Karl heads up Information Security at Exclaimer, where he’s focused on keeping data secure and ensuring compliance with standards like ISO 27001 and SOC2. With years of hands-on experience, Karl is dedicated to simplifying security processes and staying ahead of potential threats. He’s passionate about using automation and smart practices to strengthen security without adding unnecessary complexity.
Incident response in the age of AI: Why your plan is only as good as your last live simulation
Key takeaway
The UK Cybersecurity and Resilience Bill widens the old NIS perimeter with a new designated critical supplier category, a test based on what you supply, not your size or sector. You don't opt in. You get designated
The Bill runs two clocks from the same moment: an initial notification within 24 hours, a full report within 72. The 72-hour report is the one that actually tests a plan
Just 25% of UK businesses have a formal incident response plan, according to DSIT's Cyber Security Breaches Survey
Average eCrime breakout time is now 29 minutes, according to CrowdStrike's 2026 Global Threat Report, and that clock runs before your detection clock even starts
Fully automated response risks an AI agent making a fast decision without context. The fix is automating detection and escalation so the human decision, when it's needed, takes minutes rather than hours
If it's been more than six months since your last live simulation, one that timed the 72-hour report and not just the 24-hour ping, you have a document, not a tested plan
Preparation is most of the battle. That's true of exams, and it's true of incident response. A plan you've never tested is just a document. The UK Cybersecurity and Resilience Bill is about to make that distinction expensive. The Bill widens the old NIS perimeter to bring in data centers, medium and large managed service providers, large load controllers, and a new category of designated critical supplier. Read that last one twice.
A regulator can designate you a critical supplier if you supply an operator of essential services, if your own systems are load-bearing for that supply, and if your failure would cause meaningful economic or social disruption. Note what's absent from that test. Your size. Your sector. Whether you ever thought of yourself as critical infrastructure. You do not opt in. You get designated, and the obligations arrive with the letter.
Most organizations think a response policy is enough. They're about to find out it isn't, because only a quarter of UK businesses have a formal incident response plan in the first place, according to DSIT's Cyber Security Breaches Survey.
What does genuine readiness actually require?
The Bill sets two clocks running from the same moment. An initial notification within 24 hours. A full report within 72. Copies to the NCSC in parallel. Most coverage fixates on the 24 hours. That's the easy one. Twenty-four hours buys you a heads-up, and a heads-up is a low bar: something has happened, here is roughly what, here is who we are. The 72-hour report is where untested plans come apart, because by then you need scope, impact, cause, and an accountable person willing to put their name to all three.
Readiness actually requires:
Detection — knowing something has happened, rather than assuming a policy document covers it
Severity assessment — someone qualified making a fast, defensible call on scope
Sign-off — an accountable person authorizing regulatory notification, on the record
The Bill cleared the Commons in June 2026 and is now in the Lords. Royal assent is expected this year, but the thresholds that actually determine who's in scope won't arrive until later, through secondary legislation. That's a delay you can use to your advantage. It's a window to prepare in, before you know exactly what you're preparing for.
Three days sounds generous until you've watched a real incident spend the first one arguing about whether it counts as an incident. Organizations have never run this sequence live. They've written it down. Writing it down and doing it under pressure are different skills, and the difference only shows up when it's too late to fix it quietly.
Why is AI making the readiness gap wider?
Attackers are using AI, and they can already move faster than most human response processes. Here is the number that should reframe the conversation.
Average eCrime breakout time, the gap between initial access and lateral movement, fell to 29 minutes in 2025, according to CrowdStrike's 2026 Global Threat Report. The fastest observed was 27 seconds. CrowdStrike attributes the acceleration directly to AI-enabled adversaries, whose activity rose 89% year on year. Put the two clocks next to each other. An attacker needs 29 minutes. You have 24 hours to tell the regulator and 72 to explain yourself.
That sounds like comfortable margin, and it is exactly backwards, because the attacker's 29 minutes happen before your clock starts. By the time you detect anything, they have had their half hour. The instinct is to close that gap with more automation on the defensive side. That instinct is only half right.
Fully automated response creates its own failure mode: an AI agent making a fast decision without the context a human would have caught. The goal isn't matching attacker speed with machine speed everywhere. It's compressing everything either side of the human decision, so that when someone genuinely has to make the call, such as signing off regulatory notification or confirming blast radius, they spend their minutes deciding rather than assembling.
Isn't faster automation the obvious fix?
It's the obvious fix, and it's the wrong one applied on its own. Attackers don't need a human in the loop. Defenders, in most cases, still do. And working out exactly where that human checkpoint has to sit is a harder problem than pointing an AI system at an incident and letting it run.
Speed without judgement produces the wrong call quickly rather than the right call slowly. The organizations that get this right will be the ones that automate detection and escalation aggressively, while keeping a genuine human decision point exactly where it needs to be.
This is not theoretical spend. IBM's Cost of a Data Breach Report 2026 puts the global average breach at $4.99m, up 12% year on year. One in four malicious breaches is now AI-enabled, and those average $6m. AI-driven attacks added roughly $1m to the bill on their own.
What reduces it is boring by comparison. IBM's data has consistently shown that organizations which form an IR team and test the plan pay substantially less than those that do neither, and that testing at least twice a year is where the saving concentrates. Centralizing ownership of the communications side of that response, including how email disclaimers and compliance notices get applied the moment an incident is confirmed, is one of the more boring fixes that quietly pays for itself.
What should IT leaders do before the bill takes effect?
Run a live simulation. An actual test of whether your team can detect, assess, and get sign-off inside one working day. If it's been more than six months since you last did this, you don't have a tested plan. You have a document, and the Bill is coming for the difference.
What separates a real simulation from a compliance theatre?
Most tabletops fail the same way. They're scheduled, scoped, and run with the right people in the room on a day nobody is busy. Real incidents do none of that. If your exercise has never done the following, it hasn't tested anything:
Start it at an inconvenient hour. Friday at 16:30 is the honest test. So is the second week of August.
Force the sign-off rather than simulating it. Name the individual who authorizes regulatory notification. Make them say yes or no on incomplete information, on the clock. Most organizations discover here that nobody is quite sure who it is.
Withhold information deliberately. Real incidents arrive as fragments, and half the early fragments are wrong. If your scenario briefing is accurate and complete, you're testing reading comprehension.
Time the 72-hour report, not just the 24-hour ping. Actually draft it. The gap between "we'd notify the ICO" and a written account of scope and cause is where most plans turn out to be a title page.
Run it without the obvious person. Your most competent responder is on annual leave. If the plan only works when they're reachable, you have a dependency, not a process.
The exam analogy holds all the way through: you don't find out whether you revised by rereading your notes. You find out by sitting the paper.
If your last incident response test was a conversation rather than a simulation, that's worth fixing before the Bill does it for you. Here's how organizations are closing the gap between having a policy and being audit-ready on the communications side of that risk.
