Skip to content

Incident Response Runbooks

Step-by-step playbooks for responding to common security incidents.

Purpose

These runbooks provide structured, repeatable procedures for responding to security incidents. They should be used in conjunction with your organisation's Incident Management Process.

Important: These are templates. Customise based on your environment, tools, and organisational structure.

General Incident Response Steps

All incident response follows this general pattern:

flowchart TD
    A[1. Detect & Report] --> B[2. Triage & Assess]
    B --> C[3. Contain]
    C --> D[4. Eradicate]
    D --> E[5. Recover]
    E --> F[6. Post-Incident Review]

Runbook 1: Ransomware Response

Objective

Contain and recover from ransomware infection while preserving evidence and minimising business impact.

Phase 1: Detection & Initial Response

Detection Indicators

  • File extensions changed (e.g., .encrypted, .locked)
  • Ransom note files appeared (README.txt, HOW_TO_DECRYPT.html)
  • Mass file encryption activity detected
  • Inability to access files or systems
  • User reports unusual file behaviour

Immediate Actions (First 15 Minutes)

  1. DO NOT TURN OFF THE INFECTED SYSTEM - This may destroy forensic evidence or encryption keys in memory

  2. Isolate the Infected System(s)

    • Disconnect from network (unplug ethernet, disable Wi-Fi)
    • Do NOT shut down (keep powered on but isolated)
    • Document system state (take photo of screen showing ransom note)

  3. Activate Incident Response Team

    • Notify CISO/Security team
    • Notify IT management
    • Assemble IR team (assign roles: Incident Commander, Technical Lead, Communications Lead)
    • Start incident log (timestamped actions)

  4. Preserve Evidence

    • Take screenshot or photo of ransom note
    • Note file extensions used
    • Do not delete ransom notes or encrypted files yet
    • Record time of detection and estimated infection time

Phase 2: Assessment (First Hour)

  1. Scope Assessment

    • Identify all affected systems (servers, workstations, file shares)
    • Check if backups are encrypted or accessible
    • Identify ransomware variant (upload ransom note to ID Ransomware or NoMoreRansom)
    • Determine patient zero (where infection started)
    • Check for data exfiltration (modern ransomware often steals data before encrypting)

  2. Impact Assessment

    • Business functions affected
    • Critical systems offline
    • Estimated recovery time
    • Data lost (if any)

  3. Decision: Containment Scope

    • Isolate affected network segments
    • Consider broader network isolation if spread is unclear
    • Do NOT immediately isolate entire network unless necessary (may impact business)

Phase 3: Containment (First 2-4 Hours)

  1. Network Containment

    • Isolate affected VLANs or network segments
    • Block lateral movement (disable SMB, RDP if not required)
    • Change all privileged account passwords
    • Disable VPN access if compromised credentials suspected
    • Monitor network traffic for ongoing C2 communication

  2. Endpoint Containment

    • Isolate additional infected systems as discovered
    • Check EDR/antivirus for alerts on other systems
    • Run emergency scans across environment

  3. Backup Protection

    • Verify backups are not encrypted
    • Disconnect backup systems from network (if not already)
    • Create offline copy of backups if possible

Phase 4: Eradication

  1. Identify Ransomware Variant

    • Submit sample to antivirus vendors
    • Check if decryptor available (NoMoreRansom.org)
    • Determine infection vector (phishing email, RDP brute force, exploit, etc.)

  2. Remove Ransomware

    • Use EDR to remove malware from affected systems
    • Check for persistence mechanisms (scheduled tasks, registry keys, startup items)
    • Rebuild systems from clean images (recommended over cleaning)
    • Patch vulnerabilities used for initial access

  3. Credential Reset

    • Reset all domain administrator passwords
    • Reset service account passwords
    • Reset VPN and remote access credentials
    • Revoke and reissue certificates if compromised

Phase 5: Recovery

  1. Restore from Backup

    • Verify backup integrity before restoration
    • Restore from most recent clean backup (before infection)
    • Restore critical systems first (order by business priority)
    • Test restored systems before returning to production

  2. Rebuild Infected Systems

    • Reimage or rebuild compromised systems from clean media
    • Apply all security patches
    • Reconfigure security settings
    • Reconnect to network only after verification

  3. Monitoring Post-Recovery

    • Enhanced monitoring for 30 days
    • Watch for reinfection or persistence
    • Monitor for data exfiltration or extortion attempts

