A comprehensive, actionable checklist and implementation guide for NIST Special Publication 800-61 Revision 2, "Computer Security Incident Handling Guide." This resource is designed for organizations of all sizes that need to establish, maintain, or improve their incident response capabilities, including building a Computer Security Incident Response Team (CSIRT), implementing the four-phase incident response lifecycle, preserving digital evidence, and meeting breach notification requirements.
Full compliance guide: https://petronellatech.com/compliance/nist-800-61-incident-response/
Last Reviewed: March 2026
NIST SP 800-61 Rev. 2, published by the National Institute of Standards and Technology in August 2012, provides guidelines for establishing computer security incident response capabilities and handling incidents efficiently and effectively. The publication covers the entire incident response lifecycle, from preparation and planning through detection, analysis, containment, eradication, recovery, and post-incident activities.
Incident response is not optional. Every organization that operates information systems will experience security incidents. The question is not whether an incident will occur but when, and whether the organization will be prepared to respond effectively. A well-structured incident response program minimizes damage, reduces recovery time and costs, preserves evidence for potential legal proceedings, and satisfies regulatory notification requirements.
NIST SP 800-61 is referenced by virtually every major compliance framework. HIPAA requires covered entities to have incident response procedures under the Security Rule (45 CFR 164.308(a)(6)). PCI DSS Requirement 12.10 mandates an incident response plan. CMMC practices CA.L2-3.12.1 through CA.L2-3.12.3 require incident response capabilities. FISMA and the Federal Information Security Modernization Act require agencies to follow NIST guidelines for incident handling. The publication serves as the de facto standard for how organizations should prepare for and respond to cybersecurity incidents.
The revision 3 draft (NIST SP 800-61 Rev. 3) was published in 2024 and focuses on integrating incident response with the NIST Cybersecurity Framework (CSF) 2.0. Organizations should monitor https://csrc.nist.gov/publications/detail/sp/800-61/rev-3/draft for the final publication. Until Rev. 3 is finalized, Rev. 2 remains the authoritative guidance. The current Rev. 2 document is available at https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final.
NIST SP 800-61 directly supports multiple control families in NIST SP 800-53 Rev. 5, the master catalog of security and privacy controls. The most directly related control family is IR (Incident Response), which contains 10 controls:
- IR-1: Incident Response Policy and Procedures
- IR-2: Incident Response Training
- IR-3: Incident Response Testing
- IR-4: Incident Handling
- IR-5: Incident Monitoring
- IR-6: Incident Reporting
- IR-7: Incident Response Assistance
- IR-8: Incident Response Plan
- IR-9: Information Spillage Response
- IR-10: Integrated Information Security Analysis Team
SP 800-61 provides the detailed implementation guidance for satisfying these controls. When an organization implements IR-4 (Incident Handling), the four-phase lifecycle described in SP 800-61 is the methodology. When implementing IR-8 (Incident Response Plan), the plan structure and content recommendations in SP 800-61 define what the plan should contain.
Beyond the IR family, incident response capabilities also support controls in the AU (Audit and Accountability), SI (System and Information Integrity), CP (Contingency Planning), and RA (Risk Assessment) families. Effective incident response requires log collection (AU-6), malicious code protection (SI-3), system monitoring (SI-4), and feeds into risk assessment updates (RA-3).
Preparation is the foundation of effective incident response. This phase focuses on establishing the incident response capability before incidents occur.
Building the CSIRT:
- Define the CSIRT mission, scope, and authority within the organization
- Determine the CSIRT organizational model (centralized, distributed, coordinated, or hybrid)
- Assign incident response roles: Incident Manager, Incident Handler, Triage Analyst, Forensic Analyst, Communications Lead
- Establish escalation procedures and decision-making authority
- Define relationships with external parties (law enforcement, ISACs, vendors, legal counsel)
Incident Response Plan Development:
- Create a formal incident response policy approved by senior management
- Develop incident response procedures for common incident types (malware, unauthorized access, denial of service, insider threat, data breach)
- Establish incident severity classifications (Critical, High, Medium, Low)
- Define communication procedures (internal and external)
- Document evidence handling and chain-of-custody procedures
- Establish criteria for engaging law enforcement and legal counsel
Infrastructure and Tooling:
- Deploy and configure intrusion detection/prevention systems (IDS/IPS)
- Implement centralized log management and SIEM capabilities
- Prepare forensic workstations with validated tools
- Maintain jump bags with essential response tools and documentation
- Establish secure communication channels for incident response (out-of-band)
- Configure network monitoring and packet capture capabilities
Training and Testing:
- Conduct incident response training for all CSIRT members
- Perform tabletop exercises at least annually
- Conduct functional exercises simulating realistic attack scenarios
- Test communication procedures and escalation paths
- Review and update the incident response plan based on exercise findings
Detection and analysis is often the most challenging phase. Organizations must identify that an incident has occurred, determine its scope and severity, and prioritize response actions.
Detection Sources:
- Security alerts from IDS/IPS, SIEM, EDR, and antivirus systems
- User and administrator reports of suspicious activity
- Log analysis revealing anomalous patterns
- Threat intelligence feeds identifying relevant indicators of compromise (IOCs)
- External notifications from partners, ISACs, law enforcement, or vendors
- Automated anomaly detection systems
Analysis Activities:
- Correlate events from multiple data sources to confirm the incident
- Determine the attack vector and initial point of compromise
- Identify affected systems, networks, and data
- Assess the scope and severity of the incident
- Determine whether the incident is ongoing or has been contained
- Identify the threat actor type and capabilities (if possible)
- Document the incident timeline from initial compromise through detection
Incident Documentation:
- Assign an incident tracking number
- Record all relevant details in the incident tracking system
- Document the current status, actions taken, and pending actions
- Maintain a running timeline of events and response activities
- Preserve all evidence with proper chain-of-custody documentation
Once an incident is confirmed and analyzed, the response team must contain the threat, eliminate it from the environment, and restore normal operations.
Containment Strategies:
- Short-term containment: Isolate affected systems to prevent lateral movement (network segmentation, disabling accounts, blocking IPs)
- Evidence preservation: Create forensic images of affected systems before making changes
- Long-term containment: Apply temporary fixes to allow continued operation while preparing for eradication (patching, configuration changes, enhanced monitoring)
- Decision criteria: Document the rationale for containment decisions, balancing operational impact against risk
Eradication Activities:
- Identify and remove all artifacts of the incident (malware, backdoors, unauthorized accounts)
- Identify and remediate the root cause (vulnerability, misconfiguration, compromised credential)
- Verify eradication through scanning, monitoring, and manual verification
- Reset compromised credentials and certificates
- Apply patches and configuration changes to prevent recurrence
Recovery Activities:
- Restore affected systems from known-good backups or rebuild from trusted media
- Verify system integrity before returning to production
- Implement enhanced monitoring for previously affected systems
- Gradually restore services with validation at each stage
- Confirm normal operations and close the active response phase
Post-incident activities transform individual incidents into organizational learning opportunities and drive improvements to the incident response program.
Lessons Learned:
- Conduct a formal lessons-learned meeting within two weeks of incident closure
- Document what happened, what was done, what worked, and what needs improvement
- Identify gaps in detection, analysis, containment, and recovery procedures
- Update the incident response plan based on findings
- Share relevant findings with appropriate stakeholders (sanitized as needed)
Evidence Retention:
- Retain all incident evidence per the organization's evidence retention policy
- Maintain chain-of-custody documentation for all preserved evidence
- Ensure evidence is stored securely and access is restricted
- Document retention periods based on regulatory requirements and potential legal proceedings
Metrics and Reporting:
- Track key incident metrics: time to detect, time to contain, time to recover, total incidents by type and severity
- Report incident trends to senior management on a regular basis
- Use metrics to justify resource allocation and program improvements
Evidence preservation is critical both for incident analysis and for potential legal proceedings. Digital evidence is fragile and can be easily altered or destroyed if not handled properly.
Order of Volatility (collect in this order):
- CPU registers and cache
- Routing tables, ARP cache, process table, kernel statistics
- Memory (RAM)
- Temporary file systems
- Disk storage
- Remote logging and monitoring data
- Physical configuration and network topology
- Archival media
Chain of Custody Requirements:
- Document who collected the evidence, when, where, and how
- Record every transfer of evidence between parties
- Use write-blockers when imaging storage media
- Generate and verify cryptographic hashes (SHA-256) of all evidence
- Store evidence in tamper-evident containers
- Maintain a detailed evidence log with unique identifiers
Multiple federal and state laws impose breach notification obligations. The incident response plan must account for these requirements:
| Regulation | Notification Requirement | Timeline |
|---|---|---|
| HIPAA (HHS) | Notify affected individuals, HHS, and media (500+ records) | 60 days from discovery |
| FISMA/US-CERT | Report incidents to CISA | 1 hour (major incidents) |
| PCI DSS | Notify payment brands and acquiring bank | Immediately upon discovery |
| State Breach Laws | Varies by state; most require notification to residents | 30 to 90 days (varies) |
| SEC Rules (2023) | Material cybersecurity incidents on Form 8-K | 4 business days |
| GDPR (EU) | Notify supervisory authority and data subjects | 72 hours |
| CCPA/CPRA (CA) | Notify affected California residents | "Most expedient time possible" |
| DFARS 252.204-7012 | Report cyber incidents to DoD via DIBNet | 72 hours |
| Model | Description | Best For |
|---|---|---|
| Centralized | Single team handles all incidents | Small to mid-size organizations |
| Distributed | Multiple teams in different locations/business units | Large, geographically dispersed organizations |
| Coordinated | Central team coordinates, local teams execute | Organizations with autonomous business units |
| Hybrid | Combines elements of the above models | Complex organizations with varying needs |
| Category | Examples | Typical Severity |
|---|---|---|
| Unauthorized Access | Compromised credentials, privilege escalation, insider misuse | High to Critical |
| Malware | Ransomware, trojans, rootkits, wipers | High to Critical |
| Denial of Service | DDoS attacks, resource exhaustion | Medium to High |
| Data Breach | Exfiltration, accidental exposure, lost devices | High to Critical |
| Web Application Attack | SQL injection, XSS, CSRF, API abuse | Medium to High |
| Insider Threat | Data theft, sabotage, policy violation | Medium to Critical |
| Supply Chain Compromise | Compromised software update, third-party breach | High to Critical |
Traditional incident response depends heavily on human analysts to triage alerts, correlate events, and make containment decisions. With the volume of security events in modern environments reaching tens of thousands per day, manual analysis creates dangerous delays between detection and response.
Petronella Technology Group leverages its private AI fleet, including on-premise large language models and custom GPU infrastructure, to revolutionize incident response. PTG's AI-powered security operations automate alert triage, correlate events across multiple data sources in real time, and recommend containment actions within seconds of detection. This reduces mean time to detect (MTTD) and mean time to respond (MTTR) from hours or days to minutes.
PTG's unique combination of AI capability and licensed digital forensic expertise (Licensed Digital Forensic Examiner #604180) means that when containment is complete, the same team can conduct forensically sound investigations, preserve evidence for legal proceedings, and provide expert testimony if needed. Most managed security service providers (MSSPs) and compliance firms lack this combination of capabilities.
PTG's patented technology stack automates evidence collection, timeline reconstruction, and indicator-of-compromise extraction, tasks that traditionally require hours of manual analyst work.
Q: What is the difference between an event, an adverse event, and an incident? A: An event is any observable occurrence in a system or network. An adverse event is an event with negative consequences, such as a system crash or unauthorized access attempt. A security incident is a violation or imminent threat of violation of security policies, acceptable use policies, or standard security practices. Not all adverse events are incidents, and not all events are adverse.
Q: How often should we test our incident response plan? A: NIST recommends testing the incident response plan at least annually. Best practice is to conduct tabletop exercises quarterly and a full functional exercise annually. Organizations in regulated industries (healthcare, financial services, defense) may have more frequent testing requirements. Every significant incident should also trigger a review of the plan.
Q: Do we need a dedicated CSIRT, or can incident response be a collateral duty? A: NIST SP 800-61 acknowledges that not every organization can maintain a full-time, dedicated CSIRT. Small and mid-size businesses may designate incident response as a collateral duty for IT staff or engage a managed security services provider (MSSP) for incident response support. The critical requirement is that roles, responsibilities, and procedures are clearly defined and tested regardless of the staffing model.
Q: What should we do if we discover an incident was caused by a nation-state actor? A: Contact the FBI (through your local field office or IC3.gov) and CISA immediately. Do not attempt to "hack back" or engage the threat actor. Preserve all evidence, document the timeline, and follow your incident response plan. Nation-state incidents often involve classified threat intelligence that federal agencies can provide to assist your response.
Q: How long should we retain incident evidence? A: Retention periods depend on regulatory requirements, legal holds, and organizational policy. HIPAA requires six years for security documentation. Federal agencies must follow NARA records schedules. For incidents that may involve litigation, evidence should be retained until legal counsel advises it is safe to dispose. A minimum retention period of three years is a common baseline for most organizations.
Q: What is the role of law enforcement in incident response? A: Law enforcement (FBI, Secret Service, state/local agencies) can provide threat intelligence, investigative resources, and legal authority that internal teams lack. The decision to engage law enforcement should be made early in the incident lifecycle, ideally during the Preparation phase by establishing relationships before an incident occurs. Your incident response plan should document the criteria and process for engaging law enforcement.
Q: How do we handle incidents involving third-party service providers? A: Review your contracts and service-level agreements for incident notification requirements. Most cloud service agreements include shared responsibility models for incident response. Establish communication channels and escalation procedures with critical third-party providers before an incident occurs. During an incident, coordinate response activities and ensure evidence is preserved across all affected parties.
Q: What metrics should we track for our incident response program? A: Key metrics include: number of incidents by type and severity, mean time to detect (MTTD), mean time to respond (MTTR), mean time to contain (MTTC), mean time to recover, percentage of incidents detected internally vs. externally reported, percentage of incidents requiring escalation, and lessons-learned completion rate. Track these metrics over time to demonstrate program maturity and justify resource requests.
This checklist was developed by Craig Petronella, founder and CEO of Petronella Technology Group, Inc. Craig brings over 23 years of cybersecurity experience and holds the following credentials:
- CMMC Registered Practitioner (RP)
- Licensed Digital Forensic Examiner #604180
- Cisco CCNA and CWNE certifications
- MIT Artificial Intelligence Certificate
- Amazon #1 Best-Selling Author of 14+ cybersecurity books
Craig's forensic expertise is particularly relevant to incident response. As a Licensed Digital Forensic Examiner, he has conducted hundreds of forensic investigations, preserved evidence for legal proceedings, and provided expert testimony in cases involving data breaches, insider threats, and intellectual property theft.
Petronella Technology Group, Inc. is a Raleigh, NC-based cybersecurity, compliance, and AI services firm that specializes in making enterprise-grade compliance accessible to small and mid-size businesses. PTG combines AI development (custom AI agents, private LLMs, GPU hosting) with deep cybersecurity and compliance expertise, a combination that no other firm in the Research Triangle offers.
What sets PTG apart:
- AI-Powered Compliance: PTG operates its own private AI fleet with on-premise large language models and custom GPU infrastructure to accelerate compliance assessments, automate control mapping, and continuously monitor security posture.
- Patented Technology Stack: PTG's proprietary, patented security and compliance tools automate what competitors do manually.
- Licensed Digital Forensic Examiner: When compliance fails and a breach occurs, PTG has the forensic expertise to investigate, preserve evidence, and support legal proceedings. Most compliance firms cannot do this.
- Fleet Infrastructure: PTG's on-premise AI infrastructure (GPU clusters, private cloud) proves PTG practices what it preaches about data sovereignty and private AI.
Contact PTG:
- Phone: 919-348-4912
- Address: 5540 Centerview Dr. Suite 200, Raleigh, NC 27606
- Website: https://petronellatech.com
- Compliance Services: https://petronellatech.com/compliance/packages/
- Incident Response Guide: https://petronellatech.com/compliance/nist-800-61-incident-response/
Is your organization prepared to handle a cybersecurity incident? Call 919-348-4912 or schedule a free compliance assessment to evaluate your incident response readiness.
- NIST SP 800-53 Compliance Guide
- NIST SP 800-171 Compliance Guide
- HIPAA Security Guide
- CMMC Compliance Guide
- PTG Cybersecurity Services
- PTG AI Services
- SOC 2 Compliance Guide
This checklist is released under the MIT License. See LICENSE for details.