---
name: prompt-pack-data-breach-response-plan
description: Use when a company needs to draft an internal Data Breach Response Plan covering incident detection and classification, initial assessment, containment, notification to regulators and affected individuals, documentation, post-incident review, and role assignments. MENA-aware: covers UAE PDPL (72-hour notification), DIFC DP Law, ADGM DP Regs, KSA PDPL, GDPR, and UK GDPR notification requirements with their different timelines and thresholds.
license: MIT
metadata:
  id: prompt-pack.data-breach-response-plan
  category: prompt-pack
  practice_area: privacy-data-protection
  priority: P2
  intent: [drafting, data-breach-response-plan, incident-response, privacy, notification, data-protection]
  related: [prompt-pack-data-processing-agreement, prompt-pack-data-retention-policy, prompt-pack-data-subject-access-request-procedure, prompt-pack-cross-border-data-transfer-assessment]
  source: Louis — HAQQ Legal AI (github.com/sboghossian/mini-claude-for-legal)
  version: "1.0"
---

# 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

| Input | Why it matters | Sensible default |
|---|---|---|
| Company name and jurisdiction(s) of operation | Determines applicable notification frameworks and timelines | Ask the user |
| Types of personal data processed | Scope of potential breach impact; certain data types (health, financial, biometric) trigger enhanced obligations | Ask the user |
| Number of data subjects | Scale of potential breach population | Ask the user |
| Whether a Data Protection Officer (DPO) has been appointed | DPO is the primary coordinator under GDPR; note if one exists | Ask the user |
| Existing incident response or IT security team structure | The plan must integrate with existing security procedures | Ask the user |

## 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)**

| Role | Responsibilities | Typical position |
|---|---|---|
| Incident Lead | Coordinates the response; convenes the BRT; escalation authority | General Counsel / CISO |
| Data Protection Officer (DPO) | Leads regulatory notification decision; advises on obligations; liaises with DPA | DPO / Privacy Counsel |
| IT/Security Lead | Manages technical containment and forensic investigation | CISO / IT Manager |
| Communications Lead | Manages internal and external communications; press statements | Head of Communications / PR |
| Legal Counsel | Provides privilege protection; advises on notification decisions; manages litigation risk | External / In-house counsel |
| Business Lead | Represents affected business unit; operational impact assessment | BU Manager |
| HR (if employee data involved) | Employee communication and employment law compliance | HR Director |

**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:

| Factor | Questions |
|---|---|
| Type of breach | Confidentiality / Integrity / Availability |
| Scope | How many data subjects are potentially affected? |
| Data types | Does it include special category data (health, biometric, financial, children's data)? |
| Status | Is the breach ongoing or contained? |
| Cause | External attack / internal error / third-party processor? |

**3.2 Severity classification**

| Severity | Criteria | Response timeline |
|---|---|---|
| Critical | Special category data; large volume; ongoing breach; public authority involved | Immediate; 24/7 BRT activation |
| High | Standard personal data; volume above 1,000 data subjects; breach contained but data exposed | BRT activation within 4 hours |
| Medium | Limited personal data; small volume; breach contained; no evidence of unauthorized access | Assessment within 24 hours |
| Low | Near miss or no data exposure confirmed | Log and review; no notification likely |

**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)**

| Jurisdiction | Authority | Deadline | Threshold | Content required |
|---|---|---|---|---|
| EU (GDPR) | Lead Supervisory Authority (Art. 55/56) | 72 hours from discovery | If likely to result in risk to rights and freedoms of individuals | Nature, categories, approx number affected, DPO contact, consequences, measures taken |
| UK (UK GDPR) | ICO | 72 hours | Same as GDPR | Same as GDPR |
| UAE (PDPL) | UAE DPA (TDRA) | 72 hours | If likely to cause serious harm | Same categories as GDPR broadly; specific TDRA guidance to be monitored |
| DIFC | DIFC Commissioner of Data Protection | 72 hours from becoming aware | If likely to result in a risk to rights and freedoms | Nature, approximate number of data subjects, consequences, measures |
| ADGM | ADGM Commissioner of Data Protection | 72 hours | Equivalent to DIFC | Equivalent |
| KSA (PDPL) | Saudi DPA (NDMO) | 72 hours | If breach may result in prejudice to personal data subjects | NDMO implementing regulations govern the content; verify with local counsel |
| Egypt | MCIT (Ministry of Communications) | 72 hours (as per Law No. 151 of 2020) | If serious risk | Confirm with local counsel as implementing regulations are developing |

**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)**

| Jurisdiction | When required | Timing | Content required |
|---|---|---|---|
| GDPR / UK GDPR | If likely to result in high risk to rights and freedoms | "Without undue delay" | Nature of breach; DPO contact; likely consequences; measures taken; contact point for further information |
| UAE PDPL | If likely to cause serious harm | Without undue delay after regulatory notification | Equivalent content |
| DIFC DP Law | If likely to result in high risk | Without undue delay | Equivalent content |
| KSA PDPL | If harm is likely | Without undue delay | NDMO guidance to be followed |

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

| Jurisdiction | Specific risk |
|---|---|
| Lebanon | No comprehensive data protection law; apply GDPR as best practice and notify affected individuals as a matter of good practice; cyber insurance claims should be filed promptly |
| Egypt | Law No. 151 of 2020 implementing regulations are still developing; monitor MCIT guidance; 72-hour rule applies |
| KSA | NDMO implementing regulations are evolving; early regulatory engagement is recommended for significant breaches |

## 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]]