Note: The 72-hour deadline is specifically associated with qualifying personal data breach notifications under GDPR Article 33. It is not a universal deadline applicable to every privacy law or every security incident.
This playbook provides a practical incident-response framework for the first hours and days following a suspected personal data breach, while highlighting where notification requirements differ across jurisdictions.
§TL;DR
When a security incident may involve personal data, organisations should move quickly to:
- Confirm and triage the incident.
- Preserve relevant evidence.
- Contain ongoing unauthorised access or disclosure.
- Determine whether personal data is involved.
- Identify affected individuals, data categories, systems, and jurisdictions.
- Assess the likelihood and severity of harm.
- Determine applicable notification obligations.
- Prepare regulator and individual notifications where required.
- Document the incident and all notification decisions.
- Continue remediation and post-incident review.
The 72-Hour GDPR Timeline
Under GDPR Article 33, a controller must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.
If notification occurs after 72 hours, the notification must include reasons for the delay.
The 72-hour period should therefore be treated as an operational deadline to work towards—not as a reason to delay containment or investigation until the deadline approaches.
§When Does the GDPR 72-Hour Clock Start?
The GDPR clock does not necessarily begin when the underlying cyberattack first occurred.
Article 33 refers to the controller becoming aware of the personal data breach.
In practice, awareness should be assessed based on the organisation's reasonable understanding that a security incident has occurred and that personal data has been compromised.
Examples include:
- Confirmed unauthorised access to a database containing personal data.
- Confirmation that personal data was exfiltrated.
- A processor reporting a confirmed breach involving the controller's personal data.
- Discovery of a lost or stolen device containing unencrypted personal data.
A security alert does not automatically establish awareness of a personal data breach. Organisations may need a short period of investigation to determine whether personal data is actually involved.
However, investigation should not become an excuse for avoidable delay.
Operational principle: Start the incident process immediately and establish the legal notification clock as soon as the facts support a finding of awareness.
The five phases at a glance
Phase 1 — Detection and Triage
- T+0 to T+6 hours — Establish whether a security incident has occurred, preserve evidence, and activate the response structure.
Phase 2 — Containment
- T+6 to T+24 hours — Stop ongoing unauthorised access while preserving evidence.
Phase 3 — Assessment
- T+24 to T+48 hours — Determine what happened, who may be affected, and which legal obligations are triggered.
Phase 4 — Notification Decision and Documentation
- T+48 to T+72 hours
Phase 5 — Regulatory Filing and Individual Communication
- T+72 hours and beyond
§Phase 1 — Detection and Triage
T+0 to T+6 hours
Objective: Establish whether a security incident has occurred, preserve evidence, and activate the response structure.
Immediate actions
- Validate the incident signal.
- Open an incident record and assign an incident ID.
- Preserve relevant logs and forensic evidence.
- Identify affected systems and accounts.
- Determine whether personal data may be involved.
- Activate the incident-response team.
- Identify the relevant controller, processor, or sub-processor roles.
- Identify potentially affected jurisdictions.
- Record key decisions and timestamps.
Core response team
Depending on the incident, involve:
- Incident commander
- Security/CISO team
- Privacy or DPO function
- Legal counsel
- IT and infrastructure teams
- Communications
- Business owner
- Relevant processor or supplier contacts
Deliverable
Initial incident summary
Document:
- What happened
- When it was detected
- Systems affected
- Data potentially involved
- Current known facts
- Unknowns requiring investigation
- Immediate containment actions
§Phase 2 — Containment
T+6 to T+24 hours
Objective: Stop ongoing unauthorised access while preserving evidence.
Potential actions include:
- Disable compromised accounts.
- Rotate exposed credentials.
- Revoke tokens and sessions.
- Isolate affected systems.
- Block malicious network traffic.
- Preserve relevant endpoint and cloud evidence.
- Patch or mitigate exploited vulnerabilities.
- Contact affected processors or service providers.
- Review contractual incident-notification requirements.
Do not destroy evidence while attempting to contain the incident.
Forensic preservation and containment should therefore be coordinated by the security response team.
Other reporting obligations
Privacy notification is only one part of incident response.
Depending on the organisation and incident, separate obligations may apply to:
- Cybersecurity authorities
- Sector regulators
- Financial regulators
- Contractual customers
- Insurance providers
- Law enforcement
- Stock exchanges or securities regulators
These obligations must be assessed independently.
Deliverable
Preliminary containment and scope report
§Phase 3 — Assessment
T+24 to T+48 hours
Objective: Determine what happened, who may be affected, and which legal obligations are triggered.
Assess:
Data involved
- Names and contact information
- Account credentials
- Financial information
- Identification information
- Health information
- Biometric information
- Children's data
- Special-category data
- Confidential business information
Affected individuals
Determine:
- Approximate number of individuals
- Categories of individuals
- Countries or jurisdictions involved
- Whether vulnerable individuals are affected
Incident characteristics
Document:
- Nature of the breach
- Duration
- Attack or failure mechanism
- Whether data was accessed
- Whether data was copied or exfiltrated
- Whether data was altered
- Whether data was deleted
- Whether the exposure remains ongoing
Risk assessment
Consider both the likelihood of harm and the severity of potential harm.
Potential consequences may include:
- Identity theft
- Fraud
- Financial loss
- Discrimination
- Reputational harm
- Loss of confidentiality
- Physical or psychological harm
- Exposure of sensitive information
Deliverable
Documented risk and notification assessment
§Phase 4 — Notification Decision and Documentation
T+48 to T+72 hours
For GDPR-covered incidents, determine whether the breach is likely to result in a risk to individuals' rights and freedoms.
If notification to the supervisory authority is required, prepare the Article 33 notification.
The notification should include, where available:
- The nature of the personal data breach.
- Categories and approximate number of affected individuals.
- Categories and approximate number of affected personal-data records.
- Contact details for the DPO or another contact point.
- Likely consequences.
- Measures taken or proposed to address the breach and mitigate adverse effects.
If all information is not available within 72 hours, GDPR permits information to be provided in phases where appropriate.
If you decide not to notify
Do not simply close the incident.
GDPR Article 33(5) requires controllers to document personal data breaches, including the facts relating to the breach, its effects, and remedial action taken.
The record should also explain why notification was or was not considered necessary.
Deliverable
Final notification decision + regulator filing package + internal breach record
§Phase 5 — Regulatory Filing and Individual Communication
T+72 hours and beyond
Where GDPR notification is required, submit the notification to the competent supervisory authority within the applicable deadline.
If the notification is submitted after 72 hours, document the reasons for the delay.
Data-subject notification
GDPR Article 34 contains a separate threshold.
Where a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must generally communicate the breach to affected individuals without undue delay, subject to the applicable exceptions.
The regulator-notification threshold and individual-notification threshold are therefore not the same.
Individual communications should generally explain:
- What happened
- What categories of information were involved
- Likely consequences
- What the organisation has done
- What individuals can do to protect themselves
- Relevant contact information
Use clear and understandable language.
§Cross-Jurisdiction Breach Notification
A global incident should not be managed using a single 72-hour rule.
Different jurisdictions use different:
- Notification triggers
- Time periods
- Risk thresholds
- Regulatory authorities
- Notification formats
- Individual-notification requirements
Illustrative comparison
| Jurisdiction | General approach |
|---|---|
| EU GDPR | Notify competent supervisory authority within 72 hours of awareness where the breach is likely to result in a risk, subject to the GDPR's exceptions. |
| UK GDPR | Similar 72-hour framework for qualifying breaches, subject to the UK GDPR and applicable UK requirements. |
| Singapore PDPA | A notifiable breach must be reported to the PDPC as soon as practicable and no later than 3 calendar days after the organisation determines that it is notifiable. |
| Brazil LGPD | Qualifying incidents involving relevant risk or damage are subject to notification requirements under ANPD Resolution 15/2024; the ANPD framework uses a 3-business-day period. |
| India DPDP framework | The DPDP Rules 2025 require notification to affected Data Principals without delay and notification to the Board without delay, followed by detailed information within 72 hours or a longer period permitted by the Board. The implementation timeline should be checked because the Act and Rules have phased commencement. |
| Other jurisdictions | Requirements vary substantially. Assess applicable national, sectoral, contractual, and cybersecurity reporting requirements separately. |
Important: This table is an operational overview, not a substitute for jurisdiction-specific legal analysis.
§Processor vs Controller Responsibilities
The organisation responsible for regulatory notification is not always the organisation that first discovers the incident.
Under GDPR:
Processor
A processor must notify the controller without undue delay after becoming aware of a personal data breach.
The processor should provide sufficient information to allow the controller to meet its own obligations.
Controller
The controller assesses whether the breach is subject to supervisory-authority notification and, where applicable, individual notification.
Contracts with processors should therefore establish incident-escalation procedures and sufficiently early internal notification deadlines.
A controller should not design its processor notification process around the full 72-hour regulatory window.
Practical approach: Require processors to escalate suspected personal data incidents significantly earlier than the controller's regulatory deadline.
§Who Owns the Decision?
Define responsibilities before an incident occurs.
Incident Commander
Owns operational coordination, escalation, and response timelines.
Security Team
Owns technical containment, forensic investigation, remediation, and root-cause analysis.
Privacy / DPO Function
Supports privacy-law analysis, notification assessment, documentation, and regulator interaction within the organisation's governance model.
Legal Counsel
Provides legal advice and supports regulatory, contractual, litigation, and communications considerations where appropriate.
Communications
Coordinates customer, employee, media, and other external communications where required.
Executive Management
Makes business and risk decisions that require senior approval.
There should be one clearly identified decision-making process for the final notification decision.
§Common Breach-Response Mistakes
Mistake 1: Treating 72 hours as a universal deadline
The GDPR deadline does not automatically apply to every jurisdiction.
Mistake 2: Waiting for the forensic investigation to be completely finished
Regulatory notification may need to occur before every fact is known. Additional information can often be provided later.
Mistake 3: Confusing a security incident with a personal data breach
Not every cybersecurity event involves personal data, and not every personal data breach has the same notification consequences.
Mistake 4: Failing to document a non-notification decision
For GDPR controllers, the breach still needs to be documented even when notification is not required.
Mistake 5: Using one global notification threshold
Different laws apply different tests.
Mistake 6: Forgetting contractual deadlines
Customers, processors, cyber-insurance providers, and other counterparties may impose notification requirements that are earlier than statutory deadlines.
Mistake 7: Losing forensic evidence
Containment actions should be coordinated with forensic preservation.
Mistake 8: Publishing an incomplete public statement
External communications should be accurate, consistent with the investigation, and coordinated with legal, privacy, security, and communications teams.
§Breach Response Checklist
First 6 hours
- Confirm incident
- Open incident record
- Preserve evidence
- Identify potentially affected systems
- Determine whether personal data may be involved
- Activate response team
- Establish incident timeline
First 24 hours
- Contain the incident
- Identify affected data
- Identify affected individuals
- Identify relevant jurisdictions
- Contact processors/vendors
- Begin notification assessment
- Check contractual and sectoral reporting obligations
First 48 hours
- Complete preliminary risk assessment
- Determine applicable notification thresholds
- Identify competent authorities
- Draft regulatory notification
- Draft individual communication if required
- Obtain appropriate internal approvals
By the applicable deadline
- Submit required regulatory notifications
- Notify affected individuals where required
- Record filing confirmations
- Document decisions and assumptions
- Continue remediation
After notification
- Provide supplementary information where required
- Complete root-cause analysis
- Remediate vulnerabilities
- Review processor controls
- Update policies and procedures
- Conduct a post-incident review
- Run a breach-response exercise based on lessons learned
§Frequently Asked Questions
Is every data breach subject to a 72-hour deadline?
No. The 72-hour deadline is specifically associated with GDPR Article 33 notifications. Other privacy and cybersecurity laws have different requirements.
Does the GDPR 72-hour clock start when the attack begins?
Not necessarily. Article 33 measures the deadline from when the controller becomes aware of the personal data breach.
Can a GDPR notification be submitted after 72 hours?
Yes, where necessary, but the controller must provide reasons for the delay.
What if we don't know all the facts?
Do not necessarily wait for a complete investigation. GDPR allows information to be provided in phases where appropriate.
Does every breach require notifying affected individuals?
No. Under GDPR, individual notification generally depends on whether the breach is likely to result in a high risk to individuals' rights and freedoms, subject to the applicable exceptions.
What should a processor do after discovering a breach?
The processor should notify the controller without undue delay and provide sufficient information for the controller to assess and meet its obligations.
Should we notify every regulator in every country where customers are located?
Not automatically. Determine which authorities have jurisdiction and apply the specific rules of each relevant jurisdiction.
Should we notify CERT-In as well as privacy regulators in India?
Potentially. Cybersecurity reporting and personal-data breach reporting are separate compliance questions. Organisations should assess the applicable CERT-In directions, sectoral requirements, contractual obligations, and the DPDP framework independently.
§Prepare Before the Incident Happens
A breach-response plan is most valuable before a breach occurs.
Organisations should maintain:
- A documented incident-response plan
- Defined privacy and security roles
- Regulator and authority contact information
- Processor escalation procedures
- Breach-assessment criteria
- Notification templates
- Evidence-preservation procedures
- Decision logs
- Communication plans
- Tabletop exercise scenarios
A well-designed process should allow the organisation to move from detection to decision-making without having to create its response framework during an active incident.
Need Support With Breach Response?
RegulatoryBridge helps organisations assess privacy incidents, coordinate regulatory requirements, document notification decisions, and manage cross-jurisdiction compliance obligations.
Explore RegulatoryBridge's Emergency Response services or contact our team to discuss your incident-response requirements.