Security & Compliance
SOC 2 Type II & ISO/IEC 27001 Alignment
How ForensicBIM uses SOC 2 and ISO/IEC 27001 to design its security controls, what is in place today, and what an independent audit has not yet confirmed.
1. What these standards are, and what "aligned" means
SOC 2 is a report by an independent CPA firm, under AICPA rules, on a service organisation's controls for security, availability, processing integrity, confidentiality and privacy (the Trust Services Criteria). A Type I report covers how controls are designed at one point in time. A Type II report also tests whether they worked over a period, usually 3 to 12 months.
ISO/IEC 27001 is the international standard for an information security management system. An accredited certification body audits the system and issues a certificate. Annex A of the 2022 edition lists 93 controls.
When we say our controls are aligned with these frameworks, we mean that we use them to decide which controls we need and to document them. It does not mean that an auditor has tested those controls. Until that happens, you rely on our description and on the evidence we can show you.
2. Where we stand
| Item | Status |
|---|---|
| SOC 2 Type I or Type II report | Not available |
| ISO/IEC 27001 certificate | Not held |
| Independent audit | Not scheduled |
| Written security policies | In place Seven policies, reviewed at least once a year |
| Controls mapped to SOC 2 and ISO/IEC 27001 | In place See section 4 |
| Automated security and evidence checks | In place On every code change and every week |
| Disaster recovery drill | Planned Backups are on; the first drill is still to come |
3. Our written policies
Our security programme is set out in seven written policies:
- Information security policy
- Access control and multi-factor authentication policy (reviewed every six months)
- Incident response and breach notification plan
- Disaster recovery and business continuity plan
- Change management and secure development policy
- Vendor risk management and sub-processor policy
- Data retention, classification and disposal policy
Each policy is reviewed at least once a year, and the incident response plan also after every incident. Customers can request copies under confidentiality (see section 7).
4. How we protect your data
The table shows our main controls and the SOC 2 criteria and ISO/IEC 27001:2022 Annex A controls they relate to.
| Area | What we do | SOC 2 | ISO/IEC 27001 |
|---|---|---|---|
| Access control | Multi-factor authentication on our code repository, cloud platform and password manager for everyone with administrative access. Administrative rights are limited to named accounts. Customers sign in with a one-time email link or a social login, so we store no customer passwords. Sessions end after 60 minutes of inactivity. | CC6.1, CC6.2, CC6.3 | A.5.15, A.5.17, A.8.2, A.8.5 |
| Encryption | All traffic uses HTTPS (TLS), with HTTP Strict Transport Security. Stored data is encrypted at rest by our cloud platform. Enterprise customers can use their own encryption keys (CMEK) under a separate agreement. | CC6.1, CC6.7 | A.8.24 |
| Data isolation and location | Models are stored and analysed in the region the customer chooses, one of eight. If the worker in that region cannot start, the analysis fails; it never moves to another region. Storage rules tie each file to the account that uploaded it, and public access is blocked on every storage bucket. | CC6.1, C1.1 | A.5.23, A.8.3 |
| Application security | Content Security Policy and other security headers, secure HttpOnly cookies, CSRF protection, checks on file type and size at upload, and reCAPTCHA for uploads from visitors who are not signed in. | CC6.6, CC6.8 | A.8.26, A.8.28 |
| Change management and vulnerabilities | Every change to the production code goes through a pull request that must be reviewed and approved. On every change, and weekly, automated checks scan for leaked secrets (Gitleaks), vulnerable dependencies (pip-audit, npm audit), insecure code (Bandit, Semgrep), container vulnerabilities (Trivy) and web application weaknesses (OWASP ZAP). | CC7.1, CC8.1 | A.8.8, A.8.25, A.8.29, A.8.32 |
| Logging and monitoring | We log security events such as sign-ins, uploads, deletions, privacy setting changes and the use of share links, as well as administrative actions and every staff download of a model file. These logs cannot be changed from the browser and are kept for 12 months. An automated watchdog runs every 10 minutes and flags stalled analyses, failed workers, orphaned files and unusual patterns in the security log. | CC7.2, CC7.3 | A.8.15, A.8.16 |
| Backups and recovery | Database backups are enabled. Deleted files stay in a recovery store for 7 days, used only to recover from technical errors. Our recovery plan aims to restore service within 4 hours with less than 1 hour of data loss. We have not yet tested it in a drill. | A1.2, A1.3 | A.5.30, A.8.13 |
| Incident response | A written plan with severity levels covers detection, containment, recovery and lessons learned. Under our Data Processing Agreement, we notify customers of a personal data breach that affects their data within 48 hours. | CC7.3, CC7.4, CC7.5 | A.5.24, A.5.26, A.5.27 |
| Suppliers | We review sub-processors before we use them and once a year after that, and list them in our Privacy Policy and Data Processing Agreement. Their own certifications cover their services, not ForensicBIM's own controls. | CC9.2 | A.5.19, A.5.21, A.5.22 |
| People | Everyone with access to customer data receives security awareness training and has signed a confidentiality agreement. Our offboarding procedure removes access when someone leaves. | CC1.4, CC2.2 | A.6.3, A.6.5, A.6.6 |
| Privacy | Customers choose the storage region and whether their models may be used to improve our algorithms, and can delete analyses or their whole account themselves. Our Data Processing Agreement is part of our Terms of Service. | P1 to P8 | A.5.34 |
5. How we check ourselves
Alongside the security scans in section 4, an automated evidence collector runs on every code change and every week. It checks, among other things, that:
- sessions still end after 60 minutes of inactivity;
- cookies are HttpOnly and SameSite, and the security headers are present;
- security logs cannot be written or read from the browser;
- storage rules keep each customer's files separate; and
- our privacy disclosures and self-service deletion are in place.
Each run produces an evidence record that we keep, together with records of our multi-factor authentication settings. This is the evidence an auditor would ask for, but we collect it ourselves: it is not an independent assessment.
6. What we have not done yet
- No independent SOC 2 examination or ISO/IEC 27001 certification audit, and none scheduled.
- No independent penetration test.
- No disaster recovery drill yet. The first drill will test restoring the database, redeploying the service and checking stored files in every region.
We will update this page when any of these changes.
7. What you can request
For supplier assessments and procurement, we provide on request and under confidentiality:
- our written security policies;
- a summary of our controls and this mapping in more detail;
- answers to your security questionnaire; and
- a signed copy of our Data Processing Agreement.
Email support@forensicbim.business with the subject "Security documentation request". More information is on our Compliance page and in section 7 of our Privacy Policy.