Phase 6: Post-Incident

  1. Decision: To Pay or Not to Pay?

    • DO NOT PAY RANSOM unless:
      • No viable backups exist
      • Business-critical data will be permanently lost
      • Executive leadership approves after risk assessment
      • Legal counsel consulted (paying ransomware may be illegal in some jurisdictions)

    Note: Paying does not guarantee decryption and funds criminal activity.

  2. Regulatory Reporting

    • Report to ICO (UK GDPR breach) if personal data affected - within 72 hours
    • Notify affected individuals if high risk to rights and freedoms
    • Report to law enforcement (Action Fraud UK, FBI IC3 US)
    • Notify cyber insurance provider

  3. Lessons Learned

    • Conduct post-incident review (blameless)
    • Document timeline, actions, and decisions
    • Identify improvements (technical, process, training)
    • Update incident response plan
    • Implement remediation actions

Prevention Measures (Post-Incident)

  • Implement offline or immutable backups
  • Enable MFA on all remote access (VPN, RDP)
  • Disable SMBv1 and unnecessary file sharing protocols
  • Implement application whitelisting
  • Deploy EDR with behavioural detection
  • Conduct phishing awareness training
  • Patch management programme (critical patches within 7 days)
  • Network segmentation (isolate critical systems)

Runbook 2: Data Breach Response

Objective

Identify, contain, and remediate unauthorised access to or disclosure of sensitive data.

Phase 1: Detection & Triage

Detection Indicators

  • Unauthorised database access logs
  • Unusual data download or export activity
  • Public disclosure of company data (dark web, pastebin)
  • Third-party notification of exposed data
  • DLP alert triggered

Immediate Actions (First 30 Minutes)

  1. Confirm Breach

    • Verify incident is genuine (not false positive)
    • Identify what data was accessed/disclosed
    • Identify how access occurred (compromised credentials, misconfiguration, etc.)

  2. Activate IR Team

    • Notify CISO, DPO, Legal, Privacy team
    • Assemble incident response team
    • Start incident log

  3. Initial Containment

    • If credentials compromised: Reset immediately
    • If misconfiguration (public S3 bucket, exposed database): Fix immediately
    • Preserve evidence (logs, snapshots, screenshots)

Phase 2: Assessment (First 2-4 Hours)

  1. Scope Assessment

    • What data was accessed? (personal data, payment cards, health records, IP, etc.)
    • How much data? (number of records)
    • Who was affected? (customers, employees, partners)
    • Was data exfiltrated or just accessed?
    • Is data publicly available now?

  2. Regulatory Impact Assessment

    • Is this a GDPR breach? (personal data of EU/UK residents)
    • Is this a PCI DSS breach? (payment card data)
    • Is this a HIPAA breach? (PHI - US healthcare)
    • Other regulations (CCPA, SOX, etc.)

  3. Risk Assessment

    • Likelihood of harm to data subjects
    • Severity of potential harm
    • Sensitivity of data (PII, financial, health, etc.)
    • Likelihood of misuse

Phase 3: Containment

  1. Immediate Containment Actions

    • Revoke unauthorised access
    • Patch vulnerabilities exploited
    • Remove publicly exposed data (contact hosting provider if needed)
    • Block exfiltration paths (firewall rules, DLP)

  2. Evidence Preservation

    • Preserve access logs, audit trails
    • Take forensic images of affected systems
    • Preserve communications (emails, chats)

Phase 4: Eradication & Recovery

  1. Root Cause Remediation
    • Fix vulnerability or misconfiguration
    • Implement additional controls to prevent recurrence
    • Restore systems to secure state

