Incident Management Policy

Satisfies Annex A 5.24 through 5.28 (incident management planning, assessment, response, learning, and evidence collection) and 6.8 (information security event reporting). Grounded in `register/facts.md`; statuses match `register/controls.yaml`.

1. Policy statement

Stratify does not have a general incident-management plan today. What it does have is a real, specific, already-exercisable runbook for one incident class — audit-log chain corruption — documented in docs/runbooks/db-recovery.md §3.3. That runbook is not a toy example; it names the exact detection signal (verifyChain() returning { ok: false, firstBadId: N }), the exact containment step (a temporary Postgres trigger blocking all mutations on audit_log), an incident channel, a notification commitment ("counsel notification within 24h, sobald wir Phase C sind"), and a compliance note toward the DPO referencing GDPR Art. 33.

This policy's purpose is to state, explicitly, the intent to generalize that pattern — not to pretend the generalization is already written. The pattern is: triage severity → contain → collect evidence → decide on notification → recover → review. The db-recovery.md runbook already does all six steps for one scenario. The work still to do is writing PRO-08 (Incident Response — dual-clock decision tree, per PLAN.md §4), which applies the same shape to other incident classes: a leaked credential, a discovered RLS-bypass path, a breach at a sub-processor. This document states the commitment and the underlying principles; PRO-08 is where the procedure actually gets written.

2. The existing precedent — audit-chain corruption (5.24, partial)

docs/runbooks/db-recovery.md §3.3 defines, concretely:

1. Forensic snapshot. pg_dump --table=audit_log against stratify-db, written to

forensic storage, before anything else happens.

1. Containment. A temporary Postgres trigger blocks all mutations on audit_log

("Service-Role Lockdown") so the corrupted state can't be further altered or, worse, quietly overwritten.

1. Incident channel. A dedicated Slack channel (#incident-audit-XXXX), Antonios and

Toby both in it.

1. Notification. Counsel notified within 24 hours, once Stratify reaches Phase C.
2. Recovery. Restore from the most recent known-good dump (the state immediately before

firstBadId) into a throwaway database, re-validate the chain there, then selectively restore into production.

1. Evidence retention. The forensic-storage snapshot from step 1 is archived to the DPO,

with an explicit note that GDPR Art. 33 may apply.

This is scored partial in controls.yaml precisely because it is real and substantive for *one* scenario, not because it's aspirational. The gap is breadth, not existence.

3. Assessment and decision on events (5.25) — status: not_started

No incident-severity taxonomy exists beyond the single P0 label used in the audit-chain runbook. There is no documented answer today to "is this a P1, is this something that waits until Monday, does this need the same forensic-snapshot-first discipline as the audit-log scenario." That taxonomy — even a simple P0–P3 scale with a one-line trigger definition for each level — is one of the concrete deliverables PRO-08 needs to produce; this policy commits to that happening as part of Phase 3 of the ISMS build (PLAN.md §5), not to a specific delivery date.

4. Response to incidents (5.26) — status: partial

The db-recovery.md §3.3 runbook is a real incident-response runbook — for one scenario. No general incident-response runbook exists for other classes of security event: a leaked STRATIFY_SUPABASE_SERVICE_ROLE key, a discovered gap in an RLS policy, a compromise at a sub-processor (AWS SES, Stripe, or one of the push-notification vendors — see register/suppliers.yaml). The commitment this policy states is to generalize the same six-step shape from §2 to those other classes:

• Triage severity — using the taxonomy from §3, once it exists.
• Contain — the equivalent of the audit-log trigger lockdown, scenario-specific (e.g.

rotating a leaked key, per the rotation table already sketched in docs/secrets.md:76-83).

• Collect evidence — see §6.
• Decide on notification — GDPR Art. 33's 72-hour clock to the supervisory authority and

revDSG Art. 24's "as soon as possible, no fixed deadline" are the two notification clocks Stratify is exposed to today (PLAN.md §4); a third, DORA-equivalent clock becomes live once the FMA Liechtenstein license lands. PRO-08 is explicitly named to work out this decision tree — this policy states the two clocks exist and must be honored, not the decision logic itself.

• Recover — scenario-specific, drawing on the same backup/restore mechanism described in

POL-10 where the incident involves data loss or corruption.

• Review — see §5.

5. Learning from incidents (5.27) — status: not_started

No post-incident review process exists. This is a natural, and currently missing, extension of the response step above — every incident that reaches the response stage, and every drill run under PRO-07 (backup/restore testing) or PRO-13 (BC/DR testing), should produce a short written record of what worked, what didn't, and what changes as a result. None of that exists as a formal process today; it's named here as a commitment for PRO-08 to specify.

6. Collection of evidence (5.28) — status: partial

The db-recovery.md P0 runbook's forensic-snapshot step (§2, step 1) is a real, concrete evidence-collection precedent — pg_dump --table=audit_log to forensic storage, before any containment action that might alter state. That precedent generalizes reasonably well: for other incident classes, "snapshot the relevant state before you touch anything" is the same underlying discipline, whether the relevant state is a database table, application logs, or a third-party dashboard's access history. No general evidence-collection procedure exists yet for those other cases — that generalization is PRO-08's job, not this policy's.

7. Information security event reporting (6.8) — status: not_started

No formal security-event-reporting channel exists for the founder team beyond ad hoc communication (a Slack message, a conversation). For a single-person engineering team, that sounds close to moot — but it isn't: the value of a reporting channel isn't limited to notifying *someone else*, it's creating a durable, timestamped record that a suspected event was noticed and what was done about it, separate from noticing-and-moving-on.

What a minimal channel looks like, concretely: a dedicated, logged way to flag a suspected security event — even to oneself. That could be as simple as a specific audit_log event type (mirroring the ops.recovery_drill pattern already used for logging BC/DR drills, per docs/runbooks/db-recovery.md §4) reserved for "possible security event noticed," or a dated entry in a tracked incident log under docs/compliance/isms/evidence/. The mechanism matters less than the property it needs to have: it must produce a record, not just a memory. This is stated as the minimum bar; PRO-08 is where it gets specified and adopted.

8. Related documents

• PRO-08 — Incident Response (dual-clock decision tree) — pending; the procedure this policy

states the commitment for

• POL-10 — Business Continuity & ICT Resilience Policy — recovery mechanisms referenced in

§4

• docs/runbooks/db-recovery.md §3.3 — the operative P0 runbook this policy generalizes from
• docs/secrets.md §76-83 — the secret-rotation table referenced in §4
• register/risks.yaml, register/suppliers.yaml — sub-processor and risk context for

incident classes named in §4

• GOV-04 — Risk Assessment & Treatment Methodology (pending) — where the severity taxonomy

in §3 should ultimately connect to the risk register