Incident response policy
Version0.1 draft
OwnerSecurity Owner; Incident Lead runs each incident
ReviewYearly, and after every severity 1 incident
Applies toSecurity incidents and availability incidents affecting in-scope systems
The legal notification clocks and the step-by-step first hours are in the incident and breach runbook. This policy adds the SOC 2 requirements: classification, records, review, and testing. Where they overlap, follow the runbook.
Definitions#
- Security incident: an event that compromises, or is likely to compromise, the confidentiality, integrity or availability of customer data or in-scope systems. Includes a leaked secret, unauthorised access, malware, a misconfiguration that exposed data, a lost device with access, a vendor breach, and data sent to the wrong recipient.
- Availability incident: an in-scope service unavailable or seriously degraded for customers.
Severity#
| Severity | Meaning | Response |
|---|---|---|
| 1 | Confirmed breach of customer data, or a service fully down | Incident Lead now; directors told within 1 hour; legal clocks start (CERT-In 6 hours) |
| 2 | Suspected breach, partial outage, or a control failure that exposes data | Incident Lead within 1 hour |
| 3 | Contained event with no customer impact (blocked attack, single failed job) | Next business day |
Process#
- Report. Anyone who sees a possible incident reports it at once to [paging channel] or security@. Customers and researchers report through security.txt COM-03.
- Record. Every incident, of every severity, gets a record in the incident tracker with the time detected, time reported, severity, systems, data classes, actions and their times OPS-06.
- Contain, investigate, recover as in the runbook. Preserve logs and disk snapshots before restarting or wiping anything.
- Notify regulators, customers and vendors on the runbook's clocks and on contractual clocks.
- Review. Every severity 1 and 2 incident has a written post-incident review within 5 business days: timeline, root cause, what worked, what did not, corrective actions with owners and dates OPS-07. Corrective actions are tracked to closure.
- Disclose in the report. Incidents that caused a failure to meet a service commitment during the audit period are listed in the system description. They are never hidden from the auditor.
Testing#
A tabletop exercise runs yearly, using a realistic scenario (a leaked database password, a ransomware note, a vendor breach). Notes record who took part, what was decided, and what was changed afterwards OPS-08.