Incident Response Playbook

Executive Summary

A cyberattack is not a question of if — it is a question of when and how ready you are to respond. Organisations with a tested incident response plan contain incidents in hours; those without a plan contain them in days or weeks, with correspondingly greater damage.

This playbook is a practical operational guide for security teams, IT managers, and incident commanders. It follows the NIST SP 800-61 incident response lifecycle and provides specific playbooks for the most common incident types: ransomware, data breach, account compromise, and cloud security incidents.

This document should be treated as a living document — reviewed and updated after every incident and at least annually.

Chapter 1: The Incident Response Lifecycle

NIST SP 800-61 defines four phases:

Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity
     ↑                                                                              ↓
     └──────────────────────────────────────────────────────────────────────────────┘
                              (continuous feedback loop)

Phase 1 — Preparation: Building the capability before an incident occurs Phase 2 — Detection and Analysis: Identifying that an incident is occurring and understanding its scope Phase 3 — Containment, Eradication, and Recovery: Stopping the attack, removing the attacker, and restoring operations Phase 4 — Post-Incident Activity: Learning from the incident to improve resilience

Chapter 2: Preparation

Incident Response Team Structure

RACI Matrix

Document who is Responsible, Accountable, Consulted, and Informed for each decision during an incident:

Communication Templates

Pre-draft these before an incident:

Internal all-hands template:

We are currently investigating a security incident. IT and security teams are working to contain and resolve the issue. Please [do not use VPN / avoid printing / avoid accessing the following systems]. More information will be provided in [X hours]. Do not discuss this externally.

Customer notification template (placeholder):

We are writing to inform you of a security incident that may have affected [X]. We detected [activity description] on [date]. We immediately [containment action]. [Data affected / not affected]. We have [regulatory notifications made]. We are [ongoing actions]. Contact: [security@company.com] for questions.

Regulator notification template: Prepare a template compliant with the specific regulations applicable to your organisation. Key elements: date of detection, date of occurrence (if known), data subject category and count, data categories affected, likely consequences, measures taken.

Tools and Resources

IR toolkit — pre-deployed or on-standby:

• EDR platform with ability to isolate endpoints remotely (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne)
• SIEM with real-time alerting (Splunk, Microsoft Sentinel, Elastic SIEM)
• Network packet capture capability (Zeek/Bro, Security Onion, or cloud flow logs)
• Forensic imaging tools (FTK Imager, dd, AWS EBS snapshots)
• Offline/out-of-band communication channel (separate email, Signal, or an IR communication platform) — if your primary email is compromised, you need an alternative
• Preserved forensic copies of all critical logs (CloudTrail, AD logs, endpoint EDR data)

External contacts to have on retainer or speed-dial:

• External IR firm (CyberneticsPlus or specialist IR provider)
• Cyber insurance incident response hotline
• Law enforcement liaison (CERT-In for India, NCSC for UK, CISA for US)
• Legal counsel with data breach experience
• PR firm with crisis communications experience (for significant incidents)

Chapter 3: Detection and Analysis

Incident Triggers

Initial Triage Checklist

When a potential incident is reported:

• Record the time of notification — important for regulatory timeline compliance
• Assign an Incident Commander — one person leads from this point
• Open an incident channel — dedicated Slack/Teams channel or bridge call
• Preserve evidence immediately — do not reboot or shut down systems before capturing volatile data
• Initial classification: Is this a confirmed incident or a potential incident (false positive)?
• Scope assessment: How many systems are affected? What data could be impacted?
• Notify Legal — early legal involvement ensures attorney-client privilege on communications

Incident Severity Classification

Evidence Collection — Volatile Data First

Before isolating a compromised system, capture volatile evidence (it disappears on reboot):

# Active network connections
netstat -antp > connections.txt
ss -tulpn >> connections.txt

