The Problem: Why This Matters Now
Your incident response plan might be tucked away in a SharePoint folder, labeled something like "IR_Plan_v3_FINAL_updated.docx". When Manchester Airports Group faced a breach, exposing customer data across three airports, they had to act fast. They disabled services, brought in advisers, and notified authorities. But does your plan specify who decides to take revenue-generating services offline, what notifying authorities looks like at 2 a.m., or how your team handles panicked customer calls while you're still investigating?
The gap between having a plan and executing it under pressure is where reputational damage occurs. Your first 72 hours determine whether customers see you as transparent and competent or evasive and incompetent. This playbook guides you through the real-world execution of breach response, not just compliance.
What You Need Before Starting
You can't build this during an incident. These prerequisites must exist now:
Decision Authority Matrix: A single-page document listing who can authorize service shutdowns, external communications, authority notifications, and legal counsel engagement. Include backup contacts for each role. If your DPO is on holiday, who steps in? If your CISO is unreachable, does the CTO have authority to disable customer-facing systems?
Technical Inventory with Retention Schedules: A spreadsheet listing every system processing personal data, what categories it holds (contact details, payment information, location data), where logs are stored, and your Article 30 retention period for each. When you discover a breach, you need to know within 30 minutes what data was potentially exposed.
Pre-drafted Notification Templates: Three versions of customer notification emails (high severity, medium severity, precautionary), a supervisory authority notification template that maps to Article 33 requirements, and a holding statement for your website. Don't write from scratch at 3 a.m.
Communication Channels That Bypass Compromised Systems: If your email infrastructure is breached, how do you notify customers? Set up an alternative SMS gateway or maintain a secondary email domain specifically for incident communications.
External Specialist Retainer: Have a pre-negotiated contract with a forensics firm that can be on-site or remote within 4 hours. Negotiating rates during an active incident wastes time you don't have.
Step-by-Step Implementation
Hour 0-2: Containment and Initial Assessment
Your first action isn't investigation; it's stopping the bleeding. When you confirm unauthorized access, immediately:
Isolate affected systems from the network. Don't wait for full scope confirmation. If you suspect customer data exposure, assume the attacker still has access until you prove otherwise.
Preserve logs before they rotate. Copy authentication logs, access logs, and system logs to write-once storage. Your Article 33 notification to the supervisory authority requires describing "the nature of the personal data breach". You can't do that if logs have overwritten themselves.
Convene your response team via your backup communication channel. Don't use the potentially compromised email system to coordinate your response to the email system being compromised.
Hour 2-12: Scope Determination
You need three specific pieces of information for your supervisory authority notification:
- Categories of data subjects affected
- Categories of personal data compromised
- Approximate number of affected individuals
Your technical inventory should let you answer these questions by querying system logs. If the compromised database served your parking booking system, your retention schedule tells you how far back records go. Cross-reference access logs with data categories to build your Article 33 notification.
Hour 12-72: Notification Execution
Article 33 requires notification to your supervisory authority within 72 hours of becoming aware of the breach. "Becoming aware" means when you have sufficient information to conclude a breach occurred, not when you've completed your investigation.
Your notification must include the nature of the breach, categories and approximate numbers of affected individuals, likely consequences, and measures taken or proposed. If you don't yet have approximate numbers, submit what you know and explain you'll provide additional information as it becomes available.
For customer notification under Article 34, you're required to notify without undue delay if the breach is likely to result in a high risk to individuals' rights and freedoms. Email addresses and phone numbers exposed to attackers who can use them for phishing attacks likely cross that threshold.
Your customer notification should:
- Explain what happened in plain language
- Specify exactly what categories of their data were exposed
- State clearly what was NOT exposed
- Provide concrete protective actions they should take
- Include a direct contact method for questions
Hour 72+: Service Restoration and Evidence Preservation
Before bringing systems back online:
- Confirm the entry vector is closed. If you don't know how they got in, you haven't closed it.
- Reset credentials for all accounts that had access to compromised systems.
- Implement additional monitoring on restored systems. You're watching for the attacker's return.
Keep complete records of your response actions, decisions made, and timing. Your supervisory authority may audit your response, and you'll need to demonstrate you acted promptly and appropriately.
Validation: How to Verify It Works
Test your plan with a tabletop exercise quarterly. Don't announce it. On a random Tuesday morning, tell your DPO "we've detected unauthorized access to the customer database, logs show data exfiltration started 6 hours ago". Watch what happens.
Time how long it takes to:
- Assemble your response team
- Isolate the affected system
- Determine what data was potentially exposed
- Draft your supervisory authority notification
- Prepare customer notification
If any step takes longer than your plan assumes, you've found your bottleneck.
Maintenance and Ongoing Tasks
Monthly: Verify your decision authority matrix is current. People change roles.
Quarterly: Update your technical inventory when new systems launch or old ones are decommissioned.
Annually: Refresh your external specialist retainer and review your notification templates against current supervisory authority guidance.
After Every Incident (Yours or Others'): Conduct a post-incident review. Ask: could we determine within 12 hours what data categories were exposed? Could we take a revenue-generating service offline if necessary? Could we notify affected customers directly if our primary email system was compromised?
Your breach response plan isn't just a compliance document. It's an operational playbook you'll execute under the worst possible conditions. Build it for that reality.
