Cyber Attacks · Incident Response

Can You Prove You Are Ready to Respond to a Cyber Incident?

27 August 2026

Many organisations believe they are ready to respond to a cyber incident.

They have security tools in place. They have an incident response plan. They may have a SOC or MDR provider monitoring for threats. They might even have a cyber insurance policy in place.

But when a board, auditor, insurer, regulator or client asks for evidence of readiness, confidence is not enough.

The question is no longer just:

“Do we have a plan?”

It is:

“Can we prove we are ready to use it?”

That is where incident response readiness evidence becomes important.

Incident response readiness evidence shows that your organisation has not only thought about what should happen during a cyber incident, but has tested, documented and improved its response capability before an incident occurs.

Why evidence matters

Cyber incident response is not only a technical issue.

During a serious incident, decisions may need to be made about business continuity, legal obligations, regulatory reporting, customer communications, supplier involvement, system recovery, evidence preservation and board updates.

These decisions are difficult to make quickly if roles are unclear or if the response process has not been tested.

Evidence matters because it gives stakeholders confidence that your organisation has prepared properly.

It can help answer questions such as:

Has the incident response plan been reviewed recently? Have key teams been trained? Have roles and escalation routes been defined? Have response playbooks been tested? Would evidence be preserved correctly? Would the board receive timely and useful updates? Would the organisation know when to involve legal, insurers, regulators or external response support?

This is becoming increasingly important for organisations facing board scrutiny, cyber insurance renewals, ISO/IEC 27001 certification, regulatory expectations, client due diligence or personal data breach reporting obligations.

For example, organisations working towards ISO/IEC 27001 certification need to demonstrate that information security is managed through a structured, risk-based and continually improving approach. Organisations that handle personal data also need to understand their obligations around personal data breach reporting , including what information may need to be provided and when.

For regulated sectors, incident response readiness may also connect to wider resilience requirements. In financial services, for example, FCA operational resilience requirements place emphasis on understanding important business services, testing resilience and preparing for disruption.

The message is clear: readiness needs to be more than assumed.

It needs to be demonstrable.

What organisations should be able to prove

Incident response readiness evidence does not need to be complicated, but it does need to be useful.

A good starting point is to ask what your organisation would be able to show if a board member, auditor, insurer, regulator or client asked for proof of readiness today.

1. A current incident response plan

Your incident response plan should reflect how your organisation operates now, not how it operated two years ago.

It should include clear information on:

Incident categories and severity levels Roles and responsibilities Escalation routes Decision-making authority Internal and external communication routes Legal, regulatory and insurance considerations Evidence preservation expectations Key contacts and external support

A plan that has not been reviewed recently may still look complete on paper, but fail to reflect current systems, suppliers, teams or business priorities.

2. Defined roles and responsibilities

During an incident, uncertainty slows response.

Your organisation should be able to prove that roles are defined and understood. This includes technical responders, senior decision-makers, communications leads, legal and compliance contacts, operational owners and external partners.

It should be clear who is responsible for:

Leading the incident response Assessing business impact Preserving evidence Notifying leadership Coordinating with insurers Managing regulatory considerations Communicating with staff, customers or suppliers Approving critical decisions

Incident response should not rely on people working out ownership during the incident itself.

3. Practical incident playbooks

A single high-level plan is rarely enough.

Different incident types require different actions. A ransomware incident will not follow the same path as a business email compromise, data breach, DDoS attack or supplier-related incident.

Practical playbooks help teams understand what needs to happen in specific scenarios.

Useful playbooks may cover:

Ransomware Business email compromise Data breach DDoS Insider threat Lost or stolen device Compromised account Third-party supplier incident

Each playbook should give practical guidance on the immediate actions, escalation steps, evidence requirements, communication needs and decision points that apply to that scenario.

4. Evidence of testing and exercises

If your incident response plan has never been tested, it is difficult to prove that it will work.

Tabletop exercises and simulations provide evidence that your organisation has tested its response process in a controlled environment.

They can help prove that:

The right people know when to join Escalation routes work Decision-making is clear Communications can be approved quickly Evidence handling is understood Legal, compliance and leadership teams know their role Gaps have been identified and addressed

