Data Breach Response Playbook

Overview

A data breach plays by different rules. Someone copied data they shouldn’t have, customers may hear about it before you finish your first call, and regulators start counting the moment you confirm it happened, whether you’re ready or not. The first 24 hours decide whether it stays a contained incident or turns into a headline and a fine.

This playbook gives you a phased response: confirm and contain first, preserve evidence and investigate next, notify who the law says you must, then remediate and learn. Every phase ends in checkboxes with owners, because the thing that fails under pressure is rarely the plan. It’s remembering who does what.

If the incident is about availability, not data (a DDoS, a dead cluster), this is the wrong tool. The incident response guide covers general production incidents; use this playbook only when unauthorized data access is confirmed or credibly suspected.

When to Use

Activate this playbook when:

• Unauthorized access to sensitive data has been detected or credibly suspected: a DLP alert, a honeypot file touched, an unusual bulk export
• A system containing PII, PHI, financial data, or credentials has been compromised
• An insider has exfiltrated data without authorization
• A third-party vendor with access to your data reports a breach affecting your records
• Ransomware has encrypted data or threatens to publish it. Most modern ransomware exfiltrates before it encrypts

Don’t activate it for a vulnerability that could lead to a breach but hasn’t been exploited. That belongs in your normal patch and vulnerability workflow, and treating it like a breach burns legal review time you may need later.

Prerequisites

Reading this mid-breach? Skip ahead and improvise around whatever’s missing. If you’re reading it calmly, get these in place now; each one saves hours later:

• Legal counsel has reviewed notification requirements (GDPR, CCPA, state laws, contracts)
• A forensics contact or retainer is in place
• An incident response team with roles (lead, legal, comms, technical) is defined
• Contact lists for regulators, customers, and media are current
• Data inventory maps where sensitive data lives and who has access

The two that hurt most when missing are the legal review and the forensics retainer. Calling a law firm for the first time at hour 60 of a GDPR clock is expensive and slow. Same for forensics: firms with retainers answer the phone; firms without one get put in a queue.

Solution

# Data Breach Response Playbook

> Playbook owner: ______ | Last updated: ______
> Incident response team: ______ | Legal contact: ______

## Phase 1: Detection and Assessment (0-2 hours)

### Immediate actions

- [ ] Confirm the breach is real (rule out false positive)
- [ ] Document the initial indicator: time, source, type of alert
- [ ] Classify data involved: PII, PHI, financial, credentials, intellectual property, other
- [ ] Estimate number of records or users affected
- [ ] Assign incident commander and roles
- [ ] Open a secure, restricted communication channel (not the general incident channel)

### Decision: does this trigger notification requirements?

| Jurisdiction | Trigger | Timeline | Notes |
|-------------|---------|----------|-------|
| GDPR | Personal data compromised | 72 hours to supervisory authority | ______ |
| CCPA / CPRA | Personal info accessed without authorization | Without unreasonable delay | ______ |
| State laws (US) | Varies by state | Varies | ______ |
| Contractual | Defined in DPA or MSA | Defined in agreement | ______ |

## Phase 2: Containment (2-24 hours)

### Technical containment

- [ ] Isolate compromised systems (do not power off — preserve volatile memory)
- [ ] Revoke compromised credentials and sessions
- [ ] Block unauthorized IPs or accounts at firewall / WAF level
- [ ] Disable compromised API keys or service accounts
- [ ] Rotate all secrets that may have been exposed
- [ ] Preserve logs, snapshots, and disk images before cleanup

### Administrative containment

- [ ] Restrict access to incident details to need-to-know personnel
- [ ] Pause non-essential deployments or changes
- [ ] Brief executive leadership on scope and response status

## Phase 3: Evidence Preservation and Investigation (24-72 hours)

- [ ] Engage forensics team (internal or external)
- [ ] Create forensic images of affected systems
- [ ] Collect and preserve logs: application, database, network, access, audit
- [ ] Document chain of custody for all evidence
- [ ] Build timeline of attacker activity: initial access, lateral movement, data access, exfiltration
- [ ] Identify root cause: vulnerability, misconfiguration, credential theft, insider threat, third-party compromise

## Phase 4: Notification (per legal timeline)

### Internal notification

- [ ] Board / executive leadership
- [ ] Legal counsel
- [ ] Insurance provider (cyber liability)
- [ ] HR (if insider threat suspected)

### External notification

- [ ] Regulatory bodies (per applicable law)
- [ ] Affected customers / users
- [ ] Partners or vendors if their data was involved
- [ ] Law enforcement (if required or advisable)

### Notification content checklist

- [ ] What happened
- [ ] What data was involved
- [ ] What steps were taken to contain the breach
- [ ] What steps affected individuals should take
- [ ] Contact information for questions
- [ ] What the organization is doing to prevent recurrence

## Phase 5: Remediation and Recovery (1-4 weeks)

