Incident response and breach notification

Respond to an incident in a fixed order: report it internally, triage and contain it, work out whether personal data is involved and how badly people could be affected, decide on notification and record that decision, notify the regulator within 72 hours of awareness where needed, then find the root cause, update the plan and rehearse it yearly.

When you need this

Every security event that might be an incident sets this off: a phishing click, a lost laptop, an email to the wrong person. ISO 27001:2022 Annex A 5.24 expects a planned response with defined roles, 6.8 asks staff to report events quickly, 5.25 to 5.27 cover assessing, responding to and learning from incidents, and 5.28 covers keeping evidence. SOC 2 CC7.3, CC7.4 and CC7.5 expect the same evaluate, respond and recover sequence.

When personal data is involved it is a personal data breach. UK GDPR Article 33(1) and EU GDPR Article 33(1) set the 72-hour reporting rule, and Article 34 sets when you must tell the people affected. EU NIS2 Article 23 and EU DORA Article 19 add their own reporting duties for the entities they cover. An operations lead usually runs the response; a named director decides on reporting.

This is guidance to help you understand the requirement, not legal advice.

Before you start

Write the plan before you need it. You need a named incident lead and deputy, a decision-maker for regulator reports, one channel staff use to raise an alarm, and contact details for your IT provider, insurer and key processors. List every notification duty you carry: the regulator, customer contracts, your cyber insurer and any sector regulator.

Know how to export sign-in and email audit logs. A simple incident takes a few hours over one or two days. A ransomware event with data taken can take weeks.

Steps

Report the event internally through the agreed channel and record the time. Done when the incident lead has acknowledged it and opened an incident record.
Triage the event. Decide whether it is an incident, whether personal data is involved, and which systems are affected. Done when the record states the classification and who made it.
Contain the incident. Revoke sessions, reset credentials, isolate devices or recall the message. Done when the harm has stopped spreading and each action is logged with its time.
Preserve the evidence. Export logs, take screenshots with timestamps and keep copies of the affected data before you change anything else. Done when copies sit outside the affected systems.
Assess the risk to individuals. Consider the type and volume of data, whether people can be identified, and what could happen to them. Done when the likelihood and severity are written down.
Decide whether to notify, and record the reasoning either way. Done when the decision, the decision-maker and the time are on the record.
Notify the regulator within 72 hours of awareness where the decision is to report. Give the nature of the breach, the approximate numbers of people and records, a contact point, the likely consequences and your measures, as UK GDPR Article 33(3) requires. Send the rest in phases if you do not yet know it (UK GDPR Article 33(4)). Done when the report and its time are on the record.
Tell the people affected without undue delay when the risk to them is high, in plain language, with what they can do to protect themselves. Done when the notice has gone and its date is recorded.
Investigate the root cause and raise a corrective action for anything systemic. Done when the cause is supported by evidence.
Close the incident with a short review of what worked, what did not and what changes in the plan. Done when the plan carries a new version date.
Test the plan at least once a year with a tabletop exercise. Done when the exercise record lists the findings and the plan changes.

Deciding whether a breach is notifiable

The test is the effect on people, not the cause. Work through four questions:

Is personal data involved? If not, no GDPR notification is due, though NIS2 or DORA duties may be.
Is the data still protected? Strong encryption with the key secure usually means no realistic risk.
What could happen to the people: fraud, discrimination, distress, physical harm?
How likely is that, given who now holds the data?

If any risk to people remains, report to the regulator. If the risk is high, tell the people as well. Record every breach in your breach log, reported or not (UK GDPR Article 33(5)).

Three cases

A lost laptop with full-disk encryption and the key held elsewhere: record it, usually no report. A misdirected email with a patient’s health details sent to an outside address: report, and usually tell the patient, because health data is special category data. Ransomware where the attacker copied customer files first: report, and tell the customers whose financial or identity data was taken. If you cannot rule out copying, assume it.

Worked examples

ISO 27001, a mailbox taken over through phishing

A 35-person consultancy. Monday 09:12: a finance assistant reports entering her password on a fake sign-in page (Annex A 6.8). 09:40: the IT lead opens an Information Security Incident Record and classifies the event as an incident (5.25); sign-in logs show a foreign login at 08:51 and a new forwarding rule. 10:05: password reset, sessions revoked, rule deleted, logs exported (5.26 and 5.28).

