Incident Response Planning: Hope Is Not a Strategy

It’s 2 AM. Your phone rings. The caller ID says "Monitoring Alert."

Ransomware has encrypted your file servers. Users can’t access critical data. The attackers are demanding $50,000 in Bitcoin within 48 hours.

What do you do?

If your answer is "figure it out," you’re already in trouble.

Why Incident Response Plans Fail

Most organizations have incident response plans. Many have never tested them. Some have tested them once, years ago, and never updated them.

When a real incident hits, these plans fail because:

• Contact lists are outdated — Key people have changed roles or left the company
• Procedures assume resources that no longer exist — "Restore from backup server" (which was decommissioned last year)
• Nobody remembers the plan exists — It’s in a SharePoint folder that nobody can access during the outage
• Roles and responsibilities are unclear — Everyone assumes someone else is handling it
• Communication channels aren’t established — Should we use Slack? Email? Teams? (Which are all down?)

Real-World Threats Demand Real Plans

Recent security incidents highlight the diversity of threats organizations face:

Ransomware Remains the Top Threat

Attackers encrypt data and demand payment. Modern ransomware often includes data exfiltration—threatening to leak sensitive information if ransom isn’t paid (double extortion).

Nation-State Attacks on Critical Infrastructure

In December 2025, Russian state-sponsored hackers (Sandworm) attempted to deploy destructive wiper malware (DynoWiper) against Poland’s power grid. The attack was thwarted, but it demonstrates the sophistication and intent of nation-state actors targeting critical infrastructure.

Supply Chain Compromises

In January 2026, malicious VSCode extensions with 1.5 million combined installs were discovered exfiltrating developer data to China-based servers. Supply chain attacks exploit trusted distribution channels to compromise multiple victims.

Credential-Based Attacks

The ShinyHunters gang’s January 2026 campaign targeting SSO accounts at Okta, Microsoft, and Google shows how attackers increasingly focus on identity compromise over traditional malware.

The Six Phases of Incident Response

Based on the NIST framework, effective incident response follows six phases:

Phase 1: Preparation

Before any incident occurs:

• Establish an incident response team with clear roles
• Document procedures for common incident types
• Maintain updated contact lists and communication channels
• Deploy monitoring and detection tools
• Conduct regular training and tabletop exercises
• Maintain offline backups and recovery tools

Building Your Incident Response Team

Incident Commander:

• Overall decision authority and coordination
• Typically IT Director or CISO
• Delegates tasks and maintains big-picture view

Technical Lead:

• Hands-on technical investigation and remediation
• Senior systems administrator or security engineer
• Executes containment and eradication procedures

Communications Lead:

• Internal and external communications
• Marketing, PR, or designated spokesperson
• Manages stakeholder updates and media inquiries

Legal/Compliance Liaison:

• Ensures compliance with incident notification laws
• In-house counsel or external legal advisor
• Coordinates with regulators and law enforcement

Documentation Scribe:

• Records timeline, decisions, and actions taken
• Any team member with attention to detail
• Maintains evidence chain of custody

Phase 2: Detection and Analysis

Identify that an incident is occurring:

• Monitor security alerts from EDR, SIEM, and firewall logs
• Investigate anomalies reported by users
• Determine the scope and severity of the incident
• Classify the incident type (ransomware, data exposure, DDoS, etc.)
• Document initial findings with timestamps

Essential Tools and Resources

Communication Tools (Available During Outages):

• Backup phone numbers for all team members
• Alternative communication channel (Signal, personal phones)
• Conference bridge or Zoom link that works from anywhere

Technical Tools:

• Forensic analysis software (write-protected USB drive)
• Clean boot media and OS installation images
• Offline password managers with recovery codes
• Network diagrams and system documentation (offline copies)

External Resources:

• Cyber insurance policy details and contact info
• Incident response retainer (many MSPs and security firms offer this)
• Legal counsel contact information
• List of trusted third-party forensics firms

Phase 3: Containment

Stop the incident from spreading:

Short-term containment (immediate):

• Isolate affected systems from the network
• Block malicious IP addresses and domains
• Disable compromised user accounts
• Preserve evidence for forensic analysis

Long-term containment (while fixing):

• Apply temporary patches or workarounds
• Implement network segmentation
• Deploy additional monitoring
• Maintain business operations where possible

Phase 4: Eradication

Remove the threat from your environment:

• Identify and remove malware, backdoors, and compromised accounts
• Patch vulnerabilities that enabled the attack
• Reset credentials for affected accounts
• Rebuild compromised systems from clean images
• Verify eradication through scanning and monitoring

Phase 5: Recovery

Restore systems to normal operation:

• Restore data from clean backups
• Bring systems back online in a controlled manner
• Verify functionality and monitor for signs of re-infection
• Gradually increase system access and monitoring
• Communicate restoration status to stakeholders

Phase 6: Lessons Learned

Conduct a post-incident review within 2 weeks:

• Document timeline and actions taken
• Identify what worked and what didn’t
• Update incident response procedures
• Implement preventive measures to avoid recurrence
• Share findings with leadership and relevant teams

Real-World Attack Analysis: ShinyHunters SSO Campaign

Recent news highlights why preparation matters:

What happened: ShinyHunters launched sophisticated voice phishing attacks targeting SSO accounts.

Their approach:

1. Phished user credentials through fake login pages
2. Called victims pretending to be IT support
3. Convinced users to approve MFA push notifications
4. Gained access to corporate applications

Tabletop Exercises: Practice Makes Prepared

The best way to validate your incident response plan? Test it.

Tabletop exercises walk through realistic scenarios without actually breaking anything:

Sample Exercise: Ransomware Attack

Discussion points:

• Who do we notify first?
• How do we isolate affected systems?
• Where are our most recent backups?
• Do we have offline backups that ransomware can’t reach?
• When do we notify leadership? Customers? Law enforcement?
• How do we communicate with users while email is down?

Common Mistakes to Avoid

Compliance and Legal Requirements

Many regulations mandate incident response capabilities:

• HIPAA (healthcare) — 60-day incident notification requirement
• GDPR (EU data) — 72-hour notification for data security incidents
• SOC 2 — Requires documented incident response procedures
• PCI DSS (payment cards) — Incident response plan is required for compliance

Start Small, Build From There

Don’t let perfect be the enemy of good. Start with:

1. Document the basics — Who to call, what to do first, where critical info lives
2. Test your backups — Can you actually restore from them?
3. Establish communication channels — Know how to reach your team during an outage
4. Run one tabletop exercise — Learn what gaps exist
5. Iterate and improve — Update the plan based on what you learned

The Bottom Line

Hope is not a strategy. When an incident occurs—and it will—you won’t have time to figure things out from scratch.

The organizations that recover quickly and minimize damage are the ones that prepared.

Build your plan. Test your plan. Update your plan.

Then hope you never need it.