A personal data breach assessment template records what happened, which personal data and people are affected, how the breach was contained, the likely risk to those people, and the decisions on notifying the regulator and the individuals, with reasons and a named decision maker. Complete one for every breach, including those you decide not to report.
Why does every breach need a written assessment?
Data protection law in many markets, including the GDPR and the UK GDPR, requires organisations to assess breaches quickly, to notify the supervisory authority within a short statutory deadline where the breach is likely to put people at risk, and to tell affected people directly where the risk is high. It also expects a record of every breach, notified or not. The assessment is that record, and the basis for the notification decision.
Time pressure is the main reason to use a template. The deadline runs from when you become aware of the breach. A team working out what to record while the clock runs makes worse decisions than one filling in known fields.
Where can an AI agent help, and where not?
An agent can do the fast, factual parts: pull the records involved, list the data fields exposed, count affected people, and classify the data. Whether an AI agent can classify personal data covers how reliable that is. It can also draft the assessment and the notification for review.
The risk judgement and the decision to notify are different. They weigh likelihood and severity of harm to real people, and they carry legal consequences. Whether an AI agent can decide whether a data breach must be reported answers no: the data protection officer or equivalent decides. The working process is in how to assess personal data breaches for notification with an AI agent.
How do you complete each field?
- What happened. Plain facts: what, when, how discovered, by whom.
- Data involved. Categories and fields. Mark special category data, such as health data, separately; it raises the risk.
- People affected. Number, or best estimate with its basis. Note vulnerable groups.
- Containment. What was done, when, and whether the data can be recovered or deleted by the recipient.
- Likelihood of harm. Who now has the data, and could they misuse it?
- Severity of harm. What could happen to the people: fraud, distress, discrimination, physical risk.
- Decisions. Notify the regulator? Notify individuals? Each with reasons and decision maker.
The personal data breach assessment template
| No. | Field | Completed by |
|---|---|---|
| 1 | Breach reference; date and time of awareness | Agent records |
| 2 | Description of what happened | Agent drafts from incident report |
| 3 | How and by whom it was discovered | Agent records |
| 4 | Systems and records involved | Agent |
| 5 | Data categories and fields; special category marked | Agent classifies; DPO confirms |
| 6 | Number and type of people affected | Agent counts; DPO confirms |
| 7 | Containment actions and times | Incident owner |
| 8 | Can the data be recovered or confirmed deleted? | Incident owner |
| 9 | Likelihood of harm, with reasons | DPO |
| 10 | Severity of harm, with reasons | DPO |
| 11 | Overall risk to individuals | DPO |
| 12 | Notify supervisory authority? Reasons, time notified | DPO |
| 13 | Notify individuals? Reasons, method, time | DPO |
| 14 | Other notifications: insurers, partners, other regulators | DPO |
| 15 | Lessons and follow-up actions | Incident owner |
| 16 | Sign-off | DPO |
A filled sample
A hypothetical lender's support agent emailed a customer's loan statement to another customer with the same surname.
| No. | Entry |
|---|---|
| 2 | Statement for Customer A sent to Customer B's email address after the agent matched on surname and date of birth only |
| 4 | Messaging system; loan ledger |
| 5 | Name, address, loan balance, repayment history, two missed payments. No special category data |
| 6 | One person |
| 7 | Capability suspended within the hour; Customer B contacted |
| 8 | Customer B confirmed by phone that the email was deleted unread |
| 9 | Low: recipient cooperative and confirmed deletion |
| 10 | Medium: financial difficulty details could cause distress |
| 11 | Low overall |
| 12 | Not notified; risk judged unlikely given confirmed deletion; decision recorded with reasons |
| 13 | Customer A informed as a matter of good practice, with an apology |
| 15 | Matching rule changed to require account number; capability re-certified before restoring depth |
The record of the decision at row 12 is as important as the decision. If the regulator later asks, the reasons are there, dated and signed.
Where Pryme fits
In Pryme, breach assessment agents hold depth 2: they classify and draft, and the notification decision is held for the named data protection officer. The agent's own actions in a breach are in the verdict record, so row 2 can be built from evidence. Before giving an agent this role, run the AI agent risk assessment template. See AI compliance agents: second line, never the last word.
Questions people ask
Should near misses be assessed too?
Record them in a lighter form. Patterns of near misses often show where the next real breach will come from.
What if facts are incomplete when the deadline approaches?
Notify with what you know and say what is still being investigated. Most regimes allow information to follow in stages; check your own.
How does this differ from a regulatory change assessment?
A breach assessment looks at one event and its risk to people. A regulatory change impact assessment looks at a new rule and its effect on your processes. Both are second-line records, but they answer different questions.