15:00: 14 emails were forwarded, two holding bank details for three clients. The lead opens a Data Protection Incident Record timed from 09:40, when the intrusion was certain: the 72 hours run to Thursday 09:40. Tuesday 11:00: the managing director decides to report, because bank details create a fraud risk; the report goes in at 14:30 and the three clients are told that day. Friday: the root cause is an old exception that left the mailbox without multi-factor authentication, and the corrective action removes every exception. The closure review on day 12 updates the plan and books the annual exercise (5.27).

A lettings agency emails a spreadsheet of 212 customers’ names and addresses to the wrong customer on Friday 6 March 2026; one column marks 31 customers in rent arrears. The sender notices at 16:40, the time of awareness, so the 72 hours expire on Monday 9 March 2026 at 16:40.

The agency asks the recipient to delete the file at 17:10 and gets written confirmation on Saturday. Monday 09:30: the director decides. Names and addresses, now deleted, carry little risk, but the arrears column reveals financial difficulty for 31 people to a stranger, so some risk remains: the agency reports to the ICO at 11:15. The risk is not high (one known recipient, prompt written deletion, no sign of sharing), so Article 34 does not require telling the 31, and the reasoning goes on the record. The corrective action removes the arrears column from routine exports.

EU GDPR Article 33(1) and Article 34(1) apply the same tests. The report goes to the lead supervisory authority where the controller has its main establishment.

SOC 2, evidence of a working response

An auditor samples incidents from the period and checks each was classified, handled under the plan, recovered and reviewed (CC7.3 to CC7.5), as the ISO 27001 timeline above shows.

NIS2, a significant incident at an essential entity

EU NIS2 Article 23 requires an early warning within 24 hours of awareness, an incident notification within 72 hours and a final report within one month of that notification, as each member state has transposed it.

EU DORA Article 19 requires an initial notification, intermediate reports and a final report to the competent authority; the time limits are set in technical standards made under Article 20.

Checklist

How Sted helps

Sted’s knowledge base holds seven record templates under the Incident Management Procedure (PRC-IMP), among them the Information Security Incident Record (REC-ISI), the Data Protection Incident Record (REC-DPI), the Cardholder Data Incident Record (REC-CDI), the Medical Device Incident Record (REC-MDI), the AI / Algorithmic Incident Record (REC-AII) and the Incident Response Plan Test Record (REC-IRPT), which comes with a suggested annual frequency.
Records are part of the Full Management System plan.
Sted’s knowledge base includes a Data Protection Incident Record (REC-DPI) under the Incident Management Procedure (PRC-IMP), with ten sections from what happened and whose data was involved, through the risk to people, containment and who had to be told and when, to the root cause and a post-incident review.
Records are part of the Full Management System plan.
A record is opened, completed, submitted for closure and closed (or withdrawn); closure is reviewed by the document owner.
Records take file attachments, scanned for malware before download.
33 periodic record types come with a suggested frequency, but nothing is scheduled until you pick a first due date.

Sted does not detect incidents, decide whether a breach is notifiable, or notify a regulator, a CSIRT or the people affected for you.

Personal data breaches: the Article 33 and 34 rules this guide puts into practice.
ISO 27001 organisational controls: controls 5.24 to 5.28 in context.
SOC 2 security common criteria: where CC7.3 to CC7.5 sit.
Root-cause analysis for a CAPA: step 9 in detail.
Testing your business continuity plan: when an incident becomes a continuity event, and combined exercises.
Records: where each incident is recorded in Sted, and controller and processor for who reports to whom.

Frequently asked questions

When do I have to report a data breach to the ICO?

Within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. The 72 hours run through weekends and bank holidays. If you report later, the report must give the reasons for the delay.

Does a small business need a written incident response plan?

Yes, if you hold ISO 27001 certification or a SOC 2 report: Annex A 5.24 and CC7.4 both expect a planned, defined response. Without either, a one-page plan naming who leads, who decides on reporting and how staff raise an alarm still saves hours on the day.

How do I test an incident response plan?

Run a tabletop exercise at least once a year. Give a small group a realistic scenario, such as a stolen laptop on a Friday afternoon, and walk through the plan against the clock. Record who took part, which steps failed and what you changed in the plan afterwards.