How should businesses assess their cyber incident response readiness?

Cyber incident response readiness is best assessed by testing whether an organisation can make sound decisions and carry out essential actions under realistic conditions, using its own systems, people and suppliers. A policy document is useful evidence, but it does not by itself demonstrate that the organisation can identify the nature of an incident, preserve reliable information, obtain the right authority and coordinate technical, legal and business decisions.

Start with the organisation’s risk profile. Readiness should be judged against the incidents the business could realistically face, rather than against a generic checklist. Consider the effect of ransomware, a stolen administrator account, an exposed cloud service, malicious insider activity, supplier compromise and loss of access to a critical application. The assessment should record which services are most important, what information they process, which business activities depend on them and what assumptions the response process makes about system availability.

This risk-based approach helps distinguish a serious readiness gap from a lower-priority improvement. For example, an organisation that relies on a hosted platform for customer operations needs to understand the provider’s incident notification process, available audit information and contractual obligations. A business with several locations may also need to assess how consistently security controls and response procedures are applied across each site.

Examine governance and decision authority. The assessment should establish who can approve disruptive actions such as disabling an account, isolating a device, blocking network traffic or taking a service offline. It should also identify who has authority to involve external specialists, insurers, legal advisers and relevant authorities. These decisions should not depend solely on one individual being available or remembering an undocumented process.

Review whether the organisation has defined criteria for escalating an event. Useful criteria may include suspected personal data exposure, privileged account misuse, spread across multiple systems, material interruption to operations or evidence that a third party is involved. The aim is not to predict every event, but to ensure that similar incidents receive a consistent level of scrutiny and that important decisions are recorded with their rationale.

Check the quality of information available during an incident. Responders need enough reliable information to distinguish a genuine compromise from a technical fault and to determine what happened. Assess whether relevant logs are collected, retained for an appropriate period and accessible to authorised investigators. Look at identity activity, endpoint events, firewall or network records, cloud audit trails and changes to important systems where applicable.

The assessment should also consider whether timestamps can be compared accurately, whether logs can be altered by an attacker with excessive privileges and whether evidence can be preserved without unnecessarily disrupting operations. If investigators would have to reconstruct events from incomplete or inconsistent records, that limitation should be documented as a readiness risk.

Test the process through realistic exercises. A discussion-based exercise can reveal uncertainty about authority, escalation and priorities. A more detailed technical walkthrough can examine how responders would investigate a suspicious login, compromised endpoint or unauthorised change. Where appropriate, technical validation may include checking that security alerts reach the right people, that administrative actions are logged and that isolation procedures work as intended.

Exercises should be based on the organisation’s actual environment rather than an abstract scenario. Include the constraints that would exist during a real event, such as incomplete information, unavailable staff, a dependent supplier or a critical service that cannot simply be switched off. Record decisions, questions and delays as evidence. The purpose is to test the response system, not to judge individuals.

Assess third-party and cloud dependencies. Many businesses cannot investigate or restore an incident without information or action from a hosting provider, software supplier, telecoms provider, security service or outsourced IT team. Readiness therefore includes knowing how to raise an incident with each relevant supplier, what information the supplier can provide and which actions remain the customer’s responsibility.

Review contracts, support arrangements and service documentation for incident notification requirements, access to logs, data location, forensic support, recovery options and the process for returning control of an account or service. Supplier contact details should be maintained separately from systems that might become inaccessible. Any dependency that has not been tested should be treated as an assumption rather than as proven capability.

Verify that response tools and access arrangements are usable. Responders may need secure access to administrative consoles, asset records, contact information, documentation and evidence repositories. Check how that access is granted if normal identity services are affected, and whether emergency privileges are controlled, logged and removed afterwards. Shared accounts, undocumented credentials and inaccessible runbooks can create additional risk during an investigation.

The review should include the practical tools used to collect evidence, isolate systems, communicate decisions and track actions. It should confirm that responders know where those tools are located and understand any limitations. A process that depends on a single laptop, an individual’s personal notes or an internal platform that may be unavailable has not been fully demonstrated.

Include legal, regulatory and contractual considerations. The assessment should identify the circumstances in which an incident may trigger data protection, sector-specific, contractual or insurance obligations. It should define who evaluates those obligations, who approves notifications and how the organisation preserves the evidence supporting its decision. Personal data incidents require particular care because the assessment may need to establish what data was involved, whose information was affected and the likely consequences.

Legal advice should be obtained where the facts or obligations are uncertain. The response process should also distinguish factual investigation from speculation, restrict sensitive information to appropriate recipients and maintain a clear record of significant decisions. This supports later reviews and reduces the risk of inconsistent statements being made before the facts are established.

Review recovery readiness without treating recovery as an assumption. The assessment should look for evidence that important services can be rebuilt or reinstated using known procedures and suitable recovery data. Consider whether recovery copies are protected from the same compromise, whether restoration dependencies are understood and whether recovered systems can be checked before being returned to normal use.

Where restoration has not been exercised, record that clearly. A backup job showing as successful does not prove that the required data is complete, usable or recoverable in the required order. Recovery testing should also identify how business processes operate while systems are unavailable and how temporary workarounds are brought back under controlled arrangements.

Use evidence-based findings and prioritise remediation. Collect artefacts such as exercise records, alert samples, access reviews, supplier procedures, system diagrams, recovery test results and decision logs. Interview people who would actually participate in the response, including technical, operational, senior management and relevant external contacts. Compare what the documentation says with what the organisation can demonstrate.

Findings can be classified as effective, partially effective, untested or absent. Each gap should state the risk it creates, the action required, the accountable owner and the evidence that will demonstrate closure. Prioritisation should favour weaknesses that could prevent the organisation from understanding the incident, controlling further harm, meeting an obligation or restoring a critical service.

Readiness should then be reassessed after material changes, such as a new cloud service, major infrastructure upgrade, acquisition, change of supplier or significant alteration to the workforce. Regular exercises and reviews are more useful when they produce specific improvements and confirm that those improvements work. For businesses without all the necessary internal expertise, a managed IT and cyber security provider such as S2 Technology Group can help review controls, facilitate exercises and turn identified gaps into a practical improvement plan.