Data Breach Response Plan

Data Breach Response Plan

A Data Breach Response Plan is a time-sensitive operational document: the first 72 hours after a breach is discovered determine whether regulatory notification deadlines are met, whether liability is mitigated, and whether the company retains or loses control of the narrative. A well-prepared plan enables the response team to act under pressure with confidence.

When to use this

• A company is implementing a data protection compliance program and needs a formal breach response procedure.
• A regulatory review, ISO 27001 certification, or client audit requires documented incident response procedures.
• A company has suffered a breach and does not have an existing plan — the plan is being drafted in parallel with the response.
• A company has reviewed its existing plan and found it inadequate for the jurisdiction(s) in which it now operates.
• A new data protection law has come into force and the existing plan does not address its specific notification requirements.

Required inputs

Optional inputs

• Insurance coverage (cyber insurance policy — notify insurer is typically a first-hour obligation).
• Whether the company processes children's data (higher severity under most frameworks).
• Whether the company is a critical infrastructure operator (enhanced obligations in some jurisdictions).
• Existing incident classification matrix (the plan should align with existing IT severity levels).

Plan structure

Part 1 — Governance and roles

1.1 Breach Response Team (BRT)

1.2 Contact directory Maintain a current list of all BRT members, their personal mobile numbers, and deputies. Test annually. A breach typically occurs outside business hours.

1.3 External resources

• Cyber insurance broker contact.
• External privacy law firm contact.
• Digital forensics firm (pre-contracted or retainer).
• Regulatory authority contacts (DPA / DPO authority) for each jurisdiction.
• Public relations crisis communications firm.

---

Part 2 — Incident detection and reporting

2.1 What is a personal data breach? A breach is any accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. This includes:

• External cyberattacks (ransomware, phishing, SQL injection).
• Internal accidental disclosure (email sent to wrong recipient, file shared publicly).
• Internal malicious access (rogue employee).
• Physical loss of device or documents.
• Third-party processor breach that affects company data.

2.2 Internal reporting obligation All employees must report any suspected breach (or near miss) to the IT/Security team and/or DPO immediately (target: within 1 hour of discovery). No employee should decide alone that a security incident is not a breach.

2.3 Breach log Every reported incident, however minor, is logged in the Breach Register with: date reported, date discovered, reporter name, initial description, and outcome. The log is maintained by the DPO.

---

Part 3 — Initial assessment (Hours 0–4)

3.1 Classification Immediately upon reporting, the IT Lead and DPO assess:

3.2 Severity classification

3.3 Containment Immediate steps:

• Isolate affected systems (disconnect from network if necessary; balance this against operational impact).
• Revoke compromised credentials.
• Preserve forensic evidence (do not wipe or overwrite affected systems before forensic imaging).
• Take screenshots and logs.

---

Part 4 — Notification obligations

This is the most legally critical section. Timelines are strict and missed deadlines can aggravate penalties.

4.1 Regulatory notification (to the Data Protection Authority)

The 72-hour clock starts from when the company becomes "aware" — which is when the incident is reported internally, not when the forensic investigation is complete. A "provisional" or "initial" notification can be filed with a commitment to provide further information. Regulators understand that full information takes time; what they do not forgive is missing the 72-hour deadline entirely.

4.2 Individual notification (to affected data subjects)

Individual notification may be waived if: appropriate technical measures render the data unintelligible (e.g., encryption was effective), subsequent measures have removed the high risk, or individual notification would require disproportionate effort (mass public communication as alternative).

---

Part 5 — Containment and recovery

• Execute the IT security team's technical remediation plan.
• Change all affected credentials and access controls.
• Patch the vulnerability that was exploited.
• Restore from clean backup if data integrity was affected.
• Validate that the breach has been fully contained before restoring normal operations.
• Engage external forensic investigators if the cause is unknown or if litigation is anticipated.

---

Part 6 — Documentation

Maintain a comprehensive Breach Record including:

• Timeline of events (discovery, assessment, containment, notification).
• All communications (internal and external) related to the breach.
• Regulatory notifications filed (date, content, authority).
• Individual notifications sent (date, method, content, number sent).
• Forensic investigation findings.
• Remediation steps taken.
• Decision log: why each notification decision was made, by whom, and on what information.

The Breach Record must be retained for a minimum of 5 years and must be available for inspection by the relevant DPA.

Privilege: draft the Breach Record with legal counsel to preserve legal privilege where possible. Factual investigation reports may not attract privilege; legal advice on notification and liability should be documented separately under privilege.

---

Part 7 — Post-incident review

Conduct a post-incident review within 30 days of containment:

1. Root cause analysis: what caused the breach and how was it not prevented?
2. Response quality: was the response plan followed? What worked and what did not?
3. Remediation: are the fixes in place permanent?
4. Lessons learned: update the response plan, security policies, and training programs based on findings.
5. Report to the board or senior management.

---

Jurisdictional alerts

Common mistakes

• Missing the 72-hour regulatory notification deadline because the internal reporting chain was too slow.
• Filing a regulatory notification before containment is confirmed — regulators want to know what the company is doing to protect individuals, not just what happened.
• Insufficient documentation — regulators will ask for the full timeline; gaps suggest inadequate process.
• Notifying individuals before the company has accurate information — incorrect notifications create additional confusion and legal exposure.
• Failure to notify the cyber insurer within the policy's notification window (often 24–48 hours) — this can void coverage.

Related skills

• [[prompt-pack-data-processing-agreement]]
• [[prompt-pack-data-retention-policy]]
• [[prompt-pack-data-subject-access-request-procedure]]
• [[prompt-pack-cross-border-data-transfer-assessment]]
• [[prompt-pack-cookie-policy]]