Incident response and cyber resilience

This is Part 5 of a 7-part series on Cyber Resilience for CISOs. Read the previous parts on resilience thinking, threats, zero trust, and supply chain resilience for context.

---

An incident response plan needs testing. During a major incident, untested procedures may fail.

This article examines common response failures and the preparation needed to act during an attack.

Why incident response plans fail

The gap between documented plans and actual performance is often enormous. Understanding common failure modes helps you avoid them.

Plans become outdated

Many incident response plans are written once, stored somewhere, and never touched. They do not reflect current systems, contacts, or capabilities. When needed, the documented procedures no longer match reality.

Plans degrade without maintenance. System changes, personnel turnover, and vendor transitions invalidate assumptions. Annual reviews are insufficient for complex environments.

Key people are unavailable

Plans often assume specific individuals will be available. During a real incident, particularly at 3 AM on a holiday weekend, those people may be unreachable, on leave, or simply overwhelmed.

Depth matters. Every critical role needs backups who are trained and empowered to act. Cross-training prevents single points of failure.

Communication channels fail

Many plans assume internal communication systems will function. If the incident affects email, phones, or collaboration platforms, the response team may be unable to coordinate.

Out-of-band communication is essential. Response teams need channels that work even when primary infrastructure is compromised. This might be personal mobile phones, separate messaging platforms, or even predetermined physical meeting locations.

Dependencies are unknown

Organisations often discover critical dependencies during incidents. Which systems require which other systems to function? What data is needed to restore operations? Where are the credentials stored?

Dependency mapping is essential preparation. Understanding the recovery sequence for interconnected systems prevents wasted effort and cascading failures.

Decision authority is unclear

When an incident escalates, who can authorise containment actions that might disrupt business? Who approves ransom negotiation? Who authorises public disclosure?

Decision authority must be pre-established. During a crisis, there is no time to debate governance structures. Clear escalation paths and delegated authority enable rapid response.

Practices that support response

Organisations that respond effectively share common characteristics. The following practices support that response.

Practised playbooks

The difference between a plan and a capability is practice. Organisations that respond well have exercised their procedures repeatedly.

Tabletop exercises walk through scenarios conceptually, identifying gaps in plans and coordination.

Functional exercises test specific capabilities. Can you restore from backup? Can you isolate network segments? Can you reach your external counsel?

Full simulations stress-test the entire response under realistic conditions, including time pressure and incomplete information.

The organisations that handle incidents best are those for whom the response feels familiar because they have practised.

Clear incident classification

Not every alert is an incident. Not every incident is a crisis. Effective response requires rapid, consistent classification:

Severity levels should be clearly defined with objective criteria. A severity 1 incident triggers different responses than a severity 3.

Escalation triggers specify when to involve leadership, external resources, and legal counsel.

Communication requirements vary by severity, specifying who needs to know what, and when.

This classification prevents both under-reaction (missing serious incidents) and over-reaction (exhausting resources on minor events).

Designated response team

Incident response requires specific skills and clear accountability:

Incident commander. Single point of coordination with authority to direct response

Technical lead. Coordinates investigation and remediation activities

Communications lead. Manages internal and external messaging

Legal/compliance. Advises on obligations and risks

Business liaison. Represents affected business units

Scribe. Documents actions, decisions, and timeline

These roles may be filled by different individuals depending on incident type and availability, but the structure should be consistent.

External resources on retainer

Major incidents often exceed internal capacity. Organisations that respond effectively have relationships established before they need them:

Incident response firms. Technical expertise for investigation and remediation

Legal counsel. Solicitors with relevant cyber-incident expertise who understand breach response

PR/communications. Crisis communication expertise

Insurance. Cyber insurers and breach coaches

A retainer can reduce procurement delay, but response times, availability, charges and scope depend on the contract. Test the contact route and confirm what help is actually committed.

For organisations considering outsourced monitoring, assess MSSP UK services against the contracted hours, systems covered, triage responsibilities and escalation route. Test that alerts reach someone authorised to act; a contract alone does not prove faster detection.

Forensic readiness

Evidence preservation is often neglected in the initial response rush. But forensic evidence is essential for understanding what happened, meeting legal obligations, and supporting potential prosecution.

Log retention. Sufficient logging retained for sufficient duration

Evidence handling. Procedures for preserving chain of custody

Forensic imaging. Capability to capture system state before remediation

Legal hold. Preventing routine deletion of relevant data

Destroying evidence, even unintentionally, can have legal and insurance consequences.

Respond in parallel, without waiting for a time slot

The CISA ransomware response checklist starts with identifying impacted systems and immediately isolating them. Its technical guidance is useful beyond the US; UK reporting obligations need separate assessment. Do not wait two hours, or complete a fixed investigation stage, before acting to limit active harm.

Coordinate and contain

Activate the response lead, establish an approved out-of-band channel and begin a decision log. At the same time, authorised responders should isolate affected systems or segments using the incident plan. Account for health, safety and critical-service dependencies when choosing the action. Escalate uncertainty immediately rather than allowing a suspected attack to spread while waiting for perfect evidence.

Preserve relevant logs and volatile evidence where feasible, with trained help. Evidence capture must not become a reason to delay necessary containment. CISA advises powering down affected devices only if network disconnection is not possible, recognising that shutdown loses volatile evidence.

Investigate and reassess

Determine affected identities, systems, data and dependencies. Restrict compromised access, protect backups and check for continuing attacker activity. Scope will change as evidence improves. Record each conclusion, its confidence and the next action.

