---
title: "Incident Report"
incident_id: "REPLACE — e.g. INC-2026-001"
incident_kind: "incident"
source_release: "REPLACE — REQ-XXX or vYYYY.MM.DD.N"
release_scope: "REPLACE — optional broader owning release/scope"
source_issue: "REPLACE — GitHub issue number"
semantic_id: "REPLACE — stable id, usually incident_id or source_issue"
severity: "REPLACE — low | medium | high | critical"
detected_at: "REPLACE — ISO-8601 with timezone"
resolved_at: "REPLACE — ISO-8601 or 'ongoing'"
involves_personal_data: "REPLACE — true | false"
reported_to_supervisory_authority: "REPLACE — true | false | n/a"
notification_window_72h: "REPLACE — within | outside | n/a"
last_reviewed_at: "REPLACE — YYYY-MM-DD"
---

> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE COMMITTING.**
> Installed on demand via `devaudit bootstrap-governance` (v0.1.36+) as a starting point.
> If you reach for this file it's because something **happened** — replace this banner
> with the actual incident details. One incident per file (rename to
> `incident-report-<id>.md` if you keep multiple). Auditors reject unedited stubs.

# Incident Report

**Framework coverage:**

- `ISO29119.3.5.4` (Test incident report)
- `SOC2.CC7.2` (System monitoring and incident response)
- `GDPR.Art-33` (Notification of a personal data breach to the supervisory authority — 72h)
- `GDPR.Art-34` (Communication of a personal data breach to the data subject)

**Evidence type:** `incident_report` · One artefact can satisfy multiple clauses depending on its scope (test defect, ops incident, personal-data breach).

## Uploading this artefact

- **File path:** `compliance/governance/incident-report-<id>.md` (per-incident — recommended; the `incident-export.yml` workflow auto-produces these from closed GitHub issues labelled `incident`). The bare `incident-report.md` is the unedited starter — kept on disk as a reference but **skipped by the uploader** until you replace the STARTER TEMPLATE banner.
- **Upload trigger:** automatic — on every push to `develop` that touches `compliance/**`, `compliance-evidence.yml` considers `incident-report*.md` under both layouts, but uploads only files whose frontmatter `source_release` / `release_scope` matches the current derived release. Historical files remain on disk and are skipped unless an explicit bundle manifest grants inheritance; inherited files are still uploaded to their source release, not relabelled as the current release.
- **Verify after merge:** open `/projects/<slug>/compliance`. `ISO29119.3.5.4` flips to COVERED only when a non-stub `incident-report*.md` lands. `SOC2.CC7.2`, `GDPR.Art-33`, `GDPR.Art-34` flip only when the relevant attribution sections below are non-stub.
- **Refresh cadence:** none — incidents are point-in-time. Authoring is event-driven.

## Framework attribution — which clauses THIS incident closes

Mandatory baseline (every incident_report attributes to it):

- [x] **ISO 29119 §3.5.4** Test incident report — always.

Conditional — tick the boxes that match this incident's scope, then ensure the corresponding section is fully populated:

- [ ] **SOC 2 CC7.2** System monitoring and incident response — ops impact / downtime / persistent errors / perf regression / data corruption
- [ ] **GDPR Art. 33** Breach notification (supervisory authority) — personal data was exposed, lost, or mishandled (72h window applies)
- [ ] **GDPR Art. 34** Breach notification (data subject) — affected data subjects need to be told (high-risk threshold per Art. 34(1))
- [ ] **EU AI Act Art. 9 / 14 / 15** — AI / model failure, oversight bypass, accuracy / robustness regression. Cross-reference `compliance/governance/ai-disclosure.md`.

If none of the conditional boxes apply, this is still a valid incident_report — it just closes ISO 29119 §3.5.4 only. The "no specific framework impact" case is genuine and should not be padded.

## Framework checklist — fields auditors look for

