The Incident Response Reality Check

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.

Every organisation has an incident response plan. Most have never truly tested it. When a major incident occurs, that untested plan often disintegrates on contact with reality.

This article provides a reality check. What actually works when things go wrong? What do organisations discover they should have done differently? How can you build incident response capabilities that perform under the pressure of a real attack?

Incident response is where resilience philosophy becomes operational reality.

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 Exist in a Vacuum

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.

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 one occurring at 3 AM on a holiday weekend - those people may be unreachable, on leave, or simply overwhelmed.

Reality: 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.

Reality: 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?

Reality: 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?

Reality: 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.

What Actually Works

Organisations that respond effectively share common characteristics. These are the elements that matter when theory meets reality.

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 actually 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 - 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 - Cyber-specialist attorneys who understand breach response

PR/communications - Crisis communication expertise

Insurance - Cyber insurers and breach coaches

Pre-negotiated retainers mean help arrives in hours, not days. Trying to vet and engage vendors during a crisis adds dangerous delay.

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.

The First 24 Hours

The initial response period is critical. Actions taken (or not taken) in the first hours significantly impact overall outcome.

Hour 0-2: Detection and Triage

Confirm the incident is real (not a false positive)
Conduct initial severity classification
Activate incident response team
Establish communication channel
Begin incident documentation

Common mistakes: Dismissing early indicators, delayed escalation, neglecting documentation.

Hour 2-8: Containment

Prevent further damage and data loss
Isolate affected systems
Reset compromised credentials
Preserve evidence
Assess scope of compromise

Common mistakes: Rushing to remediation before understanding scope, destroying evidence, containment that causes unnecessary business disruption.

Hour 8-24: Investigation and Stabilisation

Determine attack vector and timeline
Identify all affected systems and data
Assess business impact
Begin stakeholder notifications
Plan remediation

Common mistakes: Underestimating scope, premature all-clear, inadequate communication.

Throughout this period, document everything. The incident timeline becomes essential for post-incident review, regulatory reporting, and potential litigation.

Ransomware-Specific Considerations

Ransomware incidents have unique characteristics that require specific preparation.

The Payment Decision

The payment question will arise. Prepare your position in advance:

Arguments against payment:

Funds criminal enterprises
No guarantee of decryption
May violate sanctions regulations
Does not address data exfiltration
May mark you as willing to pay again

Arguments for payment:

May be faster than restoration
May recover data that cannot otherwise be restored
May prevent publication of stolen data
May be the only option if backups are compromised

This is ultimately a business decision, not a security decision. Legal counsel, insurance, and executive leadership should be involved. Having discussed the framework in advance - even without reaching a definitive answer - accelerates decision-making during crisis.

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.

Negotiation Considerations

If considering payment, professional negotiation can reduce amounts and improve outcomes. Insurers and incident response firms often have experienced negotiators.

Never communicate directly with attackers without legal counsel involvement. Every communication may have implications.

Building Response Capability

Effective incident response is not just documentation - it is organisational capability built through deliberate investment.

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

Technology Enablement

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

Automation reduces response time and ensures consistent execution.

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. Every incident - even minor ones - offers lessons.

Quick Reference: 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

The Human Element

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.

What Comes Next

Incident response is operational. But major incidents also require strategic communication. Part 6 addresses how to communicate crises to the board, turning incidents into leadership moments.

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

The best time to prepare for incident response was before you needed it. The second best time is now.

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.

Get in touch to discuss how to strengthen your incident response posture.

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

Next: Part 6 - Communicating Crisis to the Board