Testing is also valuable because it creates a record of learning. It shows that the organisation is actively improving its readiness rather than relying on a static document.

For wider guidance on managing cyber incidents, the NCSC incident management guidance provides useful context on the importance of coordinated response, incident communications and working with external support.

5. Training records

People need to know what is expected of them before pressure arrives.

Training records help demonstrate that key stakeholders have been prepared for their role in an incident. This may include first responder training for IT teams, leadership training for decision-makers, or awareness sessions for departments involved in communications, legal, compliance or operations.

Good training evidence may include:

Attendance records Training materials Role-specific guidance Exercise participation records Feedback and improvement actions

This helps show that readiness is not limited to the security team. It is understood across the people who would need to support the response.

6. Communication templates and notification routes

Communication is one of the areas where organisations can quickly lose control during an incident.

Your organisation should be able to prove that it has considered how communications would be managed before they are urgently needed.

This may include templates or procedures for:

Internal updates Board briefings Customer communications Supplier notifications Regulatory updates Insurance notifications Media holding statements Employee guidance

Templates do not remove the need for judgement, but they do reduce the risk of starting from a blank page during a high-pressure situation.

7. Lessons learned and improvement actions

Readiness evidence should not stop at testing.

The real value comes from what happens afterwards.

After each exercise, review or real incident, your organisation should capture:

What worked well What was unclear Where decisions slowed down Which roles need clarification Which playbooks need updating What information was missing What actions need to be completed Who owns each improvement

This turns readiness into a continuous improvement process.

It also provides valuable evidence for boards, auditors, insurers and clients because it shows that the organisation is actively strengthening its response capability over time.

8. Tool, log and data readiness

A response plan depends on access to reliable information.

If an incident occurs, responders may need access to logs, endpoint data, asset inventories, network diagrams, cloud information, identity data, key contacts and supplier details.

If that information is incomplete or difficult to access, response can slow down.

Your organisation should be able to prove that it has considered:

What logs are available How long key logs are retained Which systems are monitored Where asset information is stored Who can access forensic or technical data Which third parties may hold relevant information How evidence should be preserved

This is where technical readiness supports business readiness. The organisation needs the right information available when decisions need to be made.

9. Access to specialist response support

Even organisations with strong internal IT and security teams may need external support during a serious cyber incident.

Specialist support may be needed for digital forensics, malware analysis, legal advice, insurance coordination, crisis communications or incident command.

Your organisation should be able to prove that it knows:

Who to contact When to involve them What support is available How quickly support can be activated How external responders will work with internal teams What information they will need

The National Cyber Security Centre notes that organisations may need support from certified cyber incident response companies during serious incidents. Linking your internal readiness work with external response support helps avoid delay when time matters.

Where organisations usually fall short

Most readiness gaps are not caused by a lack of effort.

They usually happen because incident response tasks are important but easy to deprioritise.

Common gaps include:

The incident response plan exists but has not been reviewed recently The plan is too generic to guide real decisions Playbooks have not been developed for realistic scenarios Key stakeholders have not been trained Legal, compliance and communications are not involved early enough Board reporting expectations are unclear Evidence preservation is not understood by first responders Cyber insurance notification requirements are not mapped Tabletop exercises have not been run Lessons learned are captured but not acted on External response support is not clearly defined

The result is assumed readiness.

The organisation believes it would be able to respond, but cannot easily prove how.

That creates risk when evidence is requested by a board, auditor, insurer, regulator or client.

Assumed readiness vs proven readiness

There is a clear difference between assumed readiness and proven readiness.

Assumed readiness sounds like:

“We have a plan.” “IT knows what to do.” “We reviewed it a while ago.” “We would work it out during an incident.”

Proven readiness sounds like:

“Our plan has been reviewed.” “Our roles are documented.” “Our playbooks have been tested.” “Our teams have been trained.” “Our evidence requirements are understood.” “Our lessons learned have been acted on.” “Our external support routes are clear.”

This is the shift organisations need to make.

From confidence to evidence.

From static documents to tested capability.

From reactive response to structured readiness.