Your Incident Response Plan Is Only as Strong as the ISMS Behind It

Most organisations that run a cyber security tabletop exercise discover the same thing within the first twenty minutes. The incident response plan looks sensible on paper, but the moment the scenario gets specific, people start asking questions the plan cannot answer. Which systems hold customer data? Who owns the supplier that has just been breached? When was the backup last tested? Who signs off on notifying the regulator?

Why Your Incident Response Plan Is Only as Strong as the ISMS Behind It

Most organisations that run a cyber security tabletop exercise discover the same thing within the first twenty minutes. The incident response plan looks sensible on paper, but the moment the scenario gets specific, people start asking questions the plan cannot answer. Which systems hold customer data? Who owns the supplier that has just been breached? When was the backup last tested? Who signs off on notifying the regulator?

These are not really incident response questions. They are information security management questions, and if the answers are not already written down, agreed and kept current, the response team ends up improvising under pressure. That is exactly where mistakes, delays and regulatory exposure creep in.

Incident Response Does Not Start When the Alert Fires

It is tempting to treat incident response as a standalone capability: a plan, a playbook, a contact list and a retained forensics firm. All of those matter. But a response plan relies on a foundation that has to be built long before anything goes wrong:

• An accurate inventory of information assets and who owns them
• A current view of risks and the controls in place to treat them
• Clear roles and decision rights, including who can authorise containment steps that affect operations
• Records of suppliers, what they have access to and how to reach them out of hours
• Logging and monitoring that will actually provide evidence when you need it

In a well-run organisation, those things live inside an information security management system.

What an ISMS Actually Gives You

An ISMS is the set of policies, processes, roles and records an organisation uses to manage information security risk in a systematic way. ISO/IEC 27001 is the best-known standard for it, but the value of an ISMS goes well beyond holding a certificate.

For incident response specifically, a mature ISMS provides three things.

1. Context Before the Crisis

Because the ISMS requires an asset inventory and a risk assessment, the response team does not have to work out what is affected from scratch. They can quickly see which business processes depend on a compromised system and how critical those processes are. That shortens the time between detection and a sensible containment decision.

2. Pre-Agreed Decisions

An ISMS defines responsibilities and approval paths in advance. During a ransomware incident, for example, someone needs the authority to take systems offline even if it disrupts trading. If that decision has already been assigned and rehearsed, the organisation avoids the costly hour of debate that so often happens on the first bridge call.

3. A Loop That Learns

Incident management is built into ISO 27001, and so is continual improvement. Every incident, near miss and tabletop exercise should feed back into the risk register, the control set and the response plan. Without an ISMS, lessons learned reports tend to sit in a shared drive. With one, they become tracked actions with owners and deadlines.

The Regulatory Angle Has Changed

For many UK and European organisations, a structured approach to security management is no longer optional. NIS2 places explicit obligations on in-scope entities to manage cyber risk and report significant incidents within tight timeframes. DORA does the same for financial entities, with detailed requirements on ICT risk management, incident classification and reporting, and third-party oversight. In the UK, the Cyber Assessment Framework continues to shape expectations for operators of essential services.

The common thread across all of these is that regulators want evidence. It is not enough to say you have an incident response plan. You need to show how risks were identified, which controls address them, how incidents are classified and how decisions were made. An ISMS is the natural place to keep that evidence, which is why organisations that already run one usually find new regulations far easier to absorb.

Common Gaps We See Between the ISMS and the Response Plan

Even organisations with ISO 27001 certification sometimes find their ISMS and their incident response capability have drifted apart. The most common gaps include:

• Out-of-date asset registers. New cloud services and SaaS tools are adopted faster than the register is updated, so responders are working from an incomplete picture.
• Supplier blind spots. Third parties are assessed at onboarding and then forgotten. When a supplier is breached, nobody knows quickly what data they hold.
• Plans written for auditors, not responders. Documents that satisfy an audit can be too long and too abstract to use at 3am.
• No link between exercises and the risk register. Tabletop findings are discussed but never translated into changes to risks or controls.

How to Bring Them Together

Closing these gaps does not require starting again. A few practical steps make a significant difference:

1. Map your playbooks to your risk register. Each high-rated risk should have a corresponding response scenario, and each playbook should reference the assets and owners recorded in the ISMS.
2. Use tabletop exercises as ISMS inputs. Treat every exercise finding as a potential nonconformity or improvement action, and track it in the same system as your audit findings.
3. Review supplier records after every exercise. If the scenario involved a third party, check that contact details, data flows and contractual notification terms were accurate.
4. Keep the response plan short. Put the detail in the ISMS and keep the plan itself to decisions, contacts and steps that people can follow under stress.
5. Automate the evidence where you can. Manual spreadsheets go stale quickly. Many organisations now use compliance platforms to keep risks, controls, suppliers and incidents linked in one place.

Final Thoughts

An incident response plan tells people what to do when something goes wrong. An ISMS makes sure they have the information, authority and context to do it well. Treating the two as separate projects leaves organisations exposed at precisely the moment they can least afford it.

If your next tabletop exercise raises questions that nobody can answer quickly, the fix may not be a better playbook. It may be a stronger management system underneath it.