# Running processes
ps auxf > processes.txt
/proc/*/cmdline (Linux)
tasklist /v > processes.txt (Windows)

# Logged-in users
who > users.txt
last -n 50 >> users.txt

# Recent commands
history > history.txt
cat ~/.bash_history >> history.txt

# Memory dump (for advanced analysis)
winpmem.exe memory.dmp (Windows)
LiME kernel module (Linux)

For cloud workloads: take a snapshot of the EC2/VM instance before terminating it.

Chapter 4: Containment

Containment Strategy Decision

Before containing, determine the strategy:

Short-term containment (immediate, while investigation continues):

• Isolate the affected system (network isolation, not shutdown)
• Block identified attacker IPs/domains at perimeter
• Disable compromised credentials

Long-term containment (sustained while eradication is prepared):

• Maintain a clean, known-good version of affected systems on standby
• Implement additional monitoring to detect attacker persistence
• Restrict access to sensitive systems during investigation

Containment vs. monitoring: In some investigations, it is valuable to monitor attacker activity before containing — to understand their full scope and objectives. This is a decision for the Incident Commander in consultation with Legal. Do not monitor longer than necessary.

Network Isolation Techniques

Credential Response

If credential compromise is suspected:

1. Disable the compromised account(s) — not just password reset (an active session remains valid)
2. Revoke all active sessions — force re-authentication for all sessions
3. Audit authentication logs — identify all access using the compromised credential
4. Identify privilege escalation — did the attacker use the credential to create new accounts or modify permissions?
5. Reset all service accounts — if a domain controller is involved, assume all credentials are compromised

Chapter 5: Specific Incident Playbooks

Playbook A: Ransomware

Detection indicators:

• Files with new/unknown extensions (.locked, .encrypted, .WNCRY)
• Ransom note (README.txt, DECRYPT_INSTRUCTIONS.html)
• Rapid file modification events in EDR
• Shadow copies deleted (Event ID 524, vssadmin delete shadows)
• CPU spike on multiple systems

Immediate actions (first 30 minutes):

1. Do not pay the ransom — not yet; engage incident response team and legal first
2. Do not reboot affected systems — may destroy forensic evidence; some ransomware has different behaviour on reboot
3. Identify Patient Zero — first infected system; usually an email attachment or RDP compromise
4. Identify propagation scope — which systems show encryption? Check EDR, file server logs
5. Isolate all affected systems — at the network level
6. Preserve backups — immediately verify backup integrity and isolate them from the network; ransomware frequently targets backups

Investigation:

• Identify the ransomware variant (upload a sample file and ransom note to ID Ransomware)
• Check whether a decryption key is available without payment (No More Ransom project)
• Determine the initial access vector — this must be closed before recovery begins
• Engage external IR firm if internal capability is insufficient

Ransom payment decision:

• Check whether payment is legally permissible (OFAC sanctions list — paying some ransomware groups is illegal)
• Engage legal counsel before any payment
• Consider: backup availability, RTO requirements, data sensitivity, attacker reputation for providing decryptors
• Payment does not guarantee decryption — track record varies by group

Recovery:

1. Rebuild affected systems from clean OS images (not from snapshots of compromised systems)
2. Restore data from last known-good backup
3. Close the initial access vector before bringing systems back online
4. Verify all systems are clean before reconnecting to network
5. Monitor intensively for 30 days post-recovery

Playbook B: Data Breach

Detection indicators:

• DLP alert: large volume of data transferred externally
• SIEM alert: database query returning unusually large result sets
• Cloud storage: public access enabled on previously private bucket
• External notification: breach discovered by third party, researcher, or dark web monitoring
• User report: customer reports receiving their data unexpectedly

Immediate actions:

1. Identify the breach vector — which system, which account, which vulnerability
2. Stop the bleeding — close the exposure (disable the endpoint, fix the misconfiguration, revoke the credential)
3. Scope the breach — what data was accessed/exfiltrated? What is the affected population?
4. Engage Legal immediately — regulatory notification timelines start from awareness, not discovery
5. Preserve evidence — access logs, data transfer records, authentication logs

Data scope assessment:

Regulatory notification timelines:

• GDPR (EU): 72 hours to supervisory authority if high risk; without undue delay to data subjects
• UK GDPR: 72 hours to ICO
• DPDPA India: notification timeline set by DPB (Data Protection Board) rules — pending final regulations
• PCI DSS: immediate notification to card brands and acquiring bank
• HIPAA: 60 days to OCR; 60 days to individuals for breaches of >500 records

Playbook C: Account Compromise

Detection indicators:

• Login from unusual country/IP
• MFA challenge failures on a previously MFA-enrolled account
• Unusual activity post-login (mass data download, new inbox rules, forwarding rules)
• Password change request from unexpected source
• User reports not recognising activity in account

Immediate actions:

1. Disable the account — not just password reset; an active session token remains valid
2. Revoke all active sessions — Azure AD: “Revoke sign-in sessions”; AWS IAM: attach deny-all policy immediately, rotate access keys
3. Audit account activity — what did the attacker do with the account? (Email forwarded? Files accessed? New accounts created?)
4. Check for persistence — new inbox rules, OAuth apps granted access, MFA methods added, new admin accounts
5. Notify the account owner — out-of-band (phone call if email is compromised)

Email account compromise specifics:

• Check inbox rules for forwarding to external addresses (attackers set up silent forwarding)
• Check for sent emails from the compromised account (BEC attempt, phishing sent to contacts)
• Check OAuth app permissions — apps granted “access to email” or “send on behalf” may maintain access even after password reset
• Check for data downloaded from OneDrive/SharePoint/Google Drive

Business Email Compromise (BEC) response: If the compromised account was used for financial fraud (wire transfer request, invoice fraud):

1. Immediately contact the financial institution to attempt to recall the transfer
2. File a report with law enforcement (CERT-In, FBI IC3, or relevant authority)
3. Contact the target organisation if another company’s employees were deceived
4. Engage legal counsel

Playbook D: Cloud Security Incident

Detection indicators:

• AWS GuardDuty/Azure Defender/GCP SCC alert
• Billing spike in unfamiliar regions
• New resources created in unexpected regions
• CloudTrail/Activity Log shows API calls from unexpected IPs or for unusual services
• Access key used after being rotated (old key still active)

Immediate actions:

1. Identify the compromised credential — review management plane logs for the identity performing unexpected actions
2. Disable the credential — IAM user, service account, or API key
3. Terminate unauthorized resources — especially in regions you don’t use (cryptomining indicator)
4. Assess scope — which resources were accessed? Was any data exfiltrated from S3/Blob/GCS? RDS/database accessed?
5. Rotate all credentials — if one credential is compromised, assume others may be; rotate all access keys and service account keys
6. Engage cloud provider support — AWS, Azure, and GCP all have security incident escalation paths and may provide credits for abuse

AWS-specific:

• GuardDuty finding: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
• Use CloudTrail Lake for fast log analysis
• Use IAM Access Analyzer to identify external sharing

Chapter 6: Eradication

Once the attacker is contained, eradicate their presence completely before recovery.

Eradication Checklist

• Identify and remove all malware (full AV scan, EDR sweep of all endpoints)
• Remove attacker-created accounts (local and domain)
• Remove attacker-created persistence mechanisms (scheduled tasks, services, registry run keys, cron jobs, SSH authorized_keys)
• Close the initial access vector (patch the vulnerability, close the port, remove the phished credential)
• Audit and reset all privileged credentials (assume all are compromised for major incidents)
• Remove attacker’s backdoors and tooling
• Verify integrity of critical systems (compare file hashes against known-good baselines)

Chapter 7: Recovery

Recovery returns affected systems to normal operation.

Recovery Sequence

1. Restore from clean backups — verify backup integrity before restoration
2. Rebuild compromised systems from known-good OS images if backup integrity is in doubt
3. Patch the vulnerability exploited for initial access before bringing systems back online
4. Implement additional controls identified during the investigation
5. Staged return — bring systems back in stages, monitoring intensively at each stage
6. Validate normal operation before declaring incident closed

Recovery Verification

• User access restored and functional
• Business processes operating normally
• No re-detection of malware or attacker activity in EDR/SIEM
• Backup systems verified operational for the next incident

Chapter 8: Post-Incident Review

Within 48 Hours — Hot Review

Capture immediate observations while memory is fresh:

• What happened, when, and in what sequence?
• What worked well in the response?
• What slowed the response?
• Any decisions that would be made differently?

Within 2 Weeks — Formal Post-Incident Review

The post-incident review (PIR) should produce:

Root cause analysis:

• Initial access vector
• Why was this vector undetected or unprotected?
• How did the attacker escalate/move laterally?
• Why was detection delayed?

Remediation actions: Each finding should become an action item with an owner and deadline:

Report: Post-incident report should be circulated to CISO, Legal, and relevant business stakeholders. For significant incidents, a board-level summary is appropriate.

Conclusion

An incident response playbook is not a guarantee — it is a structured approach that dramatically improves response effectiveness. Organisations that practice and test their playbooks respond faster, contain incidents more effectively, and emerge with lower overall impact.

Test your playbook: Conduct a tabletop exercise at least annually. Walk through a realistic scenario (ransomware attack, data breach, account compromise) and identify gaps in your plans, tooling, and communication chains.

CyberneticsPlus provides incident response retainer services, tabletop exercises, and post-incident investigation support. Contact us to build or test your incident response capability.