Data Breach Response Checklist

Purpose

This checklist turns a breach response plan into a working tool: phases, a severity matrix, an incident log field list, and role assignments — so nobody is guessing what to do at 2am. Assign the roles below to named people and store this checklist somewhere reachable without a working laptop, before you need it.

Pair it with the Data Inventory and RoPA Starter Kit (to know what data/systems are affected) and the Vendor Privacy Assessment Template when a processor is involved. For underlying concepts see Global Data Privacy Fundamentals; to build the response capability, see Practical Privacy Program Implementation. To map broader exposure, use the assessment.

Notification deadlines and thresholds vary by jurisdiction and data type; nothing here is a universal deadline. Confirm current requirements with counsel for every relevant jurisdiction.

How to use it

Work the phases in order, but treat containment as always-on. Make a provisional severity call early and revise it as facts emerge. After the incident, use "learn" to update this checklist itself.

Phase 1: Detect

• Log the exact time and source of detection; assign an incident reference number immediately.
• Limit discussion outside the response team until scope is understood.

Phase 2: Triage

• Convene the response team and appoint one incident coordinator.
• Make a provisional severity call using the matrix below.
• Decide whether outside counsel or a forensic vendor need to be engaged now.

Phase 3: Contain

• Revoke or reset compromised credentials; disable exposed links or shares.
• Isolate affected systems without destroying forensic evidence.
• Preserve logs and configuration before remediation overwrites them.
• Log every containment action with timestamp and owner.

Phase 4: Assess

• What data, whose data, how many individuals/records, which systems?
• Was the data encrypted or otherwise unintelligible to an unauthorised party?
• What is the realistic, evidenced risk of harm — not the worst theoretical case?
• Are processors, sub-processors or partners implicated, and what do their contracts require of them?

Severity matrix (illustrative — calibrate to your organisation)

Review and calibrate tiers with legal and security leadership for your sector and jurisdictions.

Phase 5: Notify

• Apply your documented notification decision criteria (severity, assessed harm, applicable law) and record the reasoning — including a decision not to notify.
• Identify every jurisdiction with a potential duty based on where affected individuals are, and confirm current deadlines and content requirements with counsel for each.
• Draft regulator content: nature of the incident, categories and approximate numbers affected, likely consequences, measures taken.
• Draft individual communication where the risk threshold is met: what happened, what data, what it means, what to do.
• Route external communications through the coordinator for consistency.

Phase 6: Recover

• Confirm systems are clean before restoring full access.
• Monitor for recurrence for an agreed period after containment.
• Support affected individuals (e.g. credential resets) as appropriate to the harm.

Phase 7: Learn

• Run a blameless root-cause review with the response team and system owners.
• Assign corrective actions with named owners and dates; track to closure.
• Update the inventory, the response plan, this checklist and training.

Incident log — fields to capture

• Reference number and severity tier (current and history)
• Time of the event, of detection, and of each key decision
• Detected by (source) and initial reporter
• Systems, data categories, approximate individuals/records affected
• Containment actions, timestamps, owners
• Assessment notes: risk of harm, encryption status, processor involvement
• Notification decisions and reasoning, with dates
• External communications sent, to whom, when
• Root cause and corrective actions, owners and due dates
• Closure date and sign-off

Roles

Worked example (illustrative)

A 120-person logistics company detects that an employee mailbox with customer shipment records (names, addresses, partial payment references) was accessed by an unauthorised party for about six hours before the account was disabled. Triage assigns a provisional "High" tier. Containment resets the credential and reviews forwarding rules. No exfiltration is confirmed but cannot be ruled out. Legal counsel assesses notification duties per jurisdiction, since thresholds and content requirements differ. The reasoning for the interim tier is documented, draft notification content is prepared pending legal advice, and a root-cause review covering forwarding-rule monitoring is scheduled. Illustrative only.

Maintenance and review

• Review the checklist and plan at least annually, and after any real incident or significant near-miss.
• Re-confirm named role holders quarterly.
• Re-validate the severity matrix and notification criteria on entering a new jurisdiction or sensitive data category.
• Table-test the plan at least once a year.

Download formats

• Guidance (Markdown .md) — this page, including the severity matrix and incident log fields.
• Print / Save as PDF — a print-friendly version to keep with your incident response pack.

Nothing here is emailed — each option downloads or prints directly from your browser.