- [ ] §1 Summary: incident ID, severity, dates discovered/contained/closed, root cause one-liner
- [ ] §2 Timeline: actor + action + time, chronological
- [ ] §3 Affected scope: systems, data, users (counts where known)
- [ ] §4 GDPR triage: personal data Y/N → if Y, categories + count of data subjects + notification path
- [ ] §5 Root cause: blameless, technical, sufficient detail to prevent recurrence
- [ ] §6 Containment + remediation: what was done, what's still open
- [ ] §7 Follow-up actions: each → owner → due date
- [ ] §8 Sign-off: incident commander + eng lead (+ DPO when PII, + security lead when security)

## 1. Summary

- **Incident ID:** REPLACE
- **Severity:** REPLACE — low / medium / high / critical
- **One-line description:** REPLACE
- **Detected at:** REPLACE — when was it first noticed
- **Resolved at:** REPLACE — or "ongoing"
- **Duration:** REPLACE

## 2. Personal data scope (GDPR triage)

| Question | Answer |
| --- | --- |
| Did the incident involve personal data? | REPLACE — Y / N |
| If Y: estimated number of data subjects affected | REPLACE |
| If Y: categories of personal data involved | REPLACE |
| If Y: likely consequences for data subjects | REPLACE |
| **Notify supervisory authority (Art. 33)?** | REPLACE — required if Y and risk to rights/freedoms |
| **Notify data subjects (Art. 34)?** | REPLACE — required if high risk to rights/freedoms |
| 72-hour notification window: | REPLACE — within / outside / n/a; if outside, explain delay |

## 3. Timeline

| Time (UTC) | Event |
| --- | --- |
| REPLACE — ISO-8601 | REPLACE — first signal observed |
| REPLACE | REPLACE — detection escalated to on-call |
| REPLACE | REPLACE — incident channel opened, IC assigned |
| REPLACE | REPLACE — mitigation deployed |
| REPLACE | REPLACE — incident declared resolved |
| REPLACE | REPLACE — supervisory authority notified (if applicable) |
| REPLACE | REPLACE — data subjects notified (if applicable) |

## 4. Root cause

- **What happened:** REPLACE — technical narrative
- **Why it happened:** REPLACE — 5-whys or equivalent
- **Why it wasn't caught earlier:** REPLACE — gap in monitoring / testing / review

## 5. Impact

- **Users affected:** REPLACE — count + segment
- **Data confidentiality / integrity / availability impact:** REPLACE
- **Financial / reputational:** REPLACE
- **Regulatory:** REPLACE

## 6. Containment, mitigation, and recovery

- **Containment actions:** REPLACE
- **Mitigation deployed (link PRs):** REPLACE
- **Recovery actions:** REPLACE
- **Verification that the incident is resolved:** REPLACE

## 7. Communications

- **Internal:** REPLACE — who was notified, when
- **Customer / data subjects:** REPLACE — channel, content (attach), timing
- **Supervisory authority:** REPLACE — body, reference number, content (attach)
- **Public statement:** REPLACE — link if any

## 8. Lessons learned and follow-ups

- **What worked well:** REPLACE
- **What didn't:** REPLACE
- **Follow-up actions (issue links, owners, due dates):** REPLACE — file GitHub issues; one row per action
  - [ ] REPLACE — owner @REPLACE — due REPLACE
  - [ ] REPLACE — owner @REPLACE — due REPLACE

## 9. Sign-off

| Role | Name | Date |
| --- | --- | --- |
| Incident Commander | REPLACE | REPLACE |
| Engineering lead | REPLACE | REPLACE |
| DPO (if personal data involved) | REPLACE | REPLACE |
| Security lead | REPLACE | REPLACE |

## Sources

- [ICO breach reporting guidance](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/) (UK)
- [EDPB Guidelines 9/2022 on personal data breach notification](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/)
- [SOC 2 Trust Services Criteria — CC7 (System Operations)](https://www.aicpa-cima.com/topic/audit-assurance/trust-services-criteria)