Data Breach Response Plan
Data Breach Response Plan
Organization: {{ORG_NAME}} Document Number: IRP-{{NUMBER}} Version: {{VERSION}} Date: {{DATE}} Author: {{AUTHOR}} Status: Draft | Approved | Active Reviewers: {{REVIEWERS}} Next Review: {{REVIEW_DATE}} Classification: Confidential — Restricted Distribution
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | {{DATE}} | {{AUTHOR}} | Initial draft |
| 1.0 | {{DATE}} | {{AUTHOR}} | Approved for use |
IMPORTANT — Keep This Document Accessible
This plan must be accessible even when systems are down. Maintain printed copies in:
- {{PHYSICAL_LOCATION_1}}
- {{PHYSICAL_LOCATION_2}} Offline copy last printed: {{DATE}}
1. Incident Classification
| Severity | Definition | Response Team | Max Time to Classify |
|---|---|---|---|
| P1 — Critical | Confirmed breach of Restricted/Confidential data (PII, financial, health) affecting > {{N}} data subjects; OR breach affecting system availability at scale | Full IRT + Management + Legal | 1 hour |
| P2 — High | Suspected breach with evidence; or confirmed breach of Internal data; or targeted attack in progress | Core IRT + Security Lead | 2 hours |
| P3 — Medium | Security event with potential for breach; precautionary containment required | Security team | 8 hours |
| P4 — Low | Security anomaly, no confirmed breach, monitoring escalated | Security team | Next business day |
GDPR notification trigger: P1 and P2 incidents MUST be assessed for 72-hour supervisory authority notification obligation.
2. Detection Mechanisms
| Detection Method | Tool | Responsible | Alert Channel |
|---|---|---|---|
| SIEM alerts | {{SIEM_TOOL}} | Platform team | PagerDuty |
| Anomalous API traffic | {{WAF/APM}} | Platform team | Slack #security-alerts |
| Failed authentication spike | Auth service metrics | Platform team | PagerDuty |
| Data exfiltration detection | DLP tool | Security team | PagerDuty |
| Third-party notification | (Vendor contacts us) | Security email | security@{{DOMAIN}} |
| User-reported | Support ticket | Support team | Escalate to security |
| Penetration test finding | External pen tester | Security team | Direct report |
| Vulnerability scanner | {{SCANNER}} | Platform team | Slack #security-alerts |
24/7 security contact: {{SECURITY_PHONE}} | {{SECURITY_EMAIL}} Escalation pager: {{PAGERDUTY_SERVICE}}
3. Response Team Roles & Contacts
| Role | Primary | Backup | Phone | |
|---|---|---|---|---|
| Incident Commander | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
| Security Lead | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
| Engineering Lead | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
| DPO (GDPR) | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
| Legal Counsel | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
| Communications Lead | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
| Executive Sponsor (CEO/CTO) | {{NAME}} | {{BACKUP_NAME}} | {{PHONE}} | {{EMAIL}} |
External contacts:
| Party | Contact | When |
|---|---|---|
| Supervisory Authority (GDPR) | {{DPA_NAME}}: {{DPA_CONTACT}} | P1 within 72h |
| Cyber insurance | {{INSURER}}: {{CONTACT}} | P1/P2 immediately |
| Forensics firm | {{FIRM}}: {{CONTACT}} | P1 immediately |
| Law enforcement | {{LOCAL_CYBERCRIME_UNIT}} | If criminal activity suspected |
| PR firm | {{FIRM}}: {{CONTACT}} | P1 if media involvement |
4. Response Procedures by Phase
Phase 1: Detection & Identification (0–1 hour)
Goal: Confirm whether a breach occurred and scope it.
Trigger: Security alert, user report, or suspicious activity detected.
Step 1.1 — ALERT RECEIVED
□ Log initial alert time: ________________
□ Assign to on-call security engineer
□ Create incident channel: #incident-{{DATE}}-{{N}}
□ Start incident log (chronological — everything goes in the log)
Step 1.2 — INITIAL ASSESSMENT (within 30 minutes)
□ What triggered the alert?
□ Is this a false positive? (if YES → close P4, document)
□ What systems are affected?
□ Is the attack/leak ongoing?
□ Initial data categories potentially affected?
Step 1.3 — CLASSIFY INCIDENT
□ Assign severity: P1 / P2 / P3 / P4
□ Notify Incident Commander
□ If P1/P2: Activate full IRT immediately (page all roles)
□ If P3/P4: Notify Security Lead
Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — do before containment if safe)
□ Take memory dump of affected system(s)
□ Preserve logs — snapshot before any containment changes
□ Document exact system state (screenshots, commands run)
□ Isolate but DO NOT wipe affected systems until forensics complete
Exit criteria: Incident classified, IRT assembled, evidence preserved.
Phase 2: Containment (1–4 hours)
Goal: Stop the bleeding. Prevent further data exposure.
Step 2.1 — IMMEDIATE CONTAINMENT
□ Isolate affected systems (network segment or shutdown if necessary)
□ Revoke compromised credentials (API keys, user accounts, OAuth tokens)
□ Block malicious IP addresses at WAF/firewall
□ Disable vulnerable endpoint or feature if applicable
□ If active exfiltration: cut network connection to affected service
Step 2.2 — ASSESS CONTAINMENT IMPACT
□ What services are affected by containment actions?
□ Communicate service impact to support team
□ Assess whether customers need to be warned of temporary degradation
Step 2.3 — PREVENT LATERAL MOVEMENT
□ Rotate all credentials on affected systems (assume all compromised)
□ Check for persistence mechanisms (new users, scheduled tasks, webhooks)
□ Verify backup/DR systems are not also compromised
□ Review access logs for other potentially compromised accounts
Step 2.4 — SCOPE ASSESSMENT
□ Which data was accessed/exfiltrated? (query audit logs)
□ Which data subjects are affected? (query: SELECT COUNT(*) affected)
□ What time period does the breach cover? (from: ___ to: ___)
□ Was data exfiltrated externally, or accessed internally?
□ Draft scope statement for legal/DPO review
Exit criteria: Active threat contained, no ongoing exfiltration, scope defined.
Phase 3: Eradication (4–24 hours)
Goal: Remove the root cause. Ensure the attacker is completely out.
Step 3.1 — ROOT CAUSE ANALYSIS
□ How did the attacker gain access? (entry vector)
□ What vulnerability was exploited?
□ How long did the attacker have access?
□ What was the full extent of access?
□ Were other systems accessible from the compromised system?
Step 3.2 — REMEDIATE ROOT CAUSE
□ Apply security patch or configuration fix
□ Remove malware or attacker-installed tools
□ Remove unauthorized accounts or access grants
□ Fix the vulnerability that enabled the breach
Step 3.3 — FORENSIC PRESERVATION
□ Hand forensic images to {{FORENSICS_FIRM}} or internal team
□ Maintain chain of custody documentation
□ Do not alter forensic evidence
Step 3.4 — VERIFICATION
□ Verify root cause has been eliminated
□ Security team confirms no persistence mechanisms remain
□ Review similar systems for same vulnerability
Exit criteria: Root cause identified and eliminated. No attacker persistence.
Phase 4: Recovery (24–72 hours)
Goal: Restore systems to full operation safely.
Step 4.1 — SAFE RESTORATION
□ Restore systems from known-good backup or rebuild from IaC
□ Deploy with enhanced monitoring
□ Rotate ALL credentials across affected systems (not just compromised ones)
□ Verify data integrity (compare against backups)
□ Re-enable services in stages (not all at once)
Step 4.2 — ENHANCED MONITORING
□ Increase logging verbosity on recovered systems for 30 days
□ Set up specific alerts for repeat attack patterns
□ Daily security review for 7 days post-recovery
Step 4.3 — STAKEHOLDER UPDATES
□ Update incident channel with recovery progress
□ Brief executive team
□ Prepare customer communication (if applicable)
□ Internal announcement of resolution
Exit criteria: Systems operational. Enhanced monitoring in place. No re-infection.
Phase 5: Post-Incident (72 hours – ongoing)
Goal: Learn from the incident. Prevent recurrence. Meet legal obligations.
Step 5.1 — POST-MORTEM (within 5 business days)
□ Schedule post-mortem meeting (blameless culture)
□ Complete timeline of events
□ Root cause analysis (5 Whys)
□ What went well?
□ What failed?
□ Action items with owners and deadlines
□ Publish post-mortem report
Step 5.2 — REGULATORY COMPLIANCE
□ Supervisory authority notification (if GDPR — see §5)
□ Data subject notifications (if required — see §5)
□ Contractual notifications (customer DPAs)
□ Insurance claim filed
Step 5.3 — REMEDIATION TRACKING
□ All action items in issue tracker with deadlines
□ Weekly review of remediation progress for 4 weeks
□ Confirm all actions closed
□ Update threat model with new attack vector
Step 5.4 — POLICY UPDATE
□ Update this response plan based on lessons learned
□ Update security architecture documentation
□ Update team training materials
□ Add scenario to next incident response drill
5. Notification Requirements
5.1 GDPR — Supervisory Authority Notification (72 hours)
Legal basis: GDPR Art. 33
Timeline: Within 72 hours of becoming aware of the breach (not when confirmed — when aware)
Required only if: Breach is likely to result in a risk to rights and freedoms of natural persons
What to report:
- Nature of the breach (categories, approximate number of data subjects, approximate number of records)
- Contact details of DPO
- Likely consequences of the breach
- Measures taken or proposed to address the breach
Partial notification allowed: If full information not available within 72 hours, submit what's known and supplement later.
5.2 GDPR — Data Subject Notification
Legal basis: GDPR Art. 34
Required if: Breach is likely to result in HIGH risk to data subjects
Timeline: Without undue delay
Communication method: Direct (email to affected users) — no mass public announcement unless direct communication impossible
Template: See §6.2
Not required if: Data was encrypted and key not compromised; OR post-breach measures ensure high risk no longer likely; OR disproportionate effort (→ public communication instead)
5.3 Contractual Obligations
| Obligation | Parties | Timeline | Method |
|---|---|---|---|
| Customer DPA notification | Enterprise customers with DPAs | {{CONTRACTUAL_TIMELINE}} | Direct email from Account Manager |
| Partner notification | {{PARTNER_TYPES}} | {{TIMELINE}} | Direct email |
| Insurance notification | {{INSURER}} | {{TIMELINE}} | Phone + email |
5.4 Law Enforcement
When to notify: If criminal activity is suspected (ransomware, deliberate intrusion) Contact: {{LOCAL_CYBERCRIME_UNIT}} Caution: Coordinate with legal counsel before contacting law enforcement — evidence preservation requirements apply.
6. Communication Templates
6.1 Internal Incident Alert
Subject: [INCIDENT P{{SEVERITY}}] Security Incident — {{DATE}} {{TIME}}
Team,
We have identified a security incident. Details:
Incident ID: INC-{{DATE}}-{{N}}
Severity: P{{SEVERITY}}
Detected: {{DATE}} {{TIME}} UTC
Status: ACTIVE — Containment in progress
Incident Commander: {{NAME}}
Incident channel: #incident-{{DATE}}-{{N}}
Do NOT discuss this incident on public channels, with customers, or on social media.
All communications go through {{COMMUNICATIONS_LEAD}}.
Next update: {{TIME}} UTC
6.2 Data Subject Notification Template
Subject: Important security notice about your account
Dear {{FIRST_NAME}},
We are writing to inform you of a security incident that may have affected your account.
What happened:
On approximately {{DATE}}, we became aware of unauthorized access to our systems that
may have exposed some of your personal information.
What information was involved:
The following information may have been accessed: {{DATA_CATEGORIES}}
What we are doing:
We have [taken/are taking] the following steps to address this incident:
- {{ACTION_1}}
- {{ACTION_2}}
What you should do:
- Change your password at {{URL}}
- Enable two-factor authentication
- Monitor your accounts for suspicious activity
- [If financial data: Monitor your bank statements / Contact your bank]
For more information:
Contact our Data Protection Officer: {{DPO_EMAIL}}
Privacy notice: {{PRIVACY_POLICY_URL}}
We take the security of your information seriously and sincerely apologize for any
concern this may cause.
Regards,
{{COMPANY_NAME}}
Data Protection Officer: {{DPO_NAME}}
6.3 Regulatory Notification Draft
To: {{DPA_AUTHORITY}}
From: {{DPO_NAME}}, DPO — {{ORG_NAME}}
Date: {{DATE}} {{TIME}} UTC
NOTIFICATION OF PERSONAL DATA BREACH (GDPR Art. 33)
1. Nature of the breach:
On {{DATE}}, we became aware of [unauthorized access to / accidental disclosure of]
personal data. The breach [is/was] {{ONGOING/CONTAINED}}.
2. Categories and approximate number of data subjects concerned:
- Categories: {{DATA_CATEGORIES}}
- Estimated affected data subjects: {{NUMBER}}
- Estimated affected records: {{NUMBER}}
3. Categories and approximate number of personal data records concerned:
{{RECORD_CATEGORIES_AND_COUNTS}}
4. Contact details of DPO:
Name: {{DPO_NAME}}
Email: {{DPO_EMAIL}}
Phone: {{DPO_PHONE}}
5. Likely consequences of the breach:
{{CONSEQUENCES}}
6. Measures taken or proposed:
- Immediate: {{IMMEDIATE_MEASURES}}
- Ongoing: {{ONGOING_MEASURES}}
- Planned: {{PLANNED_MEASURES}}
7. Note: This is a [complete / preliminary — supplementary notification to follow] report.
[DPO Signature]
7. Evidence Preservation Procedures
Principle: COLLECT BEFORE CONTAIN — evidence collection takes priority over containment unless ongoing harm is severe.
Evidence collection checklist:
□ Memory dump: strings /proc/{{PID}}/mem > evidence/memory-{{TIMESTAMP}}.dump
□ Network traffic: tcpdump -w evidence/traffic-{{TIMESTAMP}}.pcap
□ Running processes: ps aux > evidence/processes-{{TIMESTAMP}}.txt
□ Open connections: netstat -an > evidence/connections-{{TIMESTAMP}}.txt
□ System logs: cp -r /var/log/ evidence/system-logs-{{TIMESTAMP}}/
□ Application logs: {{LOG_COLLECTION_COMMAND}}
□ Database audit log: {{DB_AUDIT_EXPORT_COMMAND}}
□ Cloud provider logs: {{CLOUD_LOG_EXPORT_COMMAND}} (CloudTrail, Azure Monitor, etc.)
□ SIEM events: Export 30-day window around incident
Chain of custody:
- All evidence files: SHA-256 hash computed and recorded immediately after collection
- Hash log: evidence/chain-of-custody.txt — signed by collector
- Storage: Write-protected encrypted volume, access logged
- Custody transfers: Documented with signatures
8. Forensic Analysis Requirements
| Incident Level | Forensic Approach | Provider |
|---|---|---|
| P1 (Critical) | External forensics firm engaged immediately | {{FORENSICS_FIRM}} — {{CONTACT}} |
| P2 (High) | Internal forensics + external if complex | Internal first, escalate if needed |
| P3 (Medium) | Internal log analysis | Security team |
| P4 (Low) | Root cause review | Security engineer |
Forensics firm retainer: {{RETAINER_STATUS}} — {{FIRM}} ({{CONTACT}}) Evidence retention: All forensic evidence retained for minimum {{RETENTION_PERIOD}} post-incident
9. Lessons Learned Process
Post-mortem template: {{LINK_TO_POSTMORTEM_TEMPLATE}} Deadline: Within 5 business days of incident closure
Mandatory post-mortem components:
- Complete incident timeline (minute-by-minute)
- Root cause analysis (5 Whys or fishbone diagram)
- What went well (preserve these practices)
- What went poorly (specific improvement areas)
- Action items (specific, assigned, time-bound)
- Detection gap analysis (how long before detection?)
- Response gap analysis (where did we slow down?)
- Prevention roadmap (systemic fixes)
Action item tracking: All items in {{ISSUE_TRACKER}} labeled security-incident-followup
10. Drill Schedule
| Drill Type | Frequency | Participants | Scenario |
|---|---|---|---|
| Tabletop exercise | Quarterly | Full IRT + management | Ransomware / Data breach / Insider threat |
| Notification drill | Semi-annual | DPO + Legal + Communications | 72-hour GDPR notification dry run |
| Technical response drill | Annual | Engineering + Security | Live simulation on isolated environment |
| Communication tree test | Annual | All IRT members | Phone chain + escalation path verification |
Last drill: {{DATE}} — Scenario: {{SCENARIO}} — Outcome: {{OUTCOME}} Next drill: {{DATE}} Drill coordinator: {{NAME}} ({{EMAIL}})
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | |||
| DPO | |||
| CISO | |||
| Legal Counsel | |||
| CEO |