NIST SP 800-61
the federal incident handling framework, the four-phase cycle, the operating record

NIST SP 800-61 explained for security operations, AppSec, and GRC teams

NIST Special Publication 800-61 (Computer Security Incident Handling Guide) is the United States federal reference for how organisations build and operate an incident response capability. Revision 2 (the long-stable working text) names the four-phase incident handling cycle (preparation, detection and analysis, containment-eradication-recovery, post-incident activity), the three IR team organisational models, the IR services the capability provides, the data sources incident handlers read against, and the recommended practices for handling specific incident categories. Revision 3 (currently in update) aligns the framework against NIST CSF 2.0, the Cybersecurity Performance Goals, and the post-2020 landscape that the original revision predated.

For internal security teams running the live response, security operations leaders accountable for incident outcomes, AppSec and product security teams owning the application and software-side incident categories, GRC and compliance teams producing the audit pack, and CISOs at federal contractor organisations, FedRAMP-authorised systems, public-company US registrants subject to the SEC cybersecurity disclosure rule, EU financial entities subject to DORA, EU essential and important entities subject to NIS2, regulated healthcare entities under HIPAA, PCI-scope merchants and service providers, and SOC 2 service organisations, NIST SP 800-61 is the operating reference the IR discipline reads against. It pairs with ISO/IEC 27035 as the international counterpart and reads beneath NIST SP 800-53 Rev 5 IR control family as the working operating discipline.

This page walks through the scope of the publication, the four-phase incident handling cycle, the three IR team models, the operating-record artefact set, the recommended practices per incident category, the failure modes the framework surfaces, the relationship with adjacent regimes, and where NIST SP 800-61 sits alongside the incident response operating workflow, the breach notification and regulator readiness workflow, and the incident response plan guide. Programmes that adopt NIST 800-61 as the working reference, ISO/IEC 27035 as the international anchor, and NIST 800-53 IR family as the assessable control set produce a coherent operating posture that holds up under FedRAMP, FISMA, CMMC, ISO 27001, NIS2, DORA, SOC 2, PCI DSS, HIPAA, SEC, and audit-committee scrutiny on one operating record.

What NIST SP 800-61 covers

NIST 800-61 is the operating reference for incident handling as a programme rather than as a one-off plan. It is broader than a runbook and narrower than the full security operating baseline; the boundary is the incident lifecycle, from preparation through detection and analysis, containment-eradication-recovery, and post-incident activity. Read against the wider NIST library, 800-61 is the working IR text the rest of the IR-relevant publications cluster around.

The four-phase incident handling cycle

NIST 800-61 names a four-phase incident handling cycle. The phases are not separate processes; they are stages on the same incident record, each with named outputs the next phase reads against. Preparation produces the policy, the plan, the team, and the readiness; detection and analysis produces the structured intake and the analysis decision; containment-eradication-recovery produces the response action ledger, the evidence record, and the regulator notification artefacts; and post-incident activity produces the lessons-learned review and the policy update that feeds the next preparation iteration.

1. 1

   Phase 1: Preparation

   The programme produces the documented incident response policy, the IR plan, the named team and role assignments, the communication plan (internal stakeholders, regulators, customers, partners, counsel, law enforcement, public communications), the response procedures, the training and exercise cadence, the technical readiness (logging architecture, asset inventory, evidence collection capability, forensic tooling, encrypted storage for sensitive artefacts), and the agreements with external parties (counsel, forensic providers, communications support, cyber insurance carrier, peer IR teams, ISACs). Preparation is the phase the next three phases depend on. NIST 800-61 expects preparation to be funded, measured, and refreshed on a documented cadence rather than treated as a one-off setup.

2. 2

   Phase 2: Detection and analysis

   The programme detects the security event from monitoring (SIEM, EDR, NDR, IDS, application logs), scanner output, user report, third-party notification, partner advisory, supplier disclosure, or ISAC bulletin, and opens the structured incident record. Analysis covers the categorisation of the incident type (malware, unauthorised access, data exposure, denial of service, supply-chain compromise, insider abuse, social engineering, web defacement, AI-system misuse, ransomware), the calibrated severity, the prioritisation against active cases, the analyst notes against the documented decision criteria, and the determination of containment strategy. NIST 800-61 names attack vectors, signs of incidents (precursors and indicators), and recommended analysis steps the IR team works against.

3. 3

   Phase 3: Containment, eradication, and recovery

   Containment stops the incident from spreading further. Eradication removes the cause from affected systems. Recovery restores affected systems and verifies they are operating correctly. NIST 800-61 names containment strategies per attack vector (network segmentation, account disablement, host isolation, traffic blocking, application-layer controls), eradication procedures (malware removal, vulnerability remediation, credential rotation, configuration rollback, system rebuild), and recovery verification (functional testing, monitoring reactivation, vulnerability rescanning, integrity verification). The phase produces the response action ledger, the evidence preservation record, the regulator notifications dispatched against documented clocks, and the customer and partner notifications coordinated with counsel and communications.

