Incident Response Checklist

Introduction

When a security incident hits, stress levels spike and clear thinking becomes a luxury. The difference between a controlled response and a chaotic scramble often comes down to one thing: preparation. A well-maintained checklist won't replace expertise, but it will ensure critical steps aren't missed when the pressure is highest.

This checklist follows the incident response lifecycle defined in NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide), adapted with lessons learned from real-world engagements across industries. It covers five phases: Preparation, Detection & Analysis, Containment, Eradication & Recovery, and Post-Incident Activity.

Print it. Pin it to the wall in your SOC. Customize it for your environment. The goal isn't to follow it blindly — it's to ensure nothing falls through the cracks when every minute counts.

Phase 1: Preparation

Preparation is the phase you invest in before anything goes wrong. Every hour spent here pays dividends when an incident occurs. The goal is to ensure your people, processes, and technology are ready to detect, respond to, and recover from security incidents.

• Maintain an up-to-date asset inventory covering hardware, software, cloud services, and data repositories
• Document the incident response plan and review it at least annually or after significant organizational changes
• Maintain a current contact roster including IR team members, legal counsel, executive management, PR/communications, law enforcement liaisons, insurance contacts, and key vendors
• Ensure forensic tool kits are staged, tested, and accessible — include write blockers, forensic imaging tools, and network capture utilities
• Verify backup integrity on a regular schedule and test full restoration procedures at least quarterly
• Establish out-of-band communication channels (e.g., a dedicated messaging platform, satellite phones, or pre-configured burner devices) in case primary channels are compromised
• Prepare communication templates for internal notifications, customer disclosures, regulatory filings, and media statements
• Review and test log collection and retention policies — ensure critical logs are forwarded to a centralized, tamper-resistant store with sufficient retention
• Conduct tabletop exercises at least twice per year, rotating scenarios to cover ransomware, data breach, insider threat, supply chain compromise, and business email compromise
• Establish and maintain relationships with external IR providers so retainer agreements and NDAs are in place before you need them
• Review cyber insurance coverage annually — understand notification requirements, approved vendor lists, coverage limits, and exclusions
• Document network topology and data flow diagrams, including cloud environments, third-party integrations, and remote access pathways
• Store credentials for critical systems (domain admin, hypervisor, firewall, backup) in a secure offline location accessible to authorized IR personnel
• Define incident severity levels (e.g., SEV1 through SEV4) with clear escalation criteria, response time expectations, and authority levels
• Pre-authorize emergency actions such as network segment isolation, account lockdowns, and system shutdowns — document who can authorize what
• Ensure endpoint detection and response (EDR) coverage across all endpoints, including servers, workstations, and cloud workloads
• Maintain a current list of crown-jewel assets and the data classification of information they hold
• Review regulatory notification requirements relevant to your industry and operating jurisdictions (NIS2, GDPR, sector-specific regulations)

Phase 2: Detection & Analysis

Detection is where the incident response process truly begins. The quality of your initial analysis directly shapes every decision that follows. Move quickly, but don't sacrifice accuracy — a misidentified incident type can send your team down the wrong path entirely.

• Validate the alert — rule out false positives by correlating across multiple data sources (SIEM, EDR, network logs, user reports)
• Determine incident scope and assign an initial severity classification based on your predefined criteria
• Identify all affected systems, user accounts, and data stores — assume the scope is larger than initial evidence suggests
• Establish an incident timeline starting from the first known indicator of compromise (IOC) through the present
• Document initial indicators of compromise: file hashes, IP addresses, domain names, email addresses, registry keys, and behavioral patterns
• Activate the incident response team and assign clear roles: incident commander, technical lead, communications lead, documentation lead
• Open an incident tracking ticket in your case management system with a unique incident identifier
• Begin a detailed incident log with timestamped entries for every action taken, decision made, and finding discovered
• Determine whether the threat actor is still active in the environment — this fundamentally changes your containment approach
• Identify the attack vector: phishing, vulnerability exploitation, credential theft, supply chain compromise, insider action, or physical access
• Assess data exposure risk — determine whether regulated data (PII, PHI, financial), intellectual property, or credentials have been accessed or exfiltrated
• Notify relevant stakeholders per your escalation criteria — don't wait for complete information to begin escalation
• Engage legal counsel immediately if a data breach involving personal data is suspected — legal privilege considerations matter
• Preserve volatile evidence (running processes, network connections, memory contents) before any containment actions that could alter system state
• Check threat intelligence feeds for known campaigns matching observed TTPs (Tactics, Techniques, and Procedures)

Phase 3: Containment

Containment is about stopping the bleeding without destroying evidence or tipping off an adversary who's still watching. There are two sub-phases: short-term containment (stop the immediate damage) and long-term containment (maintain a stable state while you prepare for eradication). The balance between speed and caution depends on whether the attacker is still active.

Short-Term Containment

