# 20 Incident response policy

| | |
| --- | --- |
| Version | 0.1 draft |
| Owner | Security Owner; Incident Lead runs each incident |
| Review | Yearly, and after every severity 1 incident |
| Applies to | Security 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](/playbook/06-incident-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

1. **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).
2. **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).
3. **Contain, investigate, recover** as in the runbook. Preserve logs and disk snapshots before restarting or wiping anything.
4. **Notify** regulators, customers and vendors on the runbook's clocks and on contractual clocks.
5. **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.
6. **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).