You must notify the supervisory authority within 72 hours of becoming aware of a personal data breach. If the breach risks individuals' rights, you must also inform them without undue delay. Failure to report can result in significant fines, regardless of whether harm occurred.
Defining the Trigger Event
A personal data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of personal data. The key mechanism here is awareness. The legal obligation does not wait for you to confirm the scope or the attacker’s identity. It begins the moment you realize a breach has occurred. This creates a narrow window for initial assessment. You must distinguish between a suspected anomaly and a confirmed breach. A failed login attempt is not a breach. A successful unauthorized access to a database containing names and emails is.
The Initial Assessment Phase
Once you suspect a breach, you must immediately secure the affected systems. This involves isolating compromised servers, revoking access tokens, and resetting credentials. Speed is necessary to prevent further data exfiltration. However, rushing can destroy evidence needed for later analysis. You must balance immediate containment with the need to preserve logs. This tension often leads to the first non-obvious consequence: you may have to notify authorities before you know the full extent of the damage. The law accepts this uncertainty, but it penalizes silence.
Calculating the 72-Hour Window
The 72-hour deadline is strict. It starts from the moment you become aware of the breach. Public holidays do not automatically extend this deadline, though some jurisdictions may have specific interpretations. If you cannot provide all details within 72 hours, you must submit a partial notification. You must specify what is known and what is missing. You are expected to follow up with additional information as it becomes available. This mechanism ensures that authorities are not left in the dark while you investigate.
Determining Reporting Obligations
Not every breach requires notifying the supervisory authority. You may skip this step if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Examples include encrypted data where the key was not compromised, or anonymized data that cannot be linked to an individual. However, this exemption is narrow. If there is any doubt, you must report. The burden of proof for no risk lies with you. Documenting your decision not to report is critical. If an auditor later finds that a risk existed, your documentation serves as evidence of due diligence.
Assessing Risk to Data Subjects
If the breach poses a high risk to individuals, you must notify them directly. This is separate from the authority notification. The assessment of "high risk" considers the nature, severity, and potential consequences of the breach. Factors include the sensitivity of the data, the number of people affected, and the likelihood of identity theft or discrimination.
You must provide clear, plain-language information. Tell them what happened, what data was involved, and what they can do. Providing actionable advice, such as changing passwords or monitoring accounts, reduces the risk of harm. This step connects to broader practices like credit monitoring for financial data or checking resources like Have I Been Pwned for email exposure.
See also: Malware Payloads: Small Business Defense Strategies · Breach Notification Rule: What It Is and How to Comply
Documenting the Incident
You must record every personal data breach, regardless of whether you reported it to the authority. This internal record-keeping is mandatory. The record should include the facts, effects, and remedial actions taken. It must detail the nature of the breach, the categories of data affected, and the approximate number of individuals. This documentation serves two purposes.
First, it demonstrates compliance during audits. Second, it helps identify patterns in your security posture. If you notice repeated breaches involving credential leaks, you can address the root cause. This practice supports vendor risk management by showing how third-party failures impact your obligations.
Managing the Aftermath
After the immediate notification duties are met, focus shifts to remediation and review. You must fix the vulnerability that allowed the breach. This might involve patching software, updating firewall rules, or revising user access provisioning policies. You should also review your incident response plan. Did the team act quickly enough? Was the communication clear? Lessons learned from the incident should update your security controls. This ongoing improvement reduces the likelihood of future breaches. It also prepares you for the next incident, ensuring you are not caught off guard.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Detection | Anomaly identified as a confirmed breach. | False positive dismissed via log analysis. |
| Containment | Systems isolated to stop data loss. | Attack blocked by network controls before data exfiltration. |
| Assessment | Risk to individuals evaluated. | Risk deemed low due to encryption or anonymization. |
| Notification | Authority informed within 72 hours. | No notification needed if risk is low (internal record only). |
| Communication | Data subjects informed if high risk. | No communication needed if risk is not high. |
| Remediation | Vulnerability patched and lessons learned. | Process ends after documentation is complete. |
Handling Partial Information
It is common to not know everything in the first 72 hours. You do not need to wait for a full forensic report. Provide what you have. State clearly what is unknown. Explain how you plan to fill the gaps. Authorities prefer early, incomplete information over late, complete information. This approach builds trust and allows regulators to assess the situation sooner. It also gives you more time to investigate without the pressure of a looming deadline. Remember, the goal is transparency, not perfection.
Key takeaways
- The notification clock starts at awareness, creating a tension between speed and accuracy.
- Not all breaches require notifying the data subjects, only those posing a high risk to their rights.
- Internal documentation of every breach is mandatory, even if external reporting is not required.
Frequently asked questions
Does the 72-hour rule apply if the breach is reported by a third party?
Yes, the clock starts when you become aware of the breach, regardless of who reports it. If a customer tells you their data was leaked, you must begin the assessment immediately.
Can I extend the 72-hour deadline if the investigation is complex?
No, the deadline is fixed. However, you can submit a partial notification with the information you have and follow up with more details later.
Do I need to notify data subjects if the data was encrypted?
Only if the encryption key was also compromised. If the data remains unintelligible to the attacker, the risk to individuals is low, and notification may not be required.
What if I am not sure if the data is personal data?
If there is any doubt, treat it as personal data and report it. The definition of personal data is broad, including anything that can identify a person directly or indirectly.
How this guide was produced: written by the Circuit Observer editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
