Most incident response plans were written for a threat landscape that no longer exists. Ransomware that takes days to spread, phishing emails with obvious tells, fraud attempts a trained employee could usually spot. AI has changed the timeline and the disguise. It has not changed the fact that most businesses still find out how ready they are during the incident itself.

We have expanded our Cyber Incident Readiness service this year specifically because of what we are seeing in client environments. This post covers why, and what a readiness plan needs to include now that AI is part of the threat, not just part of the defence.

How AI is changing the threat itself

None of the categories below are new. What is new is the speed and scale at which AI lets attackers run them:

  • AI-written phishing and business email compromise: emails with no spelling errors, no awkward phrasing, and language tuned to match how your organisation actually writes internally
  • Deepfake voice and video fraud: a cloned voice authorising a wire transfer, a fabricated video call requesting urgent access, both convincing enough to bypass staff who were trained to spot the older, clumsier version of this attack
  • AI-accelerated ransomware: reconnaissance and lateral movement that used to take attackers days now takes hours, shrinking the window your team has to detect and contain an intrusion before it spreads
  • Attacks on the AI tools you use: prompt injection, data poisoning, and model manipulation aimed at the AI systems your own business has adopted, a category almost no incident plan written before 2024 accounts for

The common thread is speed. AI compresses the time between first compromise and full business impact. A plan that assumes you have a day to respond before it matters is a plan built for a threat that no longer applies to most organisations.

A plan is not the same as being ready

Every organisation we assess has some version of an incident response document. Most have not opened it in over a year. Fewer still have tested whether the people named in it actually know what they are supposed to do, or whether the technical steps still match the systems currently in production.

Incident response is a business process, not an IT process. The document matters less than whether your leadership team, your comms function, and your technical staff have actually rehearsed making decisions together under pressure. A tabletop exercise reveals gaps that a written plan hides: who has authority to take a system offline, who talks to customers, who decides whether to pay a ransom, and how long the business can actually run in a degraded state before revenue or safety is affected.

What a real fallback plan needs to cover

Keeping the business operating during an incident, not just eventually recovering from one, requires a few things most plans skip:

  • Manual fallback procedures for the processes that break first when systems go down: taking payments, checking in customers, dispatching staff, whatever keeps revenue moving without the software you normally rely on
  • A communications plan written in advance, including holding statements for customers, staff, and regulators, so nobody is drafting a public statement for the first time while also fighting the incident
  • Backups that are actually tested, isolated from the systems an attacker would compromise, and restorable within a timeframe the business can survive
  • Named decision-makers with real authority, agreed before the incident, not improvised during it
  • Regulatory reporting timelines built in, since NIS2, DORA, and UK reporting obligations all carry short statutory windows that do not pause for a crisis

This is what our Incident Readiness Assessment is built to produce: not another document to file away, but plans, playbooks, and a rehearsed team that knows what to do when the alert comes in.