Data breaches are a question of "when", not "if". What makes the difference is whether you have a ready response plan at the moment of a breach. Applying pre-written steps instead of improvising under pressure reduces both the time lost and the reputational damage. In Board practice the notification benchmark is 72 hours; you can only meet it with a playbook prepared in advance.
This article offers an end-to-end roadmap, from the moment you notice a breach to completing the notification and closing the process. The goal is for everyone, from the technical team to the legal department, to share the same scenario.
What Counts as a Breach
A breach is the unlawful acquisition, disclosure, alteration, deletion or loss of access to personal data. So a breach is not limited to "the data was stolen"; harm to any one of the confidentiality, integrity or availability of the data is enough.
Common examples:
- Unauthorised access and account takeover (after phishing),
- Ransomware that encrypts data and makes it inaccessible,
- An e-mail or document sent to the wrong recipient,
- A lost or stolen laptop, phone or USB drive,
- A database left exposed to the internet through misconfiguration,
- An employee copying data beyond their authorisation.
The 72-Hour Rule
The Board requires notification "as soon as possible" and, in practice, has fixed this at 72 hours. The clock starts the moment you become aware of the breach, not the moment it occurred. This distinction is critical: the clock begins when the incident is noticed by an employee, a system alert or a third party and reaches those responsible.
That is why documenting the "moment of awareness" is as important as the notification itself. Who became aware, when, and through which channel? This timestamp is the core evidence that you met the deadline. Also, where the risk is high, notification is expected not only to the Board but to the affected individuals as well.
Playbook: Step by Step
| Stage | What to do | Who |
|---|---|---|
| 2. Contain | Stop the spread, preserve evidence | IT |
| 3. Assess | Scope, data type, number affected | Team + legal |
| 4. Notify | Board (72h) + affected individuals if needed | Legal / DPO-contact |
| 5. Remediate | Close the gap, corrective measures | IT |
| 6. Document | Record the entire process | Everyone |
The value of this table is that who does what is decided in advance. Assign a lead and a backup for each stage, and keep contact details current. Mind the balance between containment and evidence preservation: shutting a system down stops the spread but may also erase valuable log records.
What Must the Notification Include?
- When and how the breach occurred,
- Affected data categories and approximate number of people,
- Likely consequences,
- Measures taken and to be taken,
- A contact point.
Not all information will be clear at the outset. In that case, rather than waiting with incomplete information, it is safer to notify with what is known and update the process in stages. The tone of the notification should be transparent and solution-focused, not defensive.
Assessing the Risk of the Breach
What determines whether the affected individuals must be notified is risk. When assessing risk, consider:
- Data type: Special-category data (health, biometrics, religion) or financial data raises the risk.
- Volume: How many people and what scope of data were affected?
- Identifiability: Does the data allow individuals to be reached directly?
- Potential harm: Is there a risk of fraud, identity theft or reputational damage?
Put the assessment and your conclusion in writing. Even if you decide not to notify, documenting the reasoning for that decision is part of accountability.
Example Scenario: A Bulk E-mail to the Wrong Recipients
The marketing team sent a newsletter by putting all customers' e-mail addresses in the "To" field (instead of BCC). This is a breach because the addresses were disclosed to each other.
The right reflex:
- Record the incident and the moment of awareness; start the clock.
- Determine the scope: how many recipients, and whether the addresses appeared alongside other data (names, health information).
- Notify the Board within 72 hours.
- Assess the risk; if the addresses sit in a sensitive context, inform the affected individuals too.
- Fix the process: mandatory BCC for bulk sends, a second approval step, and a pre-send checklist.
Although this scenario looks minor, if it recurs it points to a systemic flaw; so the corrective measure must apply to the process, not to a single person.
Common Mistakes
- Treating a breach as "minor" and delaying notification.
- Not documenting when the clock started.
- Not defining in advance who does what internally.
- Not extending the post-breach corrective measure to all similar processes.
- Rushing to reset the system without preserving evidence (logs, screenshots).
After Notification: Closing and Learning
Notification is the middle of the process, not the end. Once the breach is closed, run a root-cause analysis: why was the incident possible, which control was missing? Feed the lessons back into the playbook and review other processes carrying similar risks. Hold a short "post-incident review" with the team to strengthen the process. The best response is one that prevents the next breach.
Frequently Asked Questions
Do I have to notify every breach?
Notification is expected for personal-data breaches. Even if one looks "harmless", record the assessment; document the decision. The reasoning for a decision not to notify should also be in your file.
Is 72 hours business days or calendar days?
The period is short and runs from the moment of awareness; it does not wait for weekends or holidays. So the essence is fast, documentable response, not waiting. Your playbook should cover out-of-hours scenarios too.
Must I also notify the affected individuals?
If the risk is high, yes. Depending on the nature of the breach, informing the data subjects is also expected. The notice should be clear, understandable and accompanied by advice that helps people protect themselves.
Who should make the notification?
Responsibility rests with the data controller; in practice the notification is usually coordinated by the legal department or the DPO/contact person. What matters is that this role is defined and backed up in advance.
This content is for general information only and does not constitute legal advice. Always consult a professional for a specific incident. With JUS. you can document your breach response process and keep it audit-ready — request a demo.