Incident Response

Reviewed: 2026-07-22 · Canon: generation 8, effective 2026-07-21 · Status: documented runbook. Not yet exercised against a paying-customer incident, because there are no paying customers yet. Tested response is an explicit gate before production real-data use.

1. Detection

Severity is assigned at first triage: Sev 1 (regulated data or integrity at risk, or a customer-facing outage) through Sev 4 (routine).

2. Triage

Founder rotation

1. Giles-Evan Mboumi (CEO): primary on-call, customer communications lead
2. Christian Montgomery (COO): security and operations lead
3. Abhishek Jha (CTO): technical and architecture escalation

Formal paging tooling is a later formalization; the current model is a founder rotation with direct escalation.

First-response checklist

1. Confirm severity (Sev 1 through 4)
2. Open the incident channel
3. Capture initial state: timestamp, affected surface, scope of impact
4. Pull monitoring and error-tracking context
5. If Sev 1 with customer impact: notify per contractual terms
6. Begin remediation; preserve forensic evidence before destructive fixes

3. Communication

Investor notification: Sev 1 events that materially affect the commercial trajectory are included in the next investor update with summary and remediation. Routine events are not surfaced.

4. Post-mortem cadence

• Initial blameless post-mortem within 24 hours of resolution.
• Template fields: date, impact, root cause, detection, response, resolution, lessons, action items.
• Action items tracked with owner and due date; customer-facing post-mortem provided per contractual terms.

5. PHI breach protocol (activates with real data)

If PHI exposure is suspected:

1. Preserve forensic evidence immediately (cloud audit logs, access logs, application logs, ledger snapshot)
2. Begin internal investigation within 1 hour
3. Engage outside counsel (Jason Acevedo, Klehr Harrison)
4. No public disclosure pre-investigation
5. Customer notification triggers on confirmation, within the HIPAA and contractual windows

If PHI exposure is confirmed:

1. Customer notification per BAA terms
2. HHS OCR notification per the Breach Notification Rule (500-or-more individuals: within 60 days; smaller: annual log)
3. Affected-individual notification within 60 days of discovery
4. Media notification where the rule requires it

Current state: there is no production PHI flow, so this protocol has no live exposure to act on. It is documented now so it is not improvised later.

6. Vendor incident protocol

1. Confirm scope with the vendor
2. Identify affected Rōvn surfaces and, later, customers
3. Pull internal evidence for the incident window
4. Notify affected parties per contractual terms
5. Track for cumulative review at the quarterly compliance check-in

7. Specific playbooks

7.1 Regulated data in error tracking (scrub failure)

1. Disable the sender for the affected surface
2. Review the recent event window for scrub failures
3. Engage the vendor to delete affected event data
4. Trigger the breach protocol if confirmed

7.2 Database exfiltration suspected

1. Lock down database access; revoke the affected service identity
2. Pull database and cloud audit logs
3. Identify the vector; snapshot state for forensics
4. Notify per protocol if data was exposed

7.3 AI provider incident

1. Confirm vendor status
2. Route to an approved alternate model path (the runtime is model-agnostic; fallback is never silent)
3. Queue in-flight work; verify no regulated payload left the approved boundary

7.4 Source integrity (wrong data returned)

1. Pause the affected adapter (source activation fails closed)
2. Review source receipts for affected verifications
3. Escalate to the source; re-verify through an alternate path

7.5 Audit ledger integrity failure

1. Immediate Sev 1
2. Treat any chain break as potential compromise; freeze writes, snapshot, investigate
3. Full account-activity review; engage counsel

8. Tooling status

End of incident response.