• Isolate affected systems from the network — use EDR network isolation, VLAN changes, or physical disconnection depending on urgency
• Block identified IOCs (malicious IPs, domains, file hashes) at the firewall, proxy, DNS resolver, and email gateway
• Disable compromised user accounts and revoke active sessions, including OAuth tokens and API keys
• Capture forensic images of affected systems before any remediation — this is your evidence and you cannot recreate it later
• Collect and preserve relevant logs from SIEM, EDR, firewalls, proxies, DNS, authentication systems, and cloud audit logs
• If email is compromised, establish a clean communication channel immediately — do not discuss response plans over a compromised medium

Long-Term Containment

• Reset credentials for affected and potentially affected accounts — err on the side of broader resets when in doubt
• Redirect DNS for compromised domains or implement DNS sinkholing for C2 communication channels
• Implement enhanced monitoring on adjacent systems and network segments to detect lateral movement attempts
• Apply temporary access control changes to limit exposure while maintaining essential business operations
• Document all containment actions with precise timestamps and the rationale behind each decision
• Continuously assess whether containment measures are holding — monitor for new IOCs or containment bypass attempts
• Evaluate whether business continuity plan activation is needed and communicate with business stakeholders accordingly
• Ensure forensic evidence chain of custody is maintained for any systems that may be involved in legal proceedings

Phase 4: Eradication & Recovery

Eradication removes the threat from your environment. Recovery restores normal operations. Both must be done thoroughly — a rushed eradication invites re-compromise, and a rushed recovery reintroduces risk. Patience here is not a luxury; it's a discipline.

• Identify and remove all malware, backdoors, web shells, and persistence mechanisms (scheduled tasks, registry run keys, startup items, cron jobs, WMI subscriptions)
• Patch the exploited vulnerabilities that enabled initial access — if a patch isn't available, implement compensating controls
• Rebuild compromised systems from known-good images or installation media — do not attempt to "clean" a system you cannot fully trust
• Reset all credentials within the affected scope, not just those known to be compromised — include service accounts, API keys, and machine credentials
• If Active Directory is compromised, reset the KRBTGT account password twice (with appropriate interval) and review all privileged group memberships
• Verify the integrity of restored systems using file integrity monitoring, trusted hashes, and behavioral analysis before reconnecting to production
• Implement additional security controls identified during the investigation to prevent recurrence of the same or similar attack
• Restore systems in priority order based on business criticality and dependency mapping — start with authentication infrastructure
• Monitor restored systems closely for at least 72 hours for any signs of re-compromise, residual malware, or beacon activity
• Validate that your detection capabilities (SIEM rules, EDR signatures, network detection) can now identify the specific attack methods used
• Update firewall rules, IDS/IPS signatures, and email filtering rules based on all IOCs and TTPs discovered during the investigation
• Gradually restore network connectivity between segments, monitoring traffic patterns at each stage
• Confirm with all relevant stakeholders — IT operations, business owners, legal, and management — before formally declaring the incident resolved

Phase 5: Post-Incident Activity

The post-incident phase is where good teams become great teams. Every incident is a learning opportunity, but only if you capture and act on the lessons. This phase is not optional — it's where you build the institutional memory that makes the next response faster and more effective.

• Conduct a post-incident review (blameless retrospective) within 5 business days while details are still fresh — include all participants, not just the IR team
• Produce a comprehensive final incident report covering: complete timeline, root cause analysis, business impact assessment, response actions taken, what worked, what didn't, and specific recommendations
• Update the incident response plan based on lessons learned — close the loop between what happened and what you'll do differently next time
• Submit regulatory notifications within required timeframes — NIS2 requires a 24-hour early warning and a 72-hour full notification to the competent authority
• Notify affected individuals if personal data was compromised, following GDPR Article 34 criteria and any sector-specific requirements
• File a cyber insurance claim if applicable — provide the insurer with the incident timeline, impact assessment, and remediation costs
• Brief executive leadership on the incident, response effectiveness, residual risk, and recommended security investments
• Update detection rules, monitoring dashboards, and threat hunting queries based on all findings from the investigation
• Schedule a follow-up assessment (30-60 days post-incident) to verify that all remediation actions have been completed and are effective
• Archive all incident documentation — logs, forensic images, communications, decisions, and the final report — in a secure, access-controlled repository with appropriate retention

Adapting This Checklist

This checklist is a starting point, not a finished product. Every organization has unique infrastructure, regulatory obligations, risk tolerance, and team structures. Take this framework and tailor it:

• Add environment-specific items — if you run OT/ICS systems, add items for safely isolating operational technology without disrupting physical processes
• Map to your tools — replace generic references ("SIEM", "EDR") with the specific products your team uses and include quick-reference commands
• Assign owners — attach a responsible role or individual to each checklist item so there's no ambiguity during an incident
• Version control it — treat your IR checklist like code. Track changes, review updates, and ensure everyone is working from the current version
• Test it — run tabletop exercises against this checklist to find gaps before a real incident does