Stabilise and plan recovery

Define a clean recovery environment, verified backups and acceptance criteria for returning each service. Restore according to criticality and dependencies, not an assumed universal order. Keep leadership and the legal lead informed while technical work continues.

Assess notifications while containing the incident

For a UK GDPR personal data breach, the controller must notify the ICO unless the breach is unlikely to result in a risk to people's rights and freedoms. Notify without undue delay and, where feasible, within 72 hours of awareness. A late notification needs reasons for the delay. If the breach is likely to create a high risk, inform affected individuals without undue delay, subject to the applicable exceptions. A processor must notify its controller without undue delay.

The ICO's breach guide permits information in phases when full details are unavailable. An initial report does not pause a clock or remove the duty to provide further information without undue further delay. Record all personal data breaches, including the reasoning for a decision not to notify. Assess awareness and risk promptly; do not wait for recovery or a complete forensic report.

Assign one person to record obligations, awareness times, owners and deadlines. Sector rules, overseas operations and contracts may add separate duties. Use qualified advice for the organisation's circumstances.

Ransomware-specific considerations

Ransomware incidents have unique characteristics that require specific preparation.

The payment decision

NCSC guidance states that law enforcement does not encourage, endorse or condone ransom payment. Payment does not guarantee recovery, remove infection or prove that stolen data has been deleted. Preserve attacker communications as evidence and escalate through the approved incident process.

Legal counsel and accountable leadership must assess applicable law, including any sanctions restrictions. Insurance cover is not permission to make a payment. Do not build the recovery plan around an assumed payment outcome or promise that a negotiator will improve it.

Backup verification

Many organisations discover during ransomware incidents that their backups are:

• Also encrypted (not isolated from production)
• Incomplete (not covering critical systems)
• Outdated (retention periods too short)
• Untested (restoration procedures unknown)

Reality check: When did you last restore a critical system from backup? If the answer is "never" or "I don't know," you have a problem.

Keep attacker communications controlled

Only the designated response team should handle attacker contact under specialist legal advice. Staff should preserve relevant messages and report them internally rather than engaging independently.

Building response capability

Effective incident response requires investment in people, tools and practice as well as documentation.

Training and certification

Ensure response team members have appropriate skills:

• Incident response certifications (GCIH, ECIH, etc.)
• Forensic analysis capabilities
• Cloud platform-specific training
• Regular refresher training

Tools and access

Response capability depends on tools and access:

• SIEM and log aggregation for investigation
• EDR for endpoint visibility and containment
• Network monitoring for lateral movement detection
• Forensic toolkits for evidence collection
• Secure communication platforms

Process automation

Where possible, automate response actions:

• Automated evidence collection
• Scripted containment procedures
• Automated notification workflows
• Pre-approved isolation actions

Tested, bounded automation can reduce delay and make repeated actions more consistent. Define failure handling, abort conditions and a manual route when automation is unavailable or unsafe.

Metrics and improvement

Measure response effectiveness:

• Mean time to detect (MTTD)
• Mean time to respond (MTTR)
• Mean time to contain
• Mean time to recover

Use post-incident reviews to improve. Review minor incidents as well as major ones.

Incident response readiness checklist

Assess your current incident response readiness:

Planning:

• Incident response plan reviewed in last 6 months
• Contact lists current and tested
• Severity classification criteria defined
• Escalation paths documented
• Decision authority pre-delegated

Team:

• Response team roles clearly assigned
• Backup personnel identified for each role
• Team members trained and certified
• 24/7 coverage plan in place
• Cross-functional representation included

External Resources:

• Incident response retainer in place
• Legal counsel identified and engaged
• Insurance coverage confirmed
• PR/communications support available
• Vendor contacts current

Technical Capability:

• Adequate logging and retention
• Forensic collection capability
• Containment procedures documented
• Backup restoration tested
• Out-of-band communication available

Practice:

• Tabletop exercise conducted in last 12 months
• Functional exercise conducted in last 12 months
• Lessons from exercises incorporated
• Post-incident reviews conducted
• Continuous improvement demonstrated

Supporting responders

Incident response is intensely human. Technical capabilities matter, but so does how people perform under stress.

Pace yourself. Major incidents can last days or weeks. Exhausted responders make mistakes. Build rotation schedules that allow rest.

Communicate clearly. Stress degrades communication. Use structured formats, confirm understanding, and document decisions.

Manage stress. Provide psychological support. Incident response is emotionally demanding. Check in on team members during and after incidents.

Learn without blame. Post-incident reviews should focus on process improvement, not individual fault. Blame cultures suppress the honesty needed to learn.

The organisations that respond best are those where people feel supported, empowered, and prepared.

Next in the series

Incident response is operational. But major incidents also require strategic communication. Part 6 addresses how to communicate crises to the board, including decisions about what the board needs to know.

Part 7 synthesises the series into a practical roadmap you can take into 2026.

Start by checking your contact list, decision authority and latest restoration test.

---

Building incident response capability

Developing genuine incident response capability requires experienced guidance. My IT management services help organisations assess their readiness, develop and test response procedures, and build the capabilities needed when incidents occur.

Book a consultation with your response plan, contact list and last exercise findings. We can identify unclear authority, untested dependencies and the next exercise needed to resolve them.

---

Previous: Part 4 - Third-Party and Supply Chain Resilience

Next: Part 6 - Communicating Crisis to the Board