- [ ] Patch or fix the root cause vulnerability
- [ ] Remove attacker persistence mechanisms (backdoors, accounts, scheduled tasks)
- [ ] Rebuild compromised systems from known-good sources if integrity is uncertain
- [ ] Re-enable systems with enhanced monitoring
- [ ] Verify no unauthorized access persists
- [ ] Conduct a security review of affected systems
- [ ] Update security controls: MFA, segmentation, logging, alerting

## Phase 6: Post-Incident (2-4 weeks)

- [ ] Conduct a blameless postmortem (see postmortem template)
- [ ] Track and complete all remediation action items
- [ ] Review and update this playbook based on lessons learned
- [ ] Review data inventory and access controls
- [ ] Update risk assessment and insurance coverage if needed
- [ ] Publish a transparent summary to affected parties (as appropriate)

## Roles and Responsibilities

| Role | Responsibilities | Primary | Backup |
|------|------------------|---------|--------|
| Incident Commander | Primary coordination, decision authority, stakeholder updates | ______ | ______ |
| Technical Lead | Containment, forensics, remediation | ______ | ______ |
| Legal Counsel | Notification requirements, regulatory compliance, privilege | ______ | ______ |
| Communications Lead | Customer, media, and internal messaging | ______ | ______ |
| HR Representative | Insider threat, employee impact | ______ | ______ |

## Contact List

| Party | Contact | Method | Notes |
|-------|---------|--------|-------|
| Legal counsel | ______ | ______ | ______ |
| Cyber insurance | ______ | ______ | ______ |
| Forensics firm | ______ | ______ | ______ |
| Law enforcement | ______ | ______ | ______ |
| Regulatory body | ______ | ______ | ______ |

Explanation

The phases match the pressure curve of a breach. Hours 0-24 are about confirming it’s real and stopping the bleeding; days 1-3 are about understanding what happened and preserving proof; the following weeks are about fixing the hole and closing the loop with the people you had to tell.

Two decisions in the template matter more than they appear to. First, the restricted channel: assume the attacker can read your usual incident room. If the breach touched mail or chat infrastructure, move coordination out-of-band entirely. Second, the notification matrix: missing a legal deadline turns a security incident into a regulatory penalty, and the deadlines are short. GDPR’s 72 hours is the strictest common one, so most teams use it as the default clock and let counsel relax it if the law doesn’t apply.

Evidence-first containment is the other non-obvious choice. Isolating a machine is right; wiping is wrong. Volatile memory, login sessions, and running processes vanish on shutdown, and logs get rotated out on their own schedule. Capture before you clean, or your own forensics team, and later your lawyers, will have nothing to work with.

Finally, the roles table exists because group ownership is no ownership. When three people think someone else called the insurer, nobody calls the insurer.

The 72-Hour Clock: A GDPR Scenario

Walk one scenario to see why the phases go in this order. Picture a Tuesday at 09:00: account data from European customers surfaces in a public paste.

• 09:00-11:00. The on-call engineer confirms the paste is real data, not a recycled dump, and opens the restricted channel. The incident commander classifies it: personal data of EU residents. The GDPR clock just started.
• 11:00-day 2. The compromised service account is revoked, the export endpoint is rate-limited and then disabled, and snapshots of the affected hosts are taken before anything is rebuilt. Leadership gets a two-line brief: what we know, what we don’t.
• Day 2-3. Forensics builds the timeline: attacker came in through a leaked API key, read the export endpoint for six days, took ~40,000 records. Counsel confirms notification is required: personal data, confirmed access, likely risk to individuals.
• Before 72 hours. Notify the supervisory authority with whatever is known by then. GDPR asks for timeliness, not completeness. Affected customers get the email from the template below. The postmortem and full remediation continue for weeks, but the legal clock is already satisfied.

Notice what didn’t happen: nobody waited for perfect certainty about scope before deciding to notify. “We detected unauthorized access to personal data and are investigating” is a complete and compliant notification when the facts are still forming.

Breach Response Communication Templates

Three rules before you send anything from this section: one spokesperson, legal review of every external message, and no speculation. Write only what you know and what you’re doing; never guesses about the attacker or how bad it might get. If the incident communication template is already in use at your org, merge its structure into these; the breach-specific fields are the ones that matter.

=== Internal: Initial Breach Alert (Slack/Email) ===

SUBJECT: [SEV-SECURITY] Suspected data breach — [SYSTEM]

Incident commander: [NAME]
Bridge: [PHONE/VIDEO LINK]
Status: Investigating
Summary: [BRIEF DESCRIPTION — what was detected, when, by whom]
Impact: [UNKNOWN / CONFIRMED — what systems/data may be affected]
Next steps: [CONTAINMENT / FORENSICS / NOTIFICATION]

Do NOT discuss details in public channels.
Use the incident bridge and #sec-incident-private only.

=== External: Customer Notification Email ===

Subject: Important Security Notice — [COMPANY NAME]

Dear [CUSTOMER_NAME],

