All Docs
FeaturesMaking Tax DigitalUpdated March 11, 2026

GDPR-10: Data Breach Notification & Incident Response — What We've Built

GDPR-10: Data Breach Notification & Incident Response

Version: 1.0.395 Regulation: UK GDPR — Article 33 Control: GDPR-10

Why This Matters

UK GDPR Article 33 requires any organisation acting as a data controller to notify the Information Commissioner's Office (ICO) within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to the rights and freedoms of individuals.

This platform processes some of the most sensitive categories of personal financial data in the UK ecosystem:

  • National Insurance Numbers (NINOs)
  • Bank account details imported via open banking feeds
  • HMRC OAuth credentials (stored encrypted)
  • Income, expense, and rental records used for tax submissions

Without a documented incident response procedure, any breach — however well-contained technically — would carry regulatory and reputational risk simply due to the absence of process.

What's Been Added

1. Incident Response Runbook (docs/INCIDENT-RESPONSE.md)

A structured, Art. 33-compliant runbook that all engineers and operations staff should be familiar with. It covers the full lifecycle from detection to closure.

Breach Detection Sources

Breaches may surface through any of the following channels:

SourceExample Signal
Sentry alertsUnexpected bulk data access, auth token anomalies
Audit log anomaliesUnusual export volumes, repeated failed access attempts
User reportsA user noticing data that isn't theirs, account compromise
Third-party notificationBank feed provider, HMRC API, or infrastructure vendor
Internal discoveryEngineer or DPO identifies misconfiguration or exposed data

2. Severity Classification Matrix

Not all incidents are notifiable breaches. The runbook includes a severity matrix to quickly classify an incident:

SeverityDescriptionExampleAction
P1 — CriticalWide-scale exposure of NINOs, financial data, or HMRC credentialsDatabase misconfiguration exposing all usersImmediate DPO + ICO notification within 72h
P2 — HighLimited exposure of sensitive personal dataSingle user's bank records accessed by another userDPO review; likely notifiable
P3 — MediumNon-sensitive data exposed or internal onlyEmployee email addresses in a log fileDPO review; document internally
P4 — LowNo personal data involvedConfig value leaked with no PIIInternal record only

3. 72-Hour ICO Notification Decision Tree

The runbook provides a step-by-step decision tree to determine whether and when to notify the ICO:

1. Is personal data involved?
   └─ No → Document internally, no notification required
   └─ Yes → Continue

2. Was the data accessed, disclosed, altered, or lost?
   └─ No → Document internally
   └─ Yes → Continue

3. Is there a risk to individuals' rights and freedoms?
   └─ No → Document internally (Art. 33(1) threshold not met)
   └─ Yes → NOTIFY ICO within 72 hours of becoming aware

4. Is it a high risk to individuals?
   └─ Yes → ALSO notify affected individuals (Art. 34)

ICO Notification Template

The runbook includes a ready-to-use notification template covering all fields required by Art. 33(3):

  • Nature of the breach (categories and approximate number of data subjects and records)
  • Contact details of the Data Protection Officer (DPO)
  • Likely consequences of the breach
  • Measures taken or proposed to address the breach

Notification is submitted via the ICO's online breach reporting portal.

4. DPO Escalation Procedure

The runbook defines a clear escalation chain:

  1. Detecting engineer / staff member — Immediately log the incident in the internal incident tracker and notify the DPO via the designated secure channel.
  2. DPO — Assesses severity within 2 hours of notification; initiates the 72-hour ICO clock if Art. 33 threshold is met; coordinates containment.
  3. Engineering lead — Executes technical containment (credential rotation, access revocation, patch deployment).
  4. CEO / Legal — Notified for P1 incidents; approves external communications.

5. Affected-User Notification Template

Where a breach poses a high risk to individuals (Art. 34 threshold), affected users must be notified directly. The runbook includes a template covering:

  • Plain-English description of what happened
  • What personal data was involved
  • Likely consequences
  • Steps the platform has taken
  • Steps the user should take (e.g. change passwords, monitor accounts)
  • DPO contact details

6. Automation Hook (Optional)

An Inngest function registered on the breach-incident-created event can automate the initial triage phase:

  • Stamps the incident with a timestamp (starting the 72-hour clock)
  • Sends an alert to the DPO notification channel
  • Creates a structured incident record in the audit log
  • Assigns initial severity based on data categories involved

This ensures the 72-hour window is tracked automatically from the moment an incident is raised, regardless of time zone or out-of-hours availability.

Document Cross-References

The incident response procedure is linked from:

  • Privacy Policy — Users can understand how breaches affecting them will be handled
  • ROPA (Record of Processing Activities) — The response procedure is referenced against each processing activity involving high-risk data categories

Further Reading