Personal data breach response plan
FourWinds Digital · Version 1.0 · 20 August 2026 Owner: Oscar Cobbe · Review due: 20 August 2027
1. What this has to do
Article 33(1) gives a controller 72 hours from becoming aware of a personal data breach to notify the supervisory authority, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Article 33(2) gives a processor no deadline at all in hours: it must notify the controller without undue delay, which in practice means fast enough for the controller to still meet its own 72 hours. Article 34(1) requires communication to the affected people themselves where the risk is high.
Three points decide whether that is met, and all three are usually lost in the first hour of an incident:
- When the clock started. Awareness is a point in time and it has to be recorded when it happens, not reconstructed afterwards.
- Which hat we are wearing. Controller and processor have different obligations and different deadlines for the same event.
- Whether the risk assessment was written down. Article 33(1) permits a decision not to notify. Article 33(5) requires the reasoning to be documented either way.
This plan exists so that none of the three depends on somebody remembering under pressure.
2. What counts as a breach
Article 4(12): a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
Three kinds, and an event can be more than one at once:
| Kind | What happened | Example in our work |
|---|---|---|
| Confidentiality | Unauthorised disclosure or access | A client's report emailed to the wrong address; a Supabase policy that exposes one account's rows to another |
| Integrity | Unauthorised alteration | A migration that overwrites records; an automation writing to the wrong account |
| Availability | Loss of access, permanent or temporary | Ransomware; a deleted table with no usable backup; a locked-out account holding the only copy |
Availability is the one most often missed. A restore that takes long enough to matter is a breach even though nothing left the building and nothing was read by anybody.
Not a breach: a security incident with no personal data in it. A blocked intrusion attempt, a failed login, a vulnerability found and patched before exploitation. These go in the incident log, not this process. The distinction is real and it is not an excuse: if there is any doubt about whether personal data was reached, treat it as a breach until established otherwise.
3. Awareness, and when the clock starts
Recital 87: a controller is "aware" when it has a reasonable degree of certainty that a security incident has occurred that led to personal data being compromised.
That is later than the first suspicion and earlier than the end of the investigation. A short period of investigation to establish whether a breach happened is permitted, and the clock does not run during it. Once that investigation says yes, awareness is at that moment, and a slow investigation is not a defence.
The rule here: the moment anybody at FourWinds forms a reasonable belief that personal data has been compromised, they record the timestamp in the incident record before doing anything else. Sixty seconds spent on that is the difference between a defensible timeline and a reconstructed one.
Where a processor tells us, awareness is the moment they tell us, not the moment we get round to reading it. Notifications from processors go to an address that is monitored, and that is a procurement requirement, not a preference.
4. Which hat we are wearing
| We are | When | We must |
|---|---|---|
| Controller | Our own business data: our staff, our client contacts, our marketing lists, our portal accounts | Notify the DPC within 72 hours unless risk is unlikely (Art 33(1)). Notify data subjects where risk is high (Art 34(1)) |
| Processor | Data we handle on a client's instructions inside their systems: their CRM, their ad accounts, their portal account contents | Notify that client without undue delay (Art 33(2)). We do not notify the DPC on their behalf unless the contract says so |
Getting this backwards in either direction is serious. Notifying the DPC about a client's breach when we are their processor pre-empts a decision that is theirs to make. Failing to tell a client promptly denies them their own 72 hours.
Section 144 of the Data Protection Act 2018 makes it a criminal offence for a processor to disclose personal data without the controller's prior authority. The breach notification we owe the client is not a disclosure to a third party and is unaffected. Talking about the incident to anybody else is.
5. The first hour
In order. The first three take minutes and are the ones that get skipped.
- Record the time and what is known. Open an incident record. Who noticed, when, how, what data, whose data, which systems.
- Contain. Rotate the credential, revoke the token, take the endpoint offline, disable the account. Containment comes before diagnosis: a breach still in progress is getting worse while it is being understood.
- Preserve evidence. Logs, headers, database snapshots before any corrective write. A corrective migration that destroys the evidence of what it corrected is a familiar and expensive mistake.
- Establish the hat. Controller or processor, per section 4.
- Scope it. Categories of data, approximate number of data subjects, approximate number of records. Article 33(3)(a) asks for approximate figures, so an approximate figure now beats an exact figure at hour 71.
- Assess the risk. Section 6.
- Notify. Section 7.
6. Assessing the risk
The test in Article 33(1) is risk to the rights and freedoms of natural persons, which is not the same as risk to us. Financial loss, identity fraud, discrimination, reputational damage, loss of confidentiality of data covered by professional secrecy, and any reversal of pseudonymisation are all named in Recital 85.
Weigh, and write down:
- Type of breach. Confidentiality breaches of sensitive data rank highest; a temporary availability breach of ordinary contact data lowest.
- Nature and volume of the data. Special category data under Article 9, financial data, and credentials all raise it sharply. So does a small volume where the individuals are identifiable and the data is sensitive.
- Ease of identification. Whether the data alone identifies somebody, or needs combining with something else.
- Severity of consequences if the worst plausible use is made of it.
- Special characteristics of the individuals. Children and vulnerable people raise the risk of the same breach.
- Number of individuals affected.
- Whether the data was encrypted, and whether the key was in the same place.
The written assessment is the deliverable, not the conclusion. Article 33(5) requires documentation sufficient for the supervisory authority to verify compliance, and a decision not to notify with no reasoning behind it is the one that is hardest to defend later.
7. Notifying
The DPC, where we are controller
Within 72 hours of awareness, including weekends and public holidays. The Data Protection Commission takes breach notifications through its online webform. Article 33(4) permits information to be provided in phases where it is not all available at once, and a notification at hour 70 with gaps beats a complete one at hour 80. A notification later than 72 hours must be accompanied by reasons for the delay.
Article 33(3) requires, at minimum:
- the nature of the breach, the categories and approximate number of data subjects, and the categories and approximate number of records;
- the name and contact details of the contact point for more information;
- the likely consequences;
- the measures taken or proposed, including mitigation.
The individuals, where the risk is high
Article 34(1): without undue delay, in clear and plain language, covering the nature of the breach and the same points as (b), (c) and (d) above.
Article 34(3) lists three exceptions, and each has to be satisfied on its own facts:
- (a) the data was protected by measures rendering it unintelligible to anyone not authorised, such as encryption, which requires the encryption to have been applied before the breach, the key not to have been compromised with it, and the algorithm to still be considered secure;
- (b) subsequent measures ensure the high risk is no longer likely to materialise;
- (c) it would involve disproportionate effort, in which case a public communication or equivalent measure is required instead.
Encryption is not an automatic exemption. All three conditions in (a) hold together or none of them do.
The client, where we are processor
Without undue delay, in writing, with everything we know. Their 72 hours started when we became aware, so a delay on our side spends their time. The message says plainly what we know, what we do not yet know, and when they will hear from us next.
8. The register
Article 33(5) requires every personal data breach to be documented, including those not notified. There is no threshold and no exemption for small ones.
Each entry holds: the facts, the effects, the remedial action, the awareness timestamp, the risk assessment, the notification decision and its reasoning, and where notified, the reference and the time.
This register is the first thing an authority asks for, and a register with only notified breaches in it says the assessment was never done for the rest.
9. Afterwards
Within ten working days of closing an incident:
- What made it possible, and what change removes that cause rather than the instance.
- Whether the detection worked, and how long it took.
- Whether this plan was followed, and where it did not fit.
- Whether any Article 32 measure needs to change, and whether a DPIA needs revisiting.
Changes go into the record of processing and into this document. An incident that produces a fix and no change to the process tends to produce the same incident again.
10. Contacts
| Role | Who | For |
|---|---|---|
| Incident lead | Oscar Cobbe | Everything below, in the first instance |
| Supervisory authority | Data Protection Commission, 6 Pembroke Row, Dublin 2, D02 X963 | Article 33 notifications, via the DPC webform |
The DPC is our lead supervisory authority because our only establishment is in Ireland.
This line carried the Commission's former address, 21 Fitzwilliam Square South, Dublin 2, D02 RD28, while the data protection policy published beside it carried the current one. Corrected against the Commission's own contact page on 9 September 2026.
11. Review
Reviewed annually, and after any notified breach, and on any material change to the systems or the processors in section 4 of the data protection policy.
This is an internal operating document. It records how FourWinds Digital responds to a personal data breach and the legal provisions that response is built on. It is not legal advice.