Phase 5: Notification (Within 72 Hours for GDPR)

  1. Regulatory Notification

    • UK GDPR / EU GDPR:

      • Notify ICO (UK) or relevant supervisory authority within 72 hours of becoming aware
      • Include: Nature of breach, categories and approximate number of affected individuals, likely consequences, measures taken/proposed
      • Use ICO breach reporting tool: https://ico.org.uk/for-organisations/report-a-breach/

    • PCI DSS:

      • Notify payment card brands and acquiring bank immediately
      • Follow PCI Forensic Investigator (PFI) process if applicable

    • HIPAA (US):

      • Notify HHS Office for Civil Rights within 60 days (for breaches affecting 500+ individuals)
      • Notify affected individuals within 60 days

  2. Individual Notification

    • When Required (GDPR):

      • High risk to rights and freedoms of individuals
      • e.g., identity theft, discrimination, financial loss

    • Content of Notification:

      • Nature of the breach
      • Contact details of DPO or point of contact
      • Likely consequences
      • Measures taken to mitigate
      • Recommended actions for individuals (e.g., change passwords, monitor accounts)

  3. Public/Media Notification (if necessary)

    • Coordinate with PR/communications team
    • Prepare public statement (approved by legal)
    • Update website or public channels
    • Monitor media coverage

Phase 6: Post-Incident

  1. Lessons Learned

    • Post-incident review within 14 days
    • Document timeline, root cause, response effectiveness
    • Identify security improvements
    • Update incident response plan

  2. Follow-Up Actions

    • Implement technical remediation
    • Review and update policies
    • Additional training for staff
    • Ongoing monitoring for affected individuals (credit monitoring, dark web monitoring)

Runbook 3: DDoS Attack Response

Objective

Mitigate distributed denial-of-service attack and restore service availability.

Phase 1: Detection

Detection Indicators

  • Website or service unavailable
  • Extreme traffic spike (10x-100x+ normal)
  • Specific resource exhaustion (bandwidth, connections, CPU)
  • Geographically distributed source IPs

Immediate Actions (First 10 Minutes)

  1. Confirm DDoS (Not Legitimate Traffic Spike)

    • Check analytics for traffic patterns
    • Review source IPs (geographically diverse, suspicious patterns)
    • Confirm service impact (genuine users affected)

  2. Activate IR Team & Vendors

    • Notify security team, network team, service provider
    • Contact DDoS mitigation provider (if applicable: Cloudflare, Akamai, AWS Shield)
    • Start incident log

Phase 2: Mitigation

  1. Immediate Mitigation Actions

    • If using cloud DDoS protection:

      • Enable DDoS protection (AWS Shield Advanced, Azure DDoS Protection, GCP Cloud Armor)
      • Activate scrubbing centre (redirect traffic through DDoS mitigation provider)

    • If using on-premises:

      • Contact ISP for upstream filtering
      • Implement rate limiting
      • Block source IPs/countries (if attack is geographically concentrated)
      • Enable caching/CDN to absorb traffic

  2. Layer-Specific Mitigation

    • Layer 3/4 (Volumetric/Protocol Attacks):

      • ISP/cloud provider filtering
      • Blackhole routing (if last resort)

    • Layer 7 (Application Layer Attacks):

      • Web Application Firewall (WAF) rules
      • Rate limiting per IP/session
      • CAPTCHA challenges
      • Block user agents or referrers

  3. Communication

    • Update status page for customers
    • Internal communication (teams, executives)
    • Coordinate with third-party providers

Phase 3: Recovery

  1. Monitor Attack Duration

    • DDoS attacks can last minutes to days
    • Monitor traffic levels
    • Gradually restore services as attack subsides

  2. Restore Normal Operations

    • Remove temporary mitigation rules (if overly broad)
    • Verify service functionality
    • Monitor for secondary attacks

Phase 4: Post-Incident

  1. Analyse Attack

    • Attack vector (volumetric, SYN flood, HTTP flood, etc.)
    • Peak traffic volume
    • Attack duration
    • Effectiveness of mitigation

  2. Long-Term Mitigation

    • Implement DDoS protection if not already in place
    • Increase bandwidth/capacity if needed
    • Review architecture (CDN, load balancing)

  3. Reporting

    • Report to law enforcement if threat or extortion involved
    • Notify cyber insurance (if applicable)

Runbook 4: Insider Threat Response

Objective

Investigate and respond to suspected malicious or negligent insider activity.

Phase 1: Detection & Triage

