Security
Last updated: April 7, 2026
IR-OS is built for security teams by someone who has run 150+ real C-Suite tabletop exercises. We take the integrity of incident records seriously because our customers rely on them in regulatory, insurance, and legal proceedings. This page describes our current security posture. For formal certifications (SOC 2 Type II, ISO 27001) please contact us — we are on the roadmap.
Architecture highlights
End-to-end TLS
All traffic uses TLS 1.2+ with Cloudflare Full (strict) SSL. HTTP/3 is enabled. Minimum TLS version is 1.2.
Row-level security
Every table in our Postgres database enforces row-level security policies so tenants can never read or write across organization boundaries, even through a bug in the application layer.
Append-only event ledger
Every incident timeline event is chained with SHA-256 over the previous event's hash. A database trigger prevents any column other than the hash fields from being updated. Edits and deletions are mathematically detectable.
Secret isolation
API keys and third-party secrets live in Cloudflare Worker secrets and Supabase environment variables. No secret is committed to source control.
Encrypted at rest
Customer Data is encrypted at rest via Supabase (AES-256) and backed up with point-in-time recovery.
Edge WAF & DDoS
Cloudflare Web Application Firewall and global DDoS protection sit in front of both the landing site and the application.
How the hash chain works
Every event recorded in an incident (declaration, task, status change, AI suggestion, notification) gets two fields:
prev_hash — the hash of the immediately preceding event in the incident, or "GENESIS" for the first event.hash — SHA-256(prev_hash || event_id || event_type || actor_id || payload || created_at).
If any event is modified after the fact, its hash will no longer match, and every subsequent event's prev_hash will also be wrong. The chain breaks visibly. A verification endpoint (/api/events/verify) re-computes and validates the chain on demand so auditors, insurers, and outside counsel can confirm integrity independently.
A Postgres trigger on the incident_events table enforces that only the hash and prev_hash columns can be updated after insert. Attempting to modify any other column (timestamp, payload, actor, type) is rejected at the database level.
Authentication and session management
- User authentication is handled by Supabase Auth with ES256-signed JWTs.
- Sessions are stored as HTTP-only, secure, SameSite cookies.
- Passwords are hashed with bcrypt via Supabase.
- Failed logins are rate-limited at the auth provider layer.
- SSO/SAML is available on Enterprise plans.
Subprocessors
For a complete list of the third-party services we rely on to operate IR-OS, see section 4 of our Privacy Policy.
Incident response
If we detect or are notified of a security incident affecting IR-OS or our customers, we:
- Activate our own internal cyber incident response plan (naturally, we run it on IR-OS).
- Contain the incident and preserve evidence.
- Notify affected customers within the timeframes required by applicable law (GDPR 72 hours, SEC 96 hours for material cyber incidents at public companies, and any other regulation that applies to the data involved).
- Publish a post-incident report once it is safe to do so.
Reporting a vulnerability
If you believe you have found a security vulnerability in IR-OS, please report it responsibly. We will acknowledge your report within 2 business days.
Email: [email protected] with the subject line [SECURITY]
We ask that you:
- Do not publicly disclose the vulnerability until we have had a reasonable time to remediate it.
- Do not access or modify data you do not own.
- Do not attempt denial-of-service attacks or social engineering of our team or customers.
We don't yet have a formal bug bounty, but we publicly acknowledge researchers who report valid issues.
Standards alignment
IR-OS plans, runbooks, and the audit trail are built on recognized cyber-IR standards. The platform is standards-anchored, not invented. Customers select the framework their program runs on; we carry the rest.
- IR plan frameworks (pick one per plan): NIST SP 800-61 Rev. 2, ISO/IEC 27035-1:2023, CISA Federal Government IR Playbook, SANS PICERL (SEC504), and IR-OS Expert (distilled from 150+ executive cyber tabletop exercises).
- Runbook serialization: OASIS CACAO 2.0 (Committee Specification, December 2023). Runbooks export as signed CACAO 2.0 JSON for portability and procurement.
- Threat and defense taxonomy: MITRE ATT&CK technique tagging on triggers and steps; MITRE D3FEND defensive countermeasure mapping.
- Operational playbooks: Pre-built runbooks derived from the CISA Federal Government Incident Response Playbook, instantiated for the canonical cyber-IR scenarios (ransomware, BEC, insider, supply chain, data breach, cloud compromise).
- Regulatory clocks: SEC Item 1.05 (4 business days), GDPR Article 33 (72 hours), NY DFS 23 NYCRR 500.17 (72 hours), HIPAA Breach Notification Rule, NIS2, DORA, CIRCIA, and state breach laws computed in parallel.
- AI corpus: The IR Brain retrieves from NIST 800-61, ISO/IEC 27035, MITRE ATT&CK, EDPB Guidelines 9/2022, OFAC ransomware advisory, CISA #StopRansomware, FBI IC3 advisories, and 150+ tabletop patterns. Every suggestion cites its source.
- Continuous currency (on the roadmap): A Standards Watcher Agent that monitors NIST CSRC, CISA, MITRE ATT&CK / D3FEND, OASIS CACAO, OFAC, SEC, EDPB, and FBI IC3 daily, drafts plan amendments with citations within 48 hours of material changes, and routes them for IR Lead approval. Your IR program stops drifting the moment it is signed.
Compliance roadmap
- Available today: Row-level security, append-only hash chain, TLS, encrypted at rest, edge WAF, single-tenant isolation at the data layer.
- In progress: Formal SOC 2 Type II audit, HIPAA BAA (on Enterprise plan), data residency options for EU customers.
- Planned: ISO 27001, CSA STAR, FedRAMP Moderate.
Contact
Questions about our security posture? Email [email protected].