We are writing to inform you of a security incident that may have
affected your account information. We discovered the incident on
[DATE] and took immediate action to secure our systems.

What happened:
  [BRIEF, NON-TECHNICAL DESCRIPTION]

What data was involved:
  [LIST OF DATA TYPES — e.g., name, email, hashed password]

What we have done:
  - Contained the breach and secured affected systems
  - Engaged forensic investigators and notified authorities
  - [ADDITIONAL STEPS]

What you should do:
  - Change your password immediately
  - Enable two-factor authentication
  - Monitor your account for suspicious activity
  - [ADDITIONAL RECOMMENDATIONS]

We take the security of your data seriously and apologize for any
concern this may cause. We will provide updates as we learn more.

Contact: [SUPPORT_EMAIL / DEDICATED PHONE]

[COMPANY_NAME] Security Team

=== External: Status Page Update ===

[INVESTIGATING] We are investigating a security incident affecting
[SYSTEM]. We have taken affected systems offline and are working to
determine the scope. We will update this page every [INTERVAL] until
resolved.

[IDENTIFIED] We have identified the cause of the security incident
and contained the threat. Affected systems are being restored with
enhanced security measures. We will notify affected users directly.

[RESOLVED] The security incident has been resolved. All affected
systems are secure and operational. A detailed post-incident report
will be published on [DATE].

Variants

Context	Adjustments	Notes
Cloud provider breach	Add cloud incident response team contact, shared responsibility review, and provider notification	You and the provider may both have obligations
Insider threat	Add HR involvement, access log review, and employment law considerations	Insider cases have different legal and HR implications
Third-party vendor breach	Add vendor DPA review, vendor notification requirements, and dependency assessment	Your data on their systems is still your responsibility
Ransomware	Add payment policy, backup restoration plan, and law enforcement engagement	Paying ransom is a business and legal decision
Small startup (no dedicated security team)	Add external security firm engagement steps and simplified role assignments	Speed matters more than completeness when you’re small

The vendor-breach row deserves emphasis because teams get it wrong in both directions: they either assume the vendor’s notification covers them (it doesn’t — you’re the data controller) or they notify before confirming which of their records were actually exposed. Pull the DPA, get the vendor’s incident report, then decide.

What Works

1. Practice the playbook. Run a tabletop exercise quarterly: pick a scenario, walk the phases, note where it breaks. A playbook you’ve never used is a liability
2. Preserve before you clean. Forensics depends on evidence; containment that destroys logs makes root cause analysis impossible
3. Bring in legal early. Attorney-client privilege can protect investigation findings from discovery in litigation
4. Document in real time. Memories distort under pressure; a running log beats recollection in front of a regulator
5. Don’t promise what you can’t verify. If you don’t know the scope yet, say so. Overstating confidence destroys credibility when the numbers come out

Common Mistakes

1. Shutting systems down immediately. You lose volatile memory and logs. Isolate, don’t power off
2. Notifying too early or too late. Early notification without facts causes panic; late notification causes regulatory penalties. The matrix exists to pace this decision
3. Skipping evidence preservation. Without evidence you can’t prove what happened, defend against lawsuits, or learn
4. Coordinating over compromised channels. Assume the attacker is reading your incident chat; use out-of-band communication from the first hour
5. Declaring victory at containment. The breach isn’t over when the attacker is out. It’s over when the system is demonstrably safer and the remediation list is done

Troubleshooting

• The attacker is still inside after credential rotation: rotate in waves: service accounts, refresh tokens, and active sessions too, not just user passwords. Persistent sessions often survive a password reset.
• Logs already rotated out: check SIEM and backup retention before declaring the scope. Pull from archives where possible and record the gap in the timeline: “we don’t know” documented is better than a guess.
• A vendor won’t share forensic details: escalate through the breach clauses in your DPA, and document their refusal. Your notification obligations are yours regardless of their cooperation.
• Legal counsel is unreachable on a weekend: the GDPR deadline doesn’t wait for Monday. Keep an on-call escalation path in the contact list, not a single person’s number.
• Insurance requires their own forensics firm: check the policy before engaging yours. Using an unapproved firm can void coverage for the investigation.

Keeping the Playbook Current

A breach playbook goes stale faster than most documents: people leave, vendors change, laws update. Review it quarterly alongside the tabletop exercise, and treat the contact list as the part that rots first. After any real incident, update it while the postmortem is fresh; the incident postmortem template pairs with this playbook for that step.

Keep it under version control with a named owner, and keep a copy somewhere that survives a compromise of your chat and email. An offline copy has pulled real responses out of the fire before.

See Also

• GDPR Art. 33 — notification to the supervisory authority and Art. 34 — communication to data subjects
• HHS — HIPAA Breach Notification Rule
• NIST SP 800-61r2 — Computer Security Incident Handling Guide
• PCI Security Standards Council — document library
• Incident response guide for non-breach production incidents
• GDPR compliance guide for the broader data-protection program
• Companion repository: breach playbook + notification templates