Detection Indicators

  • Unusual data access or downloads
  • Access to systems outside normal duties
  • Attempts to bypass security controls
  • Data transfers to personal accounts/devices
  • Attempts to cover tracks (log deletion)

Immediate Actions

  1. Confirm Suspicion (DO NOT Alert Insider)

    • Gather initial evidence discreetly
    • Consult with HR, legal, management (strict confidentiality)
    • Determine if immediate action required (ongoing data exfiltration) or investigation needed

  2. Activate Insider Threat Team

    • CISO, HR, Legal, Security
    • Determine investigation scope
    • Assign lead investigator

Phase 2: Investigation (Discreet)

  1. Evidence Collection

    • Access logs (systems, databases, file shares)
    • Data transfer logs (email, USB, cloud uploads)
    • Endpoint activity (EDR logs, browser history)
    • Physical access logs (building entry, printer usage)
    • Communications (with legal approval: emails, Slack, etc.)

  2. Scope Assessment

    • What data was accessed?
    • Was data exfiltrated? (USB, email, cloud storage)
    • Intent (malicious vs negligent)?
    • Business impact

  3. Covert Monitoring (if ongoing activity suspected)

    • Enhanced logging on insider's account
    • Monitor activity without alerting (no access revocation yet)
    • Legal approval for monitoring

Phase 3: Containment & Action

  1. If Immediate Threat (Active Exfiltration)

  2. Immediate Containment:

    • Disable account access (coordinate with HR for timing)
    • Revoke VPN/remote access
    • Disable physical access (building badge)
    • Retrieve company devices immediately

  3. Employee Separation (coordinate with HR):

    • Conducted with witness present
    • Retrieve: laptop, phone, badge, keys, documents
    • Escort off premises
    • Document all actions

  4. If Investigation Continues

    • Continue monitoring until sufficient evidence collected
    • Coordinate with legal on employment law compliance

Phase 4: Post-Incident

  1. Legal & Regulatory

    • Consult legal on potential criminal charges
    • Report to law enforcement if criminal activity confirmed
    • GDPR breach notification if personal data involved

  2. Lessons Learned

    • Review access controls (was access appropriate?)
    • Review DLP controls (could exfiltration have been prevented?)
    • User behaviour analytics (UBA) implementation
    • Staff training on acceptable use

Incident Communication Templates

Internal Communication (Initial Notification)

SUBJECT: SECURITY INCIDENT - [SEVERITY LEVEL]

A security incident has been detected and is under investigation.

Incident Summary:
- Type: [Ransomware / Data Breach / DDoS / etc.]
- Detection Time: [YYYY-MM-DD HH:MM]
- Current Status: [Contained / Under Investigation / Ongoing]
- Business Impact: [Systems affected, services down]

Actions Required:
- [Any immediate actions for staff]

Do Not:
- Discuss externally or on social media
- Contact affected parties until instructed

Incident Commander: [Name]
Updates: [Frequency and channel]

Next Update: [Time]

Customer Communication (Data Breach Example)

SUBJECT: Important Security Notice - [Company Name]

Dear [Customer],

We are writing to inform you of a security incident that may have affected your personal information.

What Happened:
On [DATE], we discovered that [brief description of incident]. We immediately took action to [containment measures].

What Information Was Affected:
[Specific data types: names, email addresses, etc.]

What We Are Doing:
- We have secured the vulnerability
- We are conducting a thorough investigation
- We have notified relevant authorities

What You Can Do:
- Change your password immediately
- Monitor your accounts for suspicious activity
- Be vigilant for phishing emails

For more information or questions:
[Contact details]

We sincerely apologise for this incident and are committed to protecting your information.

[Name, Title]
[Company]

Key Contacts

Maintain a contact list for incidents:

Role Contact Phone Email
Incident Commander [Name]
CISO [Name]
IT Director [Name]
DPO (Data Protection Officer) [Name]
Legal Counsel [Name]
HR Director [Name]
PR/Comms [Name]
Cyber Insurance [Provider]
DDoS Mitigation [Provider]
Forensics Partner [Company]
Law Enforcement Action Fraud (UK), FBI IC3 (US)