4. 4

   Phase 4: Post-incident activity

   The programme closes the case with a structured lessons-learned review (what happened, what worked, what failed, what the programme will change), updates the policy and procedures where the incident exposed gaps, schedules the follow-on testing and exercising the gaps require, retains evidence according to the documented schedule, and feeds the metric pack reporting to leadership. NIST 800-61 expects the lessons-learned meeting to be held within a documented window, with named participants, a documented agenda, and a published action item ledger the next preparation iteration reads against. Post-incident activity is the phase that turns the response into the next preparation cycle.

The three IR team organisational models

NIST 800-61 names three IR team structural models. Programmes choose the model against the size, geography, federation, and operating culture of the organisation. The framework is agnostic about which model is correct; it expects the model choice to be documented and operated as a coherent posture rather than allowed to drift into an ambiguous federation the executive layer cannot read.

The operating-record artefact set

NIST 800-61 expects a defined artefact set rather than a single document. The pack below is the minimum durable set most programmes maintain when they adopt 800-61 as the operating baseline. Each artefact carries a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail.

Incident categories the framework covers

NIST 800-61 names recommended practices for handling specific incident categories rather than treating every incident with one generic procedure. The category catalogue below is the working set most programmes exercise against. Programmes that build per-category playbooks rather than relying on one generic IR procedure discover the per-category details (containment mechanism, eradication procedure, evidence preservation requirement, regulator notification clock, communications template) before they need them under pressure.

Failure modes the framework surfaces

NIST 800-61 is forgiving on the choice of tooling, the wording of the IR policy, the exact phase boundaries, and the IR team model. It is unforgiving about a small number of patterns that turn the incident response programme cosmetic rather than operational. The patterns below recur across IR programmes and are the ones that erode response confidence and audit defensibility most reliably.

How NIST SP 800-61 relates to adjacent regimes

NIST 800-61 sits in a busy regulatory and assurance neighbourhood. The relationships below are the ones programmes encounter most often when they read 800-61 against the rest of the operating regime. Programmes operating across regions, sectors, and customer bases use 800-61 as the working IR reference and read ISO/IEC 27035, NIST CSF 2.0, NIST 800-53 IR family, NIS2, DORA, SOC 2, PCI DSS, HIPAA, and the SEC disclosure rule as the contextual layers around it.

Where NIST SP 800-61 sits next to other framework pages

NIST 800-61 is the working IR reference; the adjacent framework pages cover the regimes the IR programme reads alongside. The pages below are the ones IR programmes most often read together.

• The ISO/IEC 27035 framework page covers the international counterpart published in three parts (principles, planning, operations) with a five-phase cycle that maps cleanly onto the 800-61 four-phase cycle.
• The NIST CSF 2.0 framework page covers the framework-level outcome model. The Respond function (RS.MA, RS.AN, RS.CO, RS.MI) and Recover function (RC.RP, RC.CO, RC.IM) read against 800-61 as the working implementation reference.
• The NIST SP 800-53 framework page covers the certifiable federal control catalogue. The IR control family (IR-1 through IR-10) reads against 800-61 as the working operating discipline assessors read into.
• The NIS2 framework page covers the EU directive on cybersecurity for essential and important entities. Article 21 (security risk management measures) and Article 23 (reporting obligations on significant incidents) read against the same operating discipline 800-61 names with EU-specific regulator clocks layered on.
• The DORA framework page covers the EU Digital Operational Resilience Act for financial entities. Articles 19 and 20 (ICT-related incident management process and reporting of major ICT-related incidents) read against 800-61 with DORA-specific four-hour initial notification clocks.
• The SEC cybersecurity disclosure framework page covers the public-company disclosure rule. Item 1.05 materiality disclosure within four business days of materiality determination reads against the chronology and impact assessment 800-61 already produces as the residue of the four-phase cycle.
• The SOC 2 framework page covers the AICPA Trust Services Criteria. CC7.3 through CC7.5 and CC9.1 read against the same incident management discipline 800-61 names with examiner-side evidence expectations.
• The PCI DSS framework page covers the payment card industry data security standard. Requirement 12.10 (incident response plan, training, monitoring, exercising) reads against a subset of 800-61 scoped to the cardholder data environment.
• The HIPAA framework page covers the US healthcare privacy and security rules. 45 CFR 164.308(a)(6) and the HITECH Breach Notification Rule read against the operating discipline 800-61 already names with HIPAA-specific breach notification clocks.
• The ISO/IEC 27001 framework page covers the certifiable ISMS standard. Annex A controls 5.24 through 5.30 (incident management policy, roles, knowledge gain, evidence collection, response, learning, ICT readiness) read against the same operating discipline 800-61 names from the international ISMS direction.
• The ISO/IEC 27031 framework page covers the ICT readiness for business continuity standard. The integration point between operational IR (where 800-61 lives) and IRBC recovery declaration (where 27031 lives) is the handoff the holistic principle expects.
• The ISO 22301 framework page covers the certifiable business continuity management system (BCMS) standard ISO/IEC 27031 sits beneath. The same operational-IR-to-BCMS-recovery handoff 27031 names at the ICT layer reads against ISO 22301 at the wider organisational layer, with the BCMS carrying the activity-level continuity commitments the IR phase hands off into.
• The CISA Secure by Design framework page covers the CISA principles for software producers and US federal partners. The IR readiness commitments inside the principles read against 800-61 as the operating reference.

