Security and trust
Security at iReportSource
iReportSource holds some of the most sensitive records a workplace produces: injury reports, personnel details, and the documentation behind them. We treat the confidentiality of that data as a precondition of our business, not a feature of it. This page describes the commitments we make to every customer and the controls behind them.
Examination in progress covering Security, Availability, and Confidentiality. The report will be available to customers under NDA on completion.
Infrastructure on Amazon Web Services and customer records on MongoDB Atlas dedicated clusters, all in the United States.
At rest and in transit: databases, backups, file storage, server volumes, and every connection to the application.
External vulnerability scanning every day, plus independent third-party penetration testing every year.
Organizational security
A documented program, with named owners.
The policies behind our security program, the people responsible for them, and how we hold ourselves to them.
Information security program
iReportSource maintains a documented information security program built on the SOC 2 framework: 21 policies covering information security, access control, acceptable use, change management, secure development, encryption, data classification, data retention, incident response, business continuity, vendor management, risk assessment, and vulnerability management. Policies are reviewed and approved by management at least annually and acknowledged by all personnel.
Our infrastructure, identity provider, source control, HR system, and personnel devices are connected to a compliance platform that continuously tests our controls and flags failures to the control owner.
Independent examination
iReportSource is currently undergoing a SOC 2 Type 2 examination by an independent CPA firm covering the Security, Availability, and Confidentiality trust services criteria. On completion, the report will be available to customers and qualified prospects under a non-disclosure agreement. Ask your Customer Success representative or contact our security team to request it.
Roles and responsibilities
Ownership of every policy and control is assigned to a named individual and recorded in our compliance platform. Our Chief Executive Officer holds overall accountability for the security and compliance program. Our Chief Technology Officer owns security engineering, including access administration, vulnerability remediation, monitoring, and incident response. An IT Compliance Coordinator monitors our security inbox and coordinates vendor reviews.
Security awareness training
Every team member is assigned security awareness training at hire, covering topics such as phishing, credential handling, and data classification. Completion is tracked to closure in our compliance platform. Security topics are also reviewed with all personnel in regular company-wide meetings and in a quarterly security review of open risks.
Confidentiality
Personnel are required to sign a confidentiality agreement before they access sensitive information, and to acknowledge an Acceptable Use Policy that classifies customer data, personal information, credentials, and production database content as confidential and sets out how it must be handled.
Background checks
Background checks are part of our hiring process for new team members and are reviewed by an authorized member of iReportSource in accordance with local laws.
Infrastructure and hosting
Built entirely on managed cloud infrastructure.
Where your data lives and how the network around it is built.
Cloud infrastructure
The iReportSource platform runs entirely on Amazon Web Services in the US East (Ohio) region. We do not operate a data center, corporate network, or server hardware of our own. Physical and environmental security of the hosting facilities is provided by AWS, whose compliance program and certifications are described at AWS Cloud Security.
Data hosting
Customer records are stored in MongoDB Atlas on dedicated replica-set clusters, which themselves run on AWS infrastructure in the United States. File attachments such as photographs, documents, and captured signatures are stored in Amazon S3. Production and non-production environments use separate clusters, storage, and credentials. MongoDB's security documentation is available at the MongoDB Trust Center.
Network security
The application runs inside a dedicated virtual private cloud with segmented subnets and security groups that restrict traffic to the specific ports and sources required. The only ingress from the internet is HTTPS to designated load balancer and content delivery endpoints, each protected by a web application firewall. Administrative access to private instances is available only through a single bastion host restricted to approved source addresses, and the production database accepts connections only from an approved network access list.
Data protection
Encrypted everywhere, separated by customer.
How your data is protected, who can reach it, and what happens to it over its life.
Encryption at rest
All customer data at rest is encrypted, including database storage and backups, file attachments, log archives, and the storage volumes attached to every server. Devices used by iReportSource personnel are required to have full-disk encryption enabled.
Encryption in transit
All traffic between your browser or mobile device and the iReportSource application is encrypted using TLS (HTTPS). Connections between the application and its database, file storage, and third-party integrations are also encrypted.
Separation between customers
iReportSource is a multi-tenant platform designed on the assumption that the data it holds is sensitive and must be kept separate by customer. Every authenticated request is scoped to the requesting user's customer workspace and permissions through a shared access-control layer, rather than by individual feature code.
Access to your data by our staff
iReportSource personnel may access customer data only to configure a workspace during onboarding, to troubleshoot a reported issue, or to investigate a defect. Such access is limited to personnel whose role requires it and is recorded in the platform's application audit log.
Sensitive identifiers
The platform does not store full Social Security numbers. Where a customer uses our insurance claim submission features, only the last four digits are retained.
Retention and deletion
Customer data is retained for as long as an account is active, as needed to provide the service, or as specified in the customer agreement. Records deleted by users within the application are removed from view but retained so that a deletion can be reversed and an audit trail preserved. On a documented customer request, we run a defined permanent deletion procedure that removes the customer's records from the database and the corresponding files from storage. That procedure was tested in 2026.
Access security
Least privilege, enforced technically.
How we control who on our team can reach production systems, and how changes get there.
Least privilege
Access to infrastructure and internal systems is granted on a least-privilege basis according to each person's documented role. Administrative access to production infrastructure, the production database, source code repositories, and the deployment pipeline is restricted to our engineering function.
Single sign-on and multi-factor authentication
Google Workspace is our corporate directory and single sign-on provider, and multi-factor authentication is required for every account. Console access to our AWS account, including the root account, requires multi-factor authentication. AWS permissions are assigned through groups and roles rather than to individual users, and the accounts used by our deployment pipeline are programmatic only, with no console access.
Password requirements
Personnel must use unique passwords of at least 12 characters that are not derived from guessable information and have not appeared in a known credential breach. Where a system supports it, these requirements are enforced technically; our AWS account enforces a minimum of 14 characters with complexity requirements. Passwords are rotated immediately on any suspected compromise.
Access reviews and offboarding
Access rights are reviewed whenever a person's role changes and when personnel join or leave the company. When someone leaves, their accounts are disabled and access to source control, cloud infrastructure, the database, and SaaS tools is revoked through a single tracked offboarding checklist.
Endpoint security
Any device used for iReportSource work must have full-disk encryption, a screen lock with session timeout, a host firewall, and endpoint protection enabled. Device posture is monitored continuously by an installed agent, and exceptions are surfaced to management for remediation.
Secure development and change management
Every application change is tracked to an issue or defect record and validated by a continuous integration pipeline that builds the application, runs linting, and performs static application security testing. For the API, web application, and internal support portal, a change cannot be merged unless that pipeline succeeds. Development, staging, and production are separate environments with separate databases and credentials. Production deployments are manual, limited to our engineering function, and recorded with the person who triggered them. Infrastructure changes outside the pipeline are recorded in a change register with management approval.
Product security
Controls your administrators work with every day.
The security features built into iReportSource for you and your users.
Role- and hierarchy-based permissions
Your administrators invite and manage your own users. Each user is assigned an access level and a position in your organizational hierarchy, and together these determine exactly which records that user can see and change.
Single sign-on for your users
You can federate sign-in to your own identity provider. Microsoft Entra ID and OneLogin are supported using OpenID Connect with full token verification, so your organization's multi-factor authentication and account deprovisioning policies apply to iReportSource automatically.
Authentication protections
Every user has a unique account. Passwords must meet minimum length and complexity requirements, and users created by an administrator or by bulk import must set a new password at first sign-in. Sessions use signed, expiring tokens. Authentication and other sensitive endpoints are rate-limited, and the platform's public submission forms are protected by bot detection.
Audit trails
Records carry a per-record audit trail for the life of the record. Independently, the platform keeps a request-level audit log recording the acting user, customer account, endpoint, and timestamp of API requests, including access by iReportSource personnel.
Public API
Our public API is key-authenticated, and every key is scoped to the workspace that issued it. Keys are stored hashed, API usage is logged, and keys can be revoked by iReportSource at any time on request.
File transfer and carrier integrations
Employee data files delivered over SFTP are authenticated with SSH keys, and each customer is confined to its own directory. Integrations with insurance carriers authenticate with OAuth 2.0 and transmit over TLS.
Monitoring, vulnerabilities, and incident response
Finding problems early, and acting on them.
How we watch our systems, how we find weaknesses, and what we do when something goes wrong.
Logging and monitoring
Activity in our cloud account is recorded in control-plane audit logs that are retained indefinitely and protected against deletion. Alarms built on those logs alert our engineering team to root account usage, console sign-in without multi-factor authentication, unauthorized API calls, and changes to identity, network, storage, encryption-key, or logging configuration. Managed threat detection, web application firewalls, and network flow logging are enabled, and load balancer, content delivery, and network logs are kept in a centralized, access-restricted archive.
Vulnerability management
Our internet-facing systems are scanned daily by an external vulnerability scanning service, and static application security testing runs in our continuous integration pipeline. An independent security firm performs penetration testing of the platform annually; the most recent test was completed in July 2026. Findings are classified by severity and tracked to remediation against defined targets: critical findings are addressed immediately with a target resolution of 7 days, high within 30 days, and medium within 60 days. Where a finding is accepted rather than fixed, the decision and its rationale are recorded in our risk register.
Incident response
We maintain a Security Incident Response Plan that any team member can initiate. It defines how incidents are classified by severity, who is responsible for containment and investigation, how affected parties are communicated with, and how the resolution and lessons learned are documented. Customers whose data is affected by a confirmed security incident are notified in accordance with the plan and applicable breach-notification laws. Infrastructure alerts are routed to our Chief Technology Officer and reviewed from 7:00 a.m. to 8:00 p.m. Eastern, seven days a week, with alerts arriving overnight addressed the following morning.
Business continuity and disaster recovery
Backed up, redundant, and tested.
How your data is backed up, how the platform stays available, and how we prove recovery works.
Backups
The production database is backed up automatically by MongoDB Atlas: snapshots every 12 hours, with daily, weekly, and monthly retention tiers and a point-in-time restore window. Snapshots are encrypted and inherit the access restrictions of the source cluster. File attachments are stored with versioning enabled and durability across multiple availability zones.
Resilient architecture
Application servers run in an auto-scaling group behind a load balancer, and a failed server is replaced automatically. The database runs as a replica set spread across multiple availability zones with automatic failover to a secondary node.
Recovery testing
Our Business Continuity and Disaster Recovery Plan documents recovery objectives, roles, and procedures, and is reviewed at least annually. Restoration from backup is tested by restoring a production snapshot to a separate temporary cluster and verifying the integrity of the restored data; the most recent test was completed in September 2026. Availability commitments, including uptime, scheduled maintenance, and recovery objectives, are set out in our customer agreements.
Vendor and risk management
Known risks, reviewed on a schedule.
How we evaluate the companies we rely on and the risks we carry.
Risk assessment
We maintain a risk register recording each risk's description, likelihood and impact, owner, treatment decision, and rationale. A full risk assessment is conducted at least annually, the register is updated when new risks are identified, and open risks are reviewed in a quarterly security review. Where a risk is accepted rather than remediated, the acceptance and its justification are documented.
Vendor management
Vendors are assessed before we engage them, considering the sensitivity of the data they will access, their security posture and available attestation reports, and our operational reliance on them. Each vendor is assigned a risk tier and recorded in a vendor register, and all vendors are reviewed at least annually. For high-risk vendors we obtain and review a current third-party audit report, such as a SOC 2 or ISO 27001 report, and confidentiality terms must be in place before any confidential data is shared.
Report a security issue.
Questions about our security program, or believe you have found a vulnerability in an iReportSource product? Contact our security team. The inbox is monitored by our compliance function and escalated to our Chief Technology Officer. We welcome reports from customers and security researchers, aim to address confirmed vulnerabilities as quickly as possible, and ask that you give us a reasonable opportunity to investigate before disclosing publicly.
Customers can also reach their Customer Success representative to request our SOC 2 report or other security documentation.