Personal Data Breach Response Playbook
Runs the security and privacy tracks of a personal data breach in parallel so the notification decision is made on facts.
Available soon
- Format
- Word
- Size
- 69 KB
- Length
- 22 pages
- Version
- 1.1
- Updated
What's inside
What changed
- 1.1
The first-hour containment step now says to use the least disruptive containment that stops the harm, as IM-08 does.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Scenario and triggers
A personal data breach is two problems at once: a security incident to contain, and a legal decision about who must be told. This playbook runs both tracks together from the first hour, so that the decision whether to notify the supervisory authority, and whether to tell the people concerned, is made on facts gathered for it, within the time the law allows. It opens for incidents in category IC-05 (personal data breach) and IC-09 (lost or stolen device) in the Incident Classification, Severity & Escalation Matrix, and alongside any other playbook when the reporting screen finds that personal data is affected.
It works within the Incident Response Plan, which sets the roles and decision rights, and after the Incident Triage & First-Hour Assessment Procedure, which declares the incident and starts the clocks. Its messages are the templates of the Incident Communications Template Set.
When this playbook applies
Scenario | Category | Examples | First containment | Run alongside |
|---|---|---|---|---|
Misdirected email, file or post | IC-05 | A spreadsheet, letter or parcel label sent to the wrong person; a group email sent with addresses visible | Recall the email if the system allows; ask the recipient to delete it, and any copies, and to confirm in writing; for post, arrange collection or confirmed destruction | — |
Lost or stolen device | IC-09 | A laptop, phone, tablet or removable drive left on a train or taken from a car or home | Remote-wipe or lock it; revoke its sessions and certificates; change passwords stored on or used from it; check the encryption status in the device management console | Crime report if stolen (RD-16) |
Unauthorised access | IC-04 or IC-08 | A mailbox or account taken over; an employee looking up records without a business reason; a shared link open to anyone | Revoke sessions and reset credentials; remove the access or the link; preserve the access logs before anything else changes | The plan's general response for account compromise or insider misuse |
Ransomware or destructive malware affecting personal data | IC-01 | Systems holding personal data encrypted or wiped, whether or not any data was taken | Follow the Ransomware Response Playbook; this playbook runs alongside it for the privacy track | Ransomware Response Playbook |
Records altered or destroyed | IC-05 | Customer or staff records changed or deleted by mistake or on purpose; a faulty import overwriting addresses | Stop the process or account making the change; restore from a checked backup; identify which records changed and when | — |
Published or exposed by mistake | IC-05 | Personal data on a public web page, in a public cloud bucket, or in a document shared outside | Take it down or close the access; ask search engines and caches to remove copies; check access logs for who reached it | — |
A processor tells us of a breach | IC-10 | A supplier that processes personal data for us reports an incident affecting it | Ask the processor for the facts in writing, what it has done, and what it needs from us; agree the next update | The plan's general response for a supplier incident |
Guidance — delete before approval
Add the scenarios your organisation sees most. For many, the misdirected email is by far the most common breach; for others it is lost devices or post.
Is it a personal data breach?
GDPR Article 4(12) defines it: “personal data breach” means “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”. It does not need an attacker, and it does not need the data to leave the organisation: an accident counts, and so does data that is lost, altered or only made unavailable.
Kind | What it means | Examples |
|---|---|---|
Confidentiality | Personal data disclosed to, or accessed by, someone not entitled to it | An email to the wrong recipient; a stolen unencrypted laptop; an attacker reading a mailbox; an employee looking up a neighbour's record |
Integrity | Personal data altered without authority, or by mistake | Bank details changed on a supplier or payroll record; addresses overwritten by a faulty import; records tampered with |
Availability | Personal data lost, destroyed, or out of reach, even for a time | Records encrypted by ransomware; a database deleted with no backup; a system holding records unavailable for long enough to harm the people concerned |
One incident can be more than one kind. Ransomware that encrypts customer records is an availability breach; if the attacker copied them first, it is also a confidentiality breach.
Not every incident touching personal data is a breach. In INC-2026-017, staff mailbox taken over after a phishing email, the mailbox held personal data, but the audit log showed nothing had been read out or forwarded: no personal data disclosed (audit log checked); recorded as assessed, not a breach. Record that assessment and its evidence; it answers the question if it is ever asked.
Two tracks, run together
Security track | Privacy track | |
|---|---|---|
Led by | Incident manager | Data Protection Officer |
Question | How do we stop it and close the route? | What is the risk to the people concerned, and who must be told? |
Needs from the other track | Which data matters most, to direct containment | What data went where, and whether containment worked |
Ends with | Containment, the route closed, data restored | The reporting decision, notifications sent, and the breach record |
The tracks meet at the reporting decision: the executive incident lead decides, on the Data Protection Officer's assessment. Neither track waits for the other to finish.
Severity mapping
Severity says how fast we respond and who leads; it is set with the Incident Classification, Severity & Escalation Matrix on the worst impact area. Severity is the highest level any impact area reaches, judged on what the incident has done or is capable of doing. When in doubt, choose the higher level. Severity is reviewed at every update and can be raised by anyone on the response team; it is lowered only by the incident manager, with the reason recorded in the case log. For a personal data breach, the Data and the Legal and regulatory areas usually decide it:
Severity | Data | Legal and regulatory | Who is told |
|---|---|---|---|
Severity 1 (Critical) | Personal or customer data at scale taken or exposed, or likely to be | Likely a significant incident (NIS2), a major ICT-related incident (DORA), or a breach that individuals must be told of | Incident manager at once; executive incident lead within 30 minutes; crisis team convened within 1 hour; board chair, or equivalent, within 4 hours |
Severity 2 (High) | Personal data of individuals exposed, lost or altered, in limited numbers | Possibly notifiable to a supervisory authority or under a contract | Incident manager at once; executive incident lead within 2 hours |
Severity 3 (Medium) | Internal non-personal data, or personal data that was protected (for example encrypted) or recovered before it could be misused | Not notifiable | Incident manager at once; Head of Information Security the same working day |
Severity 4 (Low) | No data affected | Not notifiable | IT service desk logs and handles it; Head of Information Security in the weekly summary |
Severity and the GDPR risk level are different questions, and both are answered (IM-06). They usually line up like this:
- A breach likely to result in a high risk, so that individuals must be told, meets the Severity 1 legal criterion: likely a significant incident (NIS2), a major ICT-related incident (DORA), or a breach that individuals must be told of.
- A breach that is a risk, so notifiable to the supervisory authority, is at least Severity 2: possibly notifiable to a supervisory authority or under a contract.
- Personal data exposed, lost or altered is at least Severity 2 on the Data area: personal data of individuals exposed, lost or altered, in limited numbers.
- Personal data that was protected or recovered in time can be Severity 3: internal non-personal data, or personal data that was protected (for example encrypted) or recovered before it could be misused. A lost laptop with full-disk encryption on, its key not with it and its data backed up is the usual case. It is still a personal data breach, and still goes in the breach record (RD-08). INC-2026-016 stays Severity 2: its data was disclosed to a recipient before anything could protect it.
The risk assessment often finishes after severity is first set. Raise severity at once if the assessment finds a higher risk; lower it only with a recorded reason (IM-04).
First-hour actions
The first hour follows the Incident Triage & First-Hour Assessment Procedure. For a personal data breach, each step has something more:
Step | In every incident | For a personal data breach |
|---|---|---|
1. Open the case | Give it a case number, record the time of declaration (the start of every reporting clock) and the reporter. | Record the time of declaration and the time the breach was first reported: the GDPR clock starts at awareness (see below). |
2. Set severity and category | Use the matrix. When in doubt, choose the higher severity. | Category IC-05 or IC-09, or the category of the underlying incident with this playbook alongside. Personal data exposed, lost or altered means at least Severity 2; protected or recovered in time, Severity 3 may fit. |
3. Escalate | Tell the people the severity requires, within its time. | Tell the Data Protection Officer within the hour, whatever the severity. |
4. Contain what is spreading | Isolate before investigating when harm is spreading, with the least disruptive containment that stops it; otherwise preserve evidence first. | Contain the data, not only the system: recall, ask for deletion, wipe, revoke, take down. |
5. Start the reporting screen | Ask the three legal questions (NIS2, GDPR, DORA where it applies) and the contract and insurance questions. The screen is complete within 4 hours (IM-06). | The GDPR question: Is personal data affected (confidentiality, integrity or availability)? If so, is the breach unlikely to result in a risk to individuals, a risk, or a high risk? The Data Protection Officer starts the risk assessment now. |
6. Set the next update | Agree when the team reconvenes, and send the first internal update. | Agree when the risk assessment will be ready, and the facts it still needs. |
Contain the breach
- Misdirected email or file: recall it if your email system allows, then contact the recipient by phone and in writing. Ask them to delete it, including from deleted items and any device it was saved to, and to confirm in writing that they have deleted it and kept no copy. A written confirmation from a trusted recipient is the strongest containment there is.
- Misdirected post: ask the recipient to return it or destroy it, and confirm; arrange collection if the contents are sensitive.
- Lost or stolen device: remote-wipe or lock it, revoke its sessions and certificates, and change any password stored on or used from it. Check in the device management console whether it was encrypted and when it last checked in.
- Unauthorised access: revoke sessions and reset credentials; remove the access or the public link; preserve the logs first if they will roll over.
- Data published by mistake: take it down; ask search engines to remove cached copies; check the access logs for who reached it.
- A processor's breach: ask for the facts in writing, what it has done and what it needs from us, and agree when it will update (see the decision tree).
The request to a wrong recipient. Send it by email and follow with a call. Keep the reply.
Template | Request to delete and confirm |
|---|---|
Message | Dear [[Name]], Earlier today, at [[time]], we sent you [[an email with an attachment / a letter]] that was meant for someone else. It contains personal information about other people. Please do not open, use or forward it. Please delete it now, including from your deleted items and any folder or device it was saved to, and reply to confirm in writing that you have deleted it and kept no copy, and whether you or anyone else opened it or passed it on. We are sorry for the trouble. If you have any questions, call me on [[phone]]. [[Name, role]] |
Start the clock at awareness
The GDPR clock runs from when we became aware of the breach. The pack defines awareness once, as the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. Record the time in the case log at declaration. If the record shows someone knew earlier — a team leader told on Friday, declared on Monday — the clock started on Friday.
The screen is complete within 4 hours of declaration (IM-06); the notification to the authority, where one is needed, within 72 hours of awareness (RD-06). These are different clocks: the screen says whether a report is needed, the risk assessment can take longer, but never past the notification deadline.
Involve the Data Protection Officer
The Data Protection Officer [[or the privacy lead where no DPO is appointed]] joins in the first hour. The Data Protection Officer advises on GDPR reports. A report is never held back to avoid a deadline. The decision to report is taken by the executive incident lead, on the incident manager's reporting screen.
Guidance — delete before approval
Name the Data Protection Officer and a deputy, with out-of-hours contact details. Where no DPO is appointed, name the privacy lead; the role in this playbook is the same.
Decision tree
Assess the risk to the people concerned
Notification turns on one question: how likely and how severe is the harm to the people whose data it is? Not to the organisation — to them. GDPR has three answers: unlikely to result in a risk, a risk, and a high risk. The Data Protection Officer assesses each factor below, records what was found and where it points, and reaches a conclusion with reasons. It is a guide to judgement, not a score.
Factor | Points to unlikely | Points to a risk | Points to a high risk |
|---|---|---|---|
Type and sensitivity of the data | Names or business contact details only; data already public | Contact details with something more: addresses, order or account history, dates of birth | Special categories (health, ethnicity, religion, sexual life, trade union, biometrics), criminal records, financial or identity documents, passwords |
Volume | A few records, one or two people | Tens to hundreds of people | Thousands of people, or many data items about each |
Ease of identifying people | Data that cannot be linked to a person without other information we still control | Names or identifiers that point to a person directly | Enough to identify and locate people, or to impersonate them |
Severity and permanence of the consequences | Inconvenience at most | Unwanted contact, targeted phishing, embarrassment, time spent protecting themselves | Fraud, identity theft, financial loss, discrimination, physical harm, harm to reputation that cannot be undone |
Vulnerable people | None concerned | Some may be vulnerable | Children, patients, people in debt, people at risk of harm from someone who could find them |
Protection of the data | Strongly encrypted, with the key not compromised; or a complete, checked backup where availability was lost | Protected by a password or weak measure only | Unprotected and readable |
Whether containment worked | Recovered, or a trusted recipient confirmed in writing that it deleted the data and made no copy | Recipient known but deletion not yet confirmed; access ended but its extent unknown | Data taken by an attacker, published, or with a recipient who will not cooperate |
Reaching a conclusion. Weigh the factors together; no single column wins by counting:
Level | What it means | What follows | Messages |
|---|---|---|---|
Unlikely to result in a risk | No realistic harm to the people concerned: every factor points to 'unlikely', or the ones that did not are fully offset by protection or containment. | RD-08 breach record | None outside |
Risk | Some harm to the people concerned is realistic, but not severe or not likely. | RD-06 notification to the supervisory authority RD-08 breach record | CT-07 GDPR notification to the supervisory authority |
High risk | Harm that is severe, or likely, or both: any factor at 'high risk' that protection or containment does not offset. | RD-06 notification to the supervisory authority RD-07 communication to the individuals affected RD-08 breach record | CT-07 GDPR notification to the supervisory authority CT-08 Communication to individuals affected |
- Protection and containment can offset the others: the same spreadsheet sent to a trusted business that confirmed deletion within hours is a lower risk than one sent to an unknown address that does not reply.
- Any factor at high risk that nothing offsets makes the breach a high risk: one person's medical record sent to their employer is a high risk, however small the volume.
- When in doubt between two levels, choose the higher, and record why. An assessment can be revised as facts come in; the reasons at each stage are kept.
Guidance — delete before approval
Supervisory authorities publish guidance and worked examples on assessing breach risk. Read your authority's, and adjust the factor descriptions to match it, before approval.
The tree
Work through the questions in order. Record each answer, and the reasons, in the case log.
- Is personal data affected — its confidentiality, integrity or availability? If no: record the assessment and its evidence, and close the privacy track. If yes: continue.
- Are we the processor, handling the data for another organisation (the controller)? If yes: tell the controller without undue delay (RD-09, GDPR Article 33(2)), using CT-04 with the content of Article 33(3), and support its assessment. The controller decides whether to notify. Continue with step 6 for our own other duties.
- Did the breach happen at one of our processors? If yes: we remain the controller, and the clock starts when we are aware — usually when the processor tells us. Its contract should oblige it to tell us within [[24]] hours (clause CL-07 in the P06 Supplier Contract Security Clause Library). Ask for the facts the assessment needs, then continue.
- What is the risk to the people concerned? Use the factors above.
- Unlikely to result in a risk: record it in the breach record (RD-08). No notification. The record says why.
- A risk: notify the supervisory authority (RD-06: without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay) with CT-07, and record it (RD-08).
- A high risk: notify the authority as above, and also tell the people concerned (RD-07: without undue delay) with CT-08, unless an Article 34(3) condition applies (step 5).
- If high risk, does an Article 34(3) condition apply? Under Article 34(3), no communication is required where the data was protected (for example encrypted), where later measures mean the high risk is no longer likely, or where it would involve disproportionate effort (then a public communication instead). If one does, record which and why; the authority may still require the communication.
- Run the other reporting questions. A personal data breach can also be a significant incident under NIS2 or, for a financial entity, a major ICT-related incident under DORA; and a contract, an insurance policy or a crime may need a notice (RD-14 to RD-16). They are answered separately (IM-06).
Notifying the supervisory authority within 72 hours
GDPR Article 33(1): notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay. In the pack's terms, RD-06: without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay. Where not everything is known in time, notify with what is known and add the rest later: information not available at once may be provided in phases without undue further delay (Article 33(4)).
The notification contains at least what Article 33(3) lists; CT-07 in the Incident Communications Template Set is laid out to collect it:
- 33(3)(a) The nature of the breach, including where possible the categories and approximate number of people concerned, and the categories and approximate number of personal data records concerned
- 33(3)(b) The name and contact details of the Data Protection Officer, or another contact point where more information can be obtained
- 33(3)(c) The likely consequences of the breach
- 33(3)(d) The measures taken or proposed to deal with the breach, including, where appropriate, measures to reduce its possible adverse effects
Guidance — delete before approval
Identify your lead supervisory authority now — [[lead supervisory authority]] — and save its online form and contact details in the Incident Communications Template Set. Confirm national rules and the form with counsel and the authority; this playbook is not legal advice.
Telling the people concerned
GDPR Article 34(1): where a breach is likely to result in a high risk to the rights and freedoms of natural persons, communicate it to the data subjects without undue delay. In the pack's terms, RD-07: without undue delay, where the breach is likely to result in a high risk to individuals, unless an Article 34(3) condition is met. The communication describes the breach in clear and plain language, with a contact point, the likely consequences and the measures taken (Article 34(2)); CT-08 is written for it.
The three Article 34(3) conditions, and what each means in practice:
Condition | In practice |
|---|---|
The data was protected so that it is unintelligible to anyone not authorised, for example by encryption | Strong encryption with the key not compromised. A password-protected spreadsheet whose password went in the same email does not count. |
Later measures mean the high risk is no longer likely to materialise | For example, a stolen device recovered unopened, or credentials reset before anyone used them. Record the evidence. |
Telling each person would involve disproportionate effort | A public communication, as effective as a letter, replaces individual messages. Take legal advice first. |
When we are the processor, or our processor had the breach
We are the processor. RD-09 (GDPR Article 33(2)): “The processor shall notify the controller without undue delay after becoming aware of a personal data breach.” Tell the controller what Article 33(3) lists, as far as known, and keep it updated. Do not notify the authority or the people concerned on the controller's behalf unless the contract says so.
Our processor had the breach. The clock starts when we are aware, which is why clause CL-07 of the P06 clause library asks the processor to tell us within [[24]] hours. Its first paragraph reads: "The Supplier shall notify the Customer's security contact in Schedule [[X]] without undue delay, and in any event within [[24]] hours of becoming aware, of any actual or reasonably suspected Security Incident affecting the Customer's data, the Services or the Supplier's systems used to provide them."
Guidance — delete before approval
Check your processors' contracts for their notification time. A processor allowed 72 hours to tell you leaves you none. The P06 Supplier Contract Security Clause Library gives the clause and its negotiation notes.
The other reporting questions
The reporting screen asks every question every time (IM-06). For a personal data breach, the other two are:
Regime | Question | If yes |
|---|---|---|
NIS2 | Are we an essential or important entity, and has this incident caused, or could it cause, severe operational disruption or financial loss to us, or considerable damage to others? | RD-01 to RD-05 |
DORA | Are we a financial entity, and does the incident affect critical services and meet the thresholds of Delegated Regulation (EU) 2024/1772 Articles 8 and 9? | RD-10 to RD-13 |
Under NIS2 Article 23(1), notify the CSIRT or competent authority, without undue delay, of any significant incident; where appropriate, notify the recipients of the services of significant incidents likely to adversely affect those services. Under DORA Article 19(3), where a major ICT-related incident has an impact on the financial interests of clients, inform them without undue delay of the incident and of the measures taken.
Role actions by phase
What each role does in each phase. The phases overlap; the privacy track runs through all three.
Contain
Role | Actions |
|---|---|
Incident manager | Declare the incident, open the case and record the time of declaration; set severity; direct containment; start the reporting screen |
Data Protection Officer | Join within the first hour; start the risk assessment; decide what facts the assessment needs and who gets them |
Technical responders | Recall, wipe, lock, revoke or take down; preserve logs before they roll over |
Data owner | Say what data was involved, whose it is and how sensitive; find the list of people concerned |
Legal | Advise on the recipient's confirmation, on contracts with notice terms (RD-14) and on any crime report (RD-16) |
Communications lead | Prepare CT-09 if the breach could become public; brief the customer service team on what to say if asked |
Eradicate
Role | Actions |
|---|---|
Incident manager | Confirm the route by which the data left, or was reached, is closed |
Data Protection Officer | Complete the risk assessment with the facts gathered; recommend the reporting decision to the executive incident lead |
Technical responders | Close the route: change the setting, fix the permission, remove the malware, reset the credentials |
Data owner | Confirm the final count of people and records, and the data items for each |
Legal | Review CT-07 and CT-08 before they are sent |
Communications lead | Prepare CT-08 and CT-04 where needed; set up the enquiry line and its script |
Recover
Role | Actions |
|---|---|
Incident manager | Check the recovery criteria; agree closure; schedule the post-incident review |
Data Protection Officer | Complete the breach record (RD-08); answer the authority's questions; send any follow-up information (33(4)) |
Technical responders | Restore altered or lost data from checked backups; monitor for misuse of the data |
Data owner | Check restored records are correct; answer questions from the people concerned |
Legal | Keep the file for any complaint or claim |
Communications lead | Send CT-10; record enquiries received and answered |
Guidance — delete before approval
Name the data owner for each main set of personal data: [[the business owner of the affected records, e.g. Head of Customer Service]]. In a breach, the question "whose records are these, and what is in them?" should take minutes, not a day.
Evidence preservation
Evidence must be preserved before systems are wiped or rebuilt, unless waiting would let the harm spread; who handled it, and when, must be recorded. For a personal data breach, the evidence has a second purpose: it is what the risk assessment, the notification and the breach record are built on.
Evidence | Why it matters | Collected by |
|---|---|---|
What data was involved | The data items, by field, for each kind of record. The risk assessment and CT-07 depend on it. | Data owner |
How many records and how many people | 33(3)(a) asks for approximate numbers of both; they are often different. | Data owner |
Where the data went, or who reached it | The recipient's name and address, or the access logs showing which accounts or addresses reached the data, and when. | Technical responders |
When it happened and when we knew | The time of the breach, when it was reported, and when it was declared: the clocks start at awareness. | Incident manager |
The message, file or device itself | A copy of the misdirected email with its full headers; the device's asset record, encryption status and last check-in; the published page as it was. | Technical responders |
Confirmations | The recipient's written confirmation of deletion; the remote-wipe confirmation; the processor's written account. They are what makes containment count in the assessment. | Incident manager |
The risk assessment and the decision | Each factor, the conclusion, who made it and when, and the reasons — whether or not a report is made (IM-06, RD-08). | Data Protection Officer |
What was sent, and when | Every notification and message sent, with the time and the receipt: the approval log in the Incident Communications Template Set. | Communications lead |
- Do not spread the personal data further while collecting evidence. Keep one copy of the affected file or list, in the case folder, with access limited to the response team.
- Record who handled each item, and when (IM-07). A confirmation that cannot be found later did not happen.
- Keep the evidence for as long as the breach record: [[retention period, e.g. 6 years]]. Record it in the Incident Case & Action Log.
Communications and regulatory triggers
Only the communications lead may speak for the organisation about an incident outside it, using the approved templates; nobody else may talk to the media or post about an incident. Every message below is a template in the Incident Communications Template Set, approved as the table says. Say anything outside the organisation: communications lead, with the executive incident lead's approval.
Message | Audience | When, for a personal data breach | Approver |
|---|---|---|---|
CT-07 GDPR notification to the supervisory authority | [[lead supervisory authority]] | When the risk assessment finds a risk or a high risk (RD-06) | Executive incident lead, with the Data Protection Officer |
CT-08 Communication to individuals affected | Data subjects | When it finds a high risk and no Article 34(3) condition applies (RD-07) | Executive incident lead, with the Data Protection Officer |
CT-04 Customer notice | Customers whose service or data is affected | When a customer's data is affected and a contract requires notice (RD-14); or as the processor's notice to the controller (RD-09) | Executive incident lead |
CT-09 Media holding statement | Press and public | When the breach is, or is about to be, public | Executive incident lead |
CT-03 Staff holding message | All staff, or the affected site or team | When staff need to know what to do or not to do, e.g. not to resend a file | Executive incident lead |
The regulatory triggers at a glance
Duty | To | Deadline | Applies |
|---|---|---|---|
RD-06 Notification to the supervisory authority | [[lead supervisory authority]] | Without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay | Controllers, unless the breach is unlikely to result in a risk to individuals |
RD-07 Communication to the individuals affected | The data subjects | Without undue delay | Controllers, where the breach is likely to result in a high risk to individuals, unless an Article 34(3) condition is met |
RD-08 Breach record | Kept by us; shown to the authority on request | For every personal data breach, notified or not | Controllers |
RD-09 Notice to the controller | The controller whose data we process | Without undue delay | Where we act as a processor |
Before anything goes to the people concerned, the enquiry line must be ready: people who receive a breach letter call. Brief the customer service team with the same facts, and a script, before the letters go out.
Recovery criteria
A system must not return to normal service until the recovery criteria are met, and backups must be checked for integrity before they are restored. The pack's criteria apply to every incident:
- The cause is understood well enough that the same route in is closed.
- Backups or rebuild images were checked for integrity before they were used.
- Restored systems are patched, scanned and monitored, with credentials changed where they could have been taken.
- The system owner has tested the service and confirms it works.
- The monitoring period has started: [[7]] calendar days of closer watching for Severity 1 and 2 before closure.
For a personal data breach, closure also needs:
- The data is back under control: the recipient's written confirmation of deletion received, the device wiped or recovered, the access ended, the published copy removed.
- Altered or lost records restored from a checked backup, and checked correct by the data owner.
- Every notification decided and, where required, made; the authority's questions answered.
- Where a processor was involved, its written account received and its fix confirmed.
- The breach record complete (RD-08).
Post-incident actions
Complete the breach record
Every personal data breach is recorded, notified or not (RD-08). GDPR Article 33(5): the controller documents every personal data breach: the facts, its effects and the remedial action taken. The authority may ask to see the record, including for the breaches that were not notified. Keep it in the Incident Case & Action Log or a separate register, with these fields:
Field | What to record |
|---|---|
Case number | The incident case number |
Kind of breach | Confidentiality, integrity or availability, or more than one |
What happened | The facts, in a few sentences |
When it happened; when we became aware | Dates and times |
Data and people | Categories and approximate numbers of people and records |
Effects | The likely consequences for the people concerned |
Risk assessment | The level (unlikely, risk, high risk), the factors and the reasons |
Notified to the authority? | Yes, when and with what reference; or no, and why |
People told? | Yes, when and how; or no, and why (not a high risk, or the Article 34(3) condition) |
Remedial action | What was done to contain the breach and reduce the harm, and what changes to stop it recurring |
Decided by; date | The Data Protection Officer's assessment and the executive incident lead's decision |
Review and reassess
- Every Severity 1 and 2 incident must have a post-incident review within 10 working days of closure; its actions must have owners and due dates, and the risks it touches must be reassessed (P05 RM-10).
- Where the breach touches customer data exposed through the ordering service, reassess P05 risk R-03, customer data exposed through the ordering service, in the Information Security Risk Register. A trigger forces reassessment of the risks it touches within [[10]] working days. If the breach came by a route no risk describes — a misdirected email, say — ask the review whether a new risk is needed.
- Check whether the same thing could happen elsewhere: the same email setting in other teams, the same device model, the same shared-link setting on other sites.
- Answer any follow-up from the authority, and record the exchange with the breach record.
- Give the communications lessons to the review: the lessons note in the Incident Communications Template Set.
Guidance — delete before approval
Severity 3 and 4 incidents are reviewed together once a quarter. Look at the personal data breaches together: five misdirected emails in a quarter point to one fix.
Worked examples
Two breaches from the EXAMPLE organisation's quarter: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. The organisation, people and figures are fictional.
INC-2026-016: customer order spreadsheet sent to the wrong business customer
A customer service agent emailed a spreadsheet of 212 customers' names, delivery addresses and order histories to the wrong business customer. The recipient confirmed in writing the same day that it had deleted the file. No payment data was included.
What happened, and when
Time | What happened |
|---|---|
9 Sep 2026, 11:05 | Reported by the customer service agent who sent it |
9 Sep 2026, 11:10 | Triage started |
9 Sep 2026, 11:20 | Declared Severity 2, category IC-05 (personal data breach); the GDPR clock starts. In the first hour: Data Protection Officer told; recipient called, and asked in writing to delete the file and confirm |
9 Sep 2026, 15:20 | Reporting screen due (4 hours): personal data breach, confidentiality; NIS2 not significant; DORA not applicable |
9 Sep 2026, 16:30 | Contained: the recipient confirmed in writing that it had deleted the file |
11 Sep 2026, 10:00 | Supervisory authority notified with CT-07 (RD-06), 46 hours 40 minutes after awareness; due by 12 Sep 2026, 11:20 |
16 Sep 2026 | Closed |
24 Sep 2026 | Post-incident review; action PIA-06: turn on the warning for external recipients in email, and stop address autocomplete for customer service, due 15 Oct 2026 |
Severity. Severity 2 on the Data area: personal data of individuals exposed, in limited numbers. Nothing else reached a higher level: no service was affected and nothing spread.
The risk assessment. The Data Protection Officer's factors:
Factor | What was found | Points to |
|---|---|---|
Type and sensitivity of the data | Names, delivery addresses and order histories. No payment data, no special categories. | Risk |
Volume | 212 customers, one record each. | Risk |
Ease of identifying people | Named, with a home or delivery address: directly identifiable and locatable. | Risk |
Severity and permanence of the consequences | Unwanted contact, or phishing made convincing by real order details. No route to financial loss without further deception. | Risk |
Vulnerable people | None known among the customers concerned. | Unlikely |
Protection of the data | An unprotected spreadsheet, readable by anyone who opened it. | High risk |
Whether containment worked | The recipient, a known business customer with a contract, confirmed in writing the same day that it had deleted the file. | Unlikely |
Conclusion: a risk, not a high risk.
- Not unlikely: the file named 212 people with their addresses and what they had bought, unprotected, and it was outside our control for several hours. Had it gone further, the people concerned could have received convincing phishing. That is a realistic harm, so the breach had to be notified.
- Not a high risk: no payment data, no special categories and no vulnerable people were involved, so the worst consequence was unwanted contact rather than fraud or lasting harm. Decisively, the recipient was a known business customer under contract and confirmed in writing the same day that it had deleted the file. That confirmation is what took the risk below high.
Decision. The executive incident lead, on the Data Protection Officer's assessment, decided to notify the supervisory authority and not to tell the individuals. The notification was made at 10:00 on 11 Sep 2026, 46 hours 40 minutes after awareness and inside the 72 hours, so no reasons for delay were needed. The breach record holds the assessment, the recipient's confirmation and the decision. The CT-07 the organisation sent is the worked example in the Incident Communications Template Set.
What changed. The email client suggested a similar address and there was no warning for external recipients. The review raised PIA-06: turn on the warning for external recipients in email, and stop address autocomplete for customer service (Head of IT, due 15 Oct 2026, in progress).
Guidance — delete before approval
Had the recipient not replied, or been a stranger, the containment factor would have pointed to high risk, and the people concerned would have been told with CT-08. The assessment would have been revised the moment the confirmation arrived — in either direction.
Whether INC-2026-016 should trigger a reassessment of P05 R-03 is a question for the review: the data was customer data, but it left by email, not through the ordering service.
INC-2026-014: the GDPR part of the ransomware incident
The security monitoring provider alerted on encryption activity on one office PC at Warehouse 2. It had spread to 14 office PCs on that site's office network before the site was cut off. Ordering and dispatch were not affected. The response is in the Ransomware Response Playbook; this is its privacy track.
The reporting screen, complete at 11:30 on 12 Aug 2026, found a personal data breach to assess: shipping records on the encrypted PCs were unavailable. That is an availability breach, and it counts even though nothing was taken.
Factor | What was found | Points to |
|---|---|---|
Type and sensitivity of the data | Shipping records on the office PCs: customer names and delivery addresses. | Risk |
Protection of the data | Encrypted by the ransomware, so unavailable; the same records were held in the ordering platform and in backups. | Unlikely |
Whether containment worked | Restored from checked backups when office work resumed; the security monitoring provider's analysis found no sign of data being taken. | Unlikely |
Severity and permanence of the consequences | Ordering and dispatch were not affected. The copies on the office PCs were out of reach for about a day and a half, with no effect on the people concerned. | Unlikely |
Conclusion: unlikely to result in a risk. The records were restored from checked backups when office work resumed at 14:00 on 13 Aug 2026, the same records remained available elsewhere, and the analysis found no sign of data being taken. No harm to the people concerned was realistic.
Decision. The Data Protection Officer recorded the assessment at 10:00 on 14 Aug 2026, 49 hours 35 minutes after awareness, before the 72-hour notification deadline would have fallen. Recorded under Article 33(5) (RD-08); not notified to the authority; the individuals were not told. The NIS2 reports went separately, because the incident was significant for other reasons.
Guidance — delete before approval
The decision not to notify must be made, and recorded, inside the 72 hours. Had the analysis still been running at the deadline, the organisation would have notified with what it knew and said more would follow (Article 33(4)).
Adapting this template
Guidance — delete before approval
Small organisation: you may have no Data Protection Officer and no incident team. One person may be both incident manager and privacy lead, but someone else — the managing director, say — takes the decision to notify, on their assessment. Keep the risk factor table and the breach record: they are what an authority asks for. Misdirected email is likely your most common breach; turn on the external-recipient warning before your first one.
Regulated entity: a NIS2 essential or important entity also asks whether the breach is a significant incident (RD-01 to RD-05); a DORA financial entity whether it is a major ICT-related incident, and tells clients whose financial interests are affected (RD-13). Sector rules can add their own breach duties — for example for providers of electronic communications services, health bodies or payment institutions. Confirm with counsel which apply, and add their clocks to the decision tree.
IT run by a service provider: your managed IT or cloud provider is probably your processor, and often the first to see a breach. Its contract should require notice within [[24]] hours (CL-07) and help with your notifications (CL-11), and its staff should know that your clock may start when they tell you. If you are the service provider, you are usually the processor for your customers' data: step 2 of the decision tree, and RD-09, are yours.
Set the placeholders — the supervisory authority, retention period, data owners — before approval.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2022/2554 (DORA), Delegated Regulations (EU) 2024/1772 and 2025/301, Implementing Regulation (EU) 2025/302.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.26 — Response to information security incidents | The whole playbook: the response to a personal data breach |
ISO/IEC 27001:2022 | Annex A 5.34 — Privacy and protection of PII | Risk assessment and decision tree: protecting personal data and meeting the duties that come with it |
ISO/IEC 27001:2022 | Annex A 5.28 — Collection of evidence | Evidence preservation: what data, how many, where it went, confirmations |
NIST CSF 2.0 | RS.MA-03 — “Incidents are categorized and prioritized” | Scenario and triggers; severity mapping |
NIST CSF 2.0 | RS.AN-08 — “An incident's magnitude is estimated and validated” | The risk assessment: numbers of people and records, and the harm, estimated and validated |
NIST CSF 2.0 | RS.CO-02 — “Internal and external stakeholders are notified of incidents” | Communications and regulatory triggers: the authority, individuals, customers |
NIST CSF 2.0 | RS.MI-01 — “Incidents are contained” | Contain the breach: recall, deletion, wipe, revocation |
GDPR — Regulation (EU) 2016/679 | Article 4(12) — “personal data breach” means “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed” | Is it a personal data breach? The three kinds |
GDPR — Regulation (EU) 2016/679 | Article 33(1) — notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay | Notifying the authority within 72 hours of awareness (RD-06) |
GDPR — Regulation (EU) 2016/679 | Article 33(2) — “The processor shall notify the controller without undue delay after becoming aware of a personal data breach.” | When we are the processor (RD-09) |
GDPR — Regulation (EU) 2016/679 | Article 33(3) — the notification describes the nature of the breach (categories and approximate numbers of people and records), a contact point, the likely consequences, and the measures taken or proposed | The content of the notification; CT-07 |
GDPR — Regulation (EU) 2016/679 | Article 33(4) — information not available at once may be provided in phases without undue further delay | Information in phases |
GDPR — Regulation (EU) 2016/679 | Article 33(5) — the controller documents every personal data breach: the facts, its effects and the remedial action taken | The breach record (RD-08) |
GDPR — Regulation (EU) 2016/679 | Article 34(1) — where a breach is likely to result in a high risk to the rights and freedoms of natural persons, communicate it to the data subjects without undue delay | Telling the people concerned (RD-07) |
GDPR — Regulation (EU) 2016/679 | Article 34(2) — the communication describes the breach “in clear and plain language” and gives at least the information in Article 33(3)(b), (c) and (d) | CT-08 in clear and plain language |
GDPR — Regulation (EU) 2016/679 | Article 34(3) — no communication is required where the data was protected (for example encrypted), where later measures mean the high risk is no longer likely, or where it would involve disproportionate effort (then a public communication instead) | The three conditions under which individuals need not be told |
NIS2 — Directive (EU) 2022/2555 | Article 23(1) — notify the CSIRT or competent authority, without undue delay, of any significant incident; where appropriate, notify the recipients of the services of significant incidents likely to adversely affect those services | The other reporting questions: significant incidents |
DORA — Regulation (EU) 2022/2554 | Article 19(3) — where a major ICT-related incident has an impact on the financial interests of clients, inform them without undue delay of the incident and of the measures taken | The other reporting questions: clients of financial entities |
Definitions
Term | Meaning in this playbook |
|---|---|
Awareness | The moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. |
Breach record | The record of every personal data breach, notified or not: the facts, effects, assessment and remedial action (RD-08, GDPR Article 33(5)). |
Controller | The organisation that decides why and how personal data is processed, and carries the duty to notify. |
Data owner | The business owner of a set of personal data, who knows what it contains and whose it is: [[the business owner of the affected records, e.g. Head of Customer Service]]. |
Data Protection Officer | Advises on the risk assessment and approves CT-07 and CT-08 with the executive incident lead: [[or the privacy lead where no DPO is appointed]]. |
Data subject | The person the personal data is about. |
High risk | A breach likely to cause severe harm, or likely to cause harm at all where the harm would be serious: the level at which the people concerned are told. |
Personal data | Any information relating to an identified or identifiable living person. |
Personal data breach | GDPR's term: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. |
Processor | An organisation that processes personal data on the controller's behalf. |
Special categories | Data about health, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetics, biometrics used to identify a person, sex life or sexual orientation. |
Supervisory authority | The data protection authority a controller notifies of a personal data breach. |
IM-nn, RD-nn, CT-nn | A rule of the Security Incident Management Policy, a reporting duty in the Incident Classification, Severity & Escalation Matrix, and a message in the Incident Communications Template Set. |