Your Incident Response Plan Has Never Been Tested. Here's What That Means.

The uncomfortable gap between having a plan and being ready

Somewhere in your organisation — in a SharePoint folder, or a Google Drive, or a folder on someone's desktop labelled "Compliance" — there is a document titled something like "Incident Response Plan" or "Business Continuity Plan."

It was probably written eighteen months ago, or three years ago, or in a hurry before an audit. It describes, in varying levels of detail, what the organisation will do when something goes wrong.

Here is the question nobody wants to ask: when was it last tested?

Not reviewed. Not updated with new contact numbers. Tested — as in, your leadership team sat down, worked through a realistic scenario, and actually found out whether the plan holds up under pressure.

For most organisations, the honest answer is never.

What an untested plan actually gives you

A plan that hasn't been tested gives you documentation. It gives you something to point to when a regulator asks whether you have an incident response process. It gives you the comfort of knowing that somewhere, someone has thought about this.

What it doesn't give you is confidence that anyone will know what to do when it happens. Because knowing what the plan says and knowing how to execute under pressure are completely different things. The gap between them only becomes visible when you're in the middle of an incident.

Consider what a breach actually looks like in an organisation that has never run through the scenario. The detection happens at an awkward time — it's usually a Friday evening or a Monday morning, never a convenient Tuesday at 11am. The person who finds it doesn't know who to call. The person who gets called doesn't know whether to shut down systems immediately or preserve them for forensics. Legal doesn't know whether PDPA notification has been triggered, or what the notification window is. Communications doesn't know what to say to clients. Nobody knows who has authority to make which decisions.

And the plan — the one in the SharePoint folder — is being frantically read for the first time by people who are already panicking.

What tabletop exercises are for

A tabletop exercise is a structured walkthrough of a realistic incident scenario. The key word is structured. It's not a quiz about the plan. It's an immersive, facilitated session where the relevant stakeholders — IT, legal, operations, leadership, communications — work through a scenario in real time, making the decisions they'd have to make if it were real.

What typically emerges:

Role ambiguity. Who decides when to notify the regulator? Who has authority to take systems offline? Who speaks to clients? These questions usually have answers in the plan that don't match the decisions people would actually make in the room. The gap between the documented authority and the real authority becomes visible fast.

Communication breakdowns. In a real incident, communication under pressure looks very different from communication in normal operations. Who calls whom, in what order, using what channel? What happens if the primary contact isn't available? Tabletops expose the assumptions that haven't been tested.

Missing playbooks. The plan describes the process at a high level, but the team quickly discovers they don't have the specific runbooks they need. What's the actual procedure for isolating a compromised endpoint? What's the legal threshold for PDPA notification and who makes that call? What's the approved external statement if the incident becomes public?

Decision lag. Perhaps the most dangerous thing a tabletop reveals is how long decisions take when people aren't certain of their authority or their process. In a real incident, decision lag has a cost. Every hour of uncertainty is an hour of continued exposure.

None of these gaps are failures of the people in the room. They're failures of a plan that was never stress-tested.

Phishing simulations and the human layer

A significant proportion of incidents start with a human being making a wrong call. A click on a convincing phishing email. A response to a spoofed request. A credential entered into a fake login page.

Knowing that phishing exists and knowing how to recognise it under pressure are different things. The former comes from awareness training. The latter comes from practice — from having been targeted, in a controlled environment, and having experienced what it feels like to almost click.

Controlled phishing simulations don't just identify who's vulnerable. They identify which departments are most at risk, which types of social engineering are most effective against your specific team, and where targeted reinforcement is needed before a real attacker finds the same weaknesses.

The data from a well-run simulation programme gives you something a training completion report doesn't: a realistic picture of your human attack surface.

The insurance and regulatory angle

Cyber insurance underwriters are increasingly asking not just whether you have an incident response plan, but whether you've tested it. A tested, documented response capability is a materially different risk profile from a plan in a folder. Premiums reflect that difference.

Regulators are moving in the same direction. Demonstrated readiness — evidence that the organisation has rehearsed its response, identified and closed gaps, and maintains a current and tested plan — is increasingly what "appropriate technical and organisational measures" looks like in practice, not just in principle.

The question to sit with

The purpose of an incident response plan is not to satisfy an auditor. It is to ensure that your organisation can respond effectively when something goes wrong — limiting damage, protecting data, meeting legal obligations, and maintaining the trust of your clients.

None of those things happen automatically because the document exists.

They happen because the people who need to execute the plan have practised executing it. Because the gaps have been found and closed in a controlled environment rather than a live one. Because when the call comes at 11pm, nobody is reading the plan for the first time.

StaySecure READY™ delivers controlled phishing simulations, facilitated tabletop exercises, and infrastructure vulnerability assessments — turning incident readiness from a document into a demonstrated capability. [Learn more →]