Most organisations discover their real breach process during the first serious incident. Security contains, legal debates thresholds, operations searches for data owners, communications drafts under pressure, and the deadline keeps moving closer. The hours are rarely lost through lack of effort; they are lost to decisions, templates and contacts that were never prepared.
You will not have every fact at hour 72. The law can accommodate an evolving investigation; it cannot accommodate having no process.
First decide what happened
A cyber event is not automatically a personal data breach, and a personal data breach is not limited to disclosure. Assess whether security led to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Confidentiality, integrity and availability can each be affected.
Open a decision log immediately. Record when the organisation first had sufficient information to treat the event as a suspected personal data breach, who made each decision, the evidence available at the time and what remains unknown. Do not rewrite earlier entries as facts change.
Map every clock
| Regime or obligation | Recipient | Timing and threshold | Operational note |
|---|---|---|---|
| EU GDPR Article 33 | Competent supervisory authority | Without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in risk to people’s rights and freedoms. | Document every breach and the notification decision; provide reasons if notification is late. |
| EU GDPR Article 34 | Affected individuals | Without undue delay where the breach is likely to result in a high risk. | The individual-notification threshold is higher than the authority-notification threshold. |
| India DPDP Rules 2025, Rule 7 | Affected Data Principals | Concise, clear and plain intimation without delay after awareness. | Include consequences, mitigation, protective steps and a contact point. |
| India DPDP Rules 2025, Rule 7 | Data Protection Board | Initial description without delay; detailed information within 72 hours, or a longer period allowed by the Board on written request. | Verify the applicable commencement position before relying on the rule. |
| CERT-In Directions 2022 | CERT-In | Specified cyber-security incidents must be reported within six hours of noticing the incident or being informed of it. | Not every personal data breach is necessarily a reportable CERT-In incident; map the listed incident categories. |
| Contracts and insurance | Controllers, customers, insurers and other parties | As agreed; contractual windows may be shorter than statutory deadlines. | Keep the contract matrix and current contact details in the playbook. |
“72 hours” is not a universal rule. Recipients, triggers, risk tests, content and commencement dates differ. Use a jurisdiction-and-contract matrix for every incident.
Run the first 72 hours deliberately
| Window | Primary objective | Minimum output |
|---|---|---|
| 0–2 hours | Escalate, preserve evidence, establish command and open the decision log. | Incident identifier, awareness record, named lead and secure working channel. |
| 2–6 hours | Contain without destroying evidence; identify systems, initial data scope and possible CERT-In categories. | Containment record, evidence hold, preliminary scope and six-hour reporting decision. |
| 6–24 hours | Confirm processing roles, affected people, data, locations, likely consequences and applicable clocks. | Jurisdiction matrix, initial risk assessment and notification recommendation. |
| 24–48 hours | Draft regulator, individual, customer and insurer communications using available facts. | Approved draft notices, known/unknown fact table and update schedule. |
| 48–72 hours | Submit required notifications, record references and brief support teams. | Delivery evidence, decision rationale, customer script and next-update timetable. |
| After 72 hours | Continue investigation, issue updates, remediate and preserve evidence. | Root-cause record, follow-up reports, action owners and closure tests. |
Hours 0–6: command, containment and evidence
Activate the incident team and deputies. Preserve volatile logs, snapshots and affected records before rebuilding. Separate containment decisions from destructive remediation. Record the time and source of each material fact, and assess any six-hour CERT-In obligation immediately.
Hours 6–24: scope and risk
Identify systems, data categories, approximate volume, people affected, processing roles, recipients, transfers and jurisdictions. Assess likely consequences for individuals. Confirm whether processors, joint controllers, customers or insurers must be informed.
Hours 24–72: notify and communicate
Prepare notifications from approved templates. Clearly label preliminary information and unknowns. Where a regime permits information to be provided in phases, do not wait for the complete forensic picture before submitting the initial notice. Brief customer support and internal stakeholders before individual communications are sent.
Prepare the required content
| Information | Questions to answer | Evidence source |
|---|---|---|
| Nature and scope | What happened, when, where and to which systems? | Incident timeline, logs, forensic notes |
| People and data | Which groups, data categories and approximate numbers are affected? | RoPA, data inventory, system records |
| Likely consequences | What harm could occur, with what likelihood and severity? | Risk assessment and threat analysis |
| Mitigation | What has been done and what remains planned? | Containment actions and treatment plan |
| Protective steps | What can affected people do now? | Security and fraud-prevention guidance |
| Contact point | Who can answer regulator and individual questions? | DPO or designated incident contact |
| Recurrence prevention | What root cause and corrective measures are known? | Problem record, action plan, validation tests |
Use explicit decision criteria
The notification decision should not be a vote based on confidence. Use agreed criteria covering the sensitivity and identifiability of data, scale, ease of misuse, vulnerable people, duration, containment, encryption, actual or likely harm and the ability of affected people to protect themselves.
- Whether a personal data breach occurred and the basis for that conclusion.
- The awareness time and evidence supporting it.
- Each applicable legal, regulatory, contractual and insurance clock.
- The likelihood and severity of harm to affected people.
- Who approved notification or non-notification, with authority recorded.
- Reasons for any delay and the plan for phased updates.
Communicate for the affected person
A notification is not a press release. Use clear language, explain the likely consequences, state what the organisation has done, give practical protective steps and provide a working contact route. Avoid minimising the event, hiding important facts in legal language or asking people to take steps that do not match the actual risk.
Coordinate messages across regulators, customers, affected people, employees and public statements. Differences may be necessary, but contradictions undermine trust and complicate the investigation.
Prepare before the incident
- Name incident, privacy, legal, communications and executive leads, each with a deputy.
- Maintain a one-page matrix of regulators, portals, thresholds, clocks and contract notices.
- Pre-approve notification templates and plain-language protective advice.
- Keep processor and sub-processor escalation requirements in contract records.
- Ensure the RoPA, data inventory and system ownership records can support rapid scoping.
- Test out-of-hours access to decision-makers, portals, insurers and external advisers.
- Run realistic tabletop exercises and retain the exercise log and remediation evidence.
Keep an evidence pack
- The incident and decision logs, including awareness time.
- Scoping and risk assessments with sources and assumptions.
- Copies of every notification, timestamp and delivery reference.
- Approvals, legal or DPO advice and reasons for decisions.
- Containment, remediation and recurrence-prevention actions.
- Closure evidence and updates to controls, training and playbooks.
References and scope
- Regulation (EU) 2016/679 (GDPR), Articles 33 and 34.
- Digital Personal Data Protection Rules, 2025 (India), Rule 7, together with applicable commencement notifications.
- CERT-In Directions under section 70B(6) of the Information Technology Act, dated 28 April 2022.
General information for practitioners, not legal advice. Notification duties depend on facts, jurisdiction, roles, contracts and commencement dates. Confirm the current official text and obtain qualified advice for a live incident.