Your incident response plan looks solid on paper. It passed the annual audit. It ticks the ISO 27001 Annex A.5.24 box. But when ransomware locks your systems at 2am on a Saturday, that document becomes worthless within minutes. The 72-hour GDPR notification window starts counting down, and suddenly your team discovers the plan doesn't include current contact details, assumes systems that no longer exist, or relies on a manager who left six months ago.
Article 33 of the UK GDPR is unambiguous: personal data breaches must be reported to the ICO within 72 hours of becoming aware of them — unless you can demonstrate the breach is unlikely to result in a risk to individuals. Miss that window without good reason, and you're already on the back foot before the ICO even examines the breach itself. The notification failure becomes its own compliance violation, separate from whatever caused the incident.
Most incident response plans fail not because they're poorly written, but because they've never been tested under realistic pressure. The gap between documentation and execution is where breaches become disasters.
What Actually Happens in the First 72 Hours
The ICO's guidance on breach reporting makes clear that the 72-hour clock starts when your organisation has a "reasonable degree of certainty" that a breach has occurred. Not when you've completed your investigation. Not when legal has reviewed the facts. The moment your security team confirms something is wrong, time starts.
In those first hours, your team must simultaneously contain the incident, preserve forensic evidence, assess whether personal data is affected, determine the scope and severity, draft a notification to the ICO, and decide whether to notify affected individuals directly under Article 34. That's a lot to coordinate when your systems are compromised and your team is working from mobile phones because email is down.
The common failure mode isn't ignorance — it's friction. The incident response plan says "contact the Data Protection Officer" but doesn't specify their personal mobile number. It references "the backup system" without naming which of your three backup solutions applies to which data. It assumes your SIEM will provide logs, but nobody tested whether those logs are actually retained for long enough to be useful.
Why Most IR Tabletop Exercises Miss the Point
Running an IR tabletop exercise once a year to satisfy audit requirements is better than nothing, but only marginally. The typical exercise involves senior stakeholders sitting in a conference room, walking through a hypothetical scenario at a comfortable pace, with IT available to answer questions. That bears almost no resemblance to a real incident.
Effective tabletop exercises must introduce realistic constraints. What happens when your primary incident commander is on annual leave? When the attacker has compromised your communication tools? When the breach is discovered at 6pm on Friday and half your team is unreachable? When the person who knows the backup recovery process is the same person whose credentials were compromised?
The point of the exercise isn't to prove the plan works. It's to discover where the plan breaks. Every failure during a tabletop is a failure you won't experience during a real incident — if you fix it. Document every assumption that didn't hold, every contact detail that was wrong, every handoff that caused confusion. Then update the plan and test again.
Practical Steps to Close the Gap
First, separate your incident response documentation from your corporate network. If ransomware encrypts your SharePoint, and your IR plan lives on SharePoint, you've already lost. Maintain offline copies — printed runbooks, a secure cloud location with separate credentials, or both. Your IR plan should be accessible when everything else isn't.
Second, build your plan around roles, not names. People leave. People go on holiday. Your plan should specify "Incident Commander" with clear criteria for who fills that role, not "John Smith, Head of IT." Maintain a current contact list separately, updated monthly, with personal mobile numbers and secondary contacts for every critical role.
Third, define your 72-hour notification threshold clearly. The GDPR requires notification unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons." That's a judgement call, and you don't want to be making it for the first time at 3am. Pre-define categories: if X type of data is affected, we notify. If the breach affects more than Y individuals, we notify. Remove ambiguity before the pressure hits.
Fourth, test your breach response in the UK context specifically. If you operate across jurisdictions, your UK notification goes to the ICO. Your EU notification (if applicable) goes to the relevant supervisory authority. Don't let jurisdictional confusion add hours to your response time.
Common Mistakes That Guarantee Failure
The most dangerous mistake is assuming your plan works because it's comprehensive. Length is not quality. A 50-page document that nobody can navigate under pressure is worse than a 5-page runbook with clear decision trees and current contacts.
Another failure: treating the IR plan as a security team document. Incident response involves legal, communications, HR, senior leadership, and potentially external counsel. If those stakeholders haven't participated in exercises, they'll slow you down when it matters. The NCSC's guidance on incident management explicitly emphasises cross-functional coordination.
Finally, don't confuse detection with response. Having a SIEM that alerts on anomalies is detection. Having a tested process for what happens after that alert — who triages it, who escalates it, who makes the call that this is a breach — is response. Many organisations invest heavily in the former and neglect the latter.
How Pyralink Helps
Pyralink delivers incident response readiness that survives contact with reality. Our vCISO service, starting at £497 per month, includes structured IR tabletop exercises designed to stress-test your plan under realistic conditions — not tick a compliance box. We identify the gaps before attackers do.
For organisations managing cloud infrastructure, CloudAuditX provides continuous visibility across AWS, Azure, and GCP, ensuring your IR team has accurate, current information about your environment when an incident occurs. No more assumptions about which systems hold what data.
Pyralink holds £5M professional indemnity insurance and is led by Michael Adedeji (CISM, CISA, CC, MSc Data Science). We've built and tested incident response programmes in production environments — not just reviewed them on paper.
Ready to find out if your IR plan actually works?