Incident Command Platform
← Back to home

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:

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

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:

  1. Activate our own internal incident response plan (naturally, we run it on IR-OS).
  2. Contain the incident and preserve evidence.
  3. 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).
  4. 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:

We don't yet have a formal bug bounty, but we publicly acknowledge researchers who report valid issues.

Compliance roadmap

Contact

Questions about our security posture? Email [email protected].