Where SecPortal fits in a NIST SP 800-61 programme

SecPortal is the operating layer for the incident management case lifecycle, not a replacement for the detection telemetry platforms, the forensic investigation tooling, the operational response actions, the legal counsel and communications partnerships, or the crisis management discipline. The platform handles the case-side workstreams (detection intake, analysis decision, containment-eradication-recovery actions, communications log, evidence custody, post-incident review, lessons-learned action items, exercising trail) so the artefacts the policy commits to are produced as structured records rather than reconstructed across email threads, ticketing systems, and document drives at audit time. The same workspace that hosts the incident record hosts the SAST, dependency analysis, authenticated DAST, external scanning, and continuous monitoring evidence the response and post-incident verification phases depend on.

What SecPortal does not do

NIST 800-61 is a working programme reference that depends on the organisation operating detection, forensic investigation, technical response, legal counsel, communications, and crisis management as coordinated functions. SecPortal is the operating record for the case lifecycle slice, not the detection platform, the forensic investigation suite, the operational response controller, the legal counsel relationship, the communications partnership, the cyber insurance broker, or the law-enforcement liaison. The honest scope below reads against the 800-61 boundary so the platform commitment is unambiguous.

The incident management evidence (preparation, detection and analysis, containment- eradication-recovery, communications, evidence custody, post-incident review, exercising) reads against operational workflows that already exist as named use cases. The incident response operating workflow carries the live-incident handling discipline the case record reads against. The breach notification and regulator readiness workflow carries the parallel notification queue model the communications track operates against when a case crosses regulator-clock thresholds (SEC four-business-day clock, DORA four-hour clock, NIS2 24-hour clock, GDPR 72-hour clock, HIPAA 60-day individual notification clock, sector-specific clocks). The PSIRT product security incident response workflow carries the case-management discipline for product-vulnerability incidents that pair 800-61 with ISO/IEC 30111 and ISO/IEC 29147. The security incident evidence handover workflow carries the structured handover discipline between IR, forensic providers, counsel, and regulators that the evidence custody record reads against. The zero-day and emergency vulnerability response workflow carries the accelerated case discipline for actively exploited zero-day disclosures the IR team operates against.

For internal security teams operating NIST 800-61 as the IR reference, the internal security teams workspace bundles the platform with the engagement structure the response cadence reads against. For security operations leaders carrying the operational incident management posture into the management review, the security operations leaders workspace covers the per-cycle response readiness, the exercise programme, and the post-incident action ledger. For GRC and compliance teams reading the incident evidence against ISO 27001, SOC 2, NIS2, DORA, PCI DSS, HIPAA, and the SEC rule, the GRC and compliance teams workspace covers the policy hierarchy, the evidence pack, and the audit cadence the framework expects. For CISOs and security leaders carrying the programme-level reporting on the incident response posture and the post-incident accountability narrative, the CISOs and security leaders workspace covers the executive-layer reporting model that sits on top of the case operating record.

For deeper reading on the disciplines this framework reads against, the incident response plan guide covers the practical IR plan structure that operationalises the framework. The incident response tabletop exercise guide covers the exercising cadence the preparation phase commits to. The ransomware readiness programme guide covers the ransomware-specific operating model that runs the framework against the most common live-incident scenario in current threat reporting. The security incident postmortem and after-action review guide covers the structured post-incident review discipline the lessons-learned phase carries. The SEC cybersecurity incident materiality guide covers the disclosure-decision discipline US public companies operate alongside the broader 800-61 cycle. The enterprise incident response at scale guide covers the multi-team, multi-region, multi-regulator operating model larger programmes operate the framework against. The security engineering handoff latency research covers the cross-team handoff economics that the IR team experiences during containment-eradication-recovery when remediation work crosses team boundaries.