Search every question across sub-FAQs

Start with monitoring data, an alert, a user or third-party report, or another observation. An event may be routine: NIST examples include a login attempt, installation of a software update, and an application's response to a transaction request. An adverse event has a negative consequence, but the cause may be a natural disaster, power failure, or cybersecurity attack. Rev. 3 focuses on adverse cybersecurity events.

Estimate the event's scope and impact, correlate information from relevant sources, add current threat and asset context, and apply the organization's defined incident criteria to known and assumed characteristics. Account for known false positives. The criteria should connect the NIST incident definition to the organization's systems, data, policies, risk, and any applicable legal definitions.

If the criteria are met, declare the incident and execute the incident response plan with relevant third parties as needed. Examples in Rev. 3 include a botnet making an internet-facing service unavailable, stolen administrative credentials putting hosted tenant data at risk, ransomware blocking systems while copying files, phishing-led account compromise and fraud, exploitation of a new appliance vulnerability, and compromised vendor software distributed to customers.

If evidence is incomplete, continue or escalate analysis under a named owner and state what fact is still needed. If the criteria are not met, document closure or continued monitoring, including any condition that would reopen triage. Do not use severity alone as the declaration threshold; severity and urgency are estimated after preliminary review verifies an incident.

A NIST incident declaration does not by itself decide whether a statutory data breach, reportable cyber incident, insurance event, contractual incident, or public-notification threshold has occurred. Apply each external definition and trigger separately with the responsible legal, privacy, compliance, contractual, or regulatory owner.

Keep enough evidence to show what was observed, what was decided, and why the team moved forward or stopped. That usually means the alert or log entry, the triage notes, the incident criteria that were applied, and the declaration rationale.

NIST SP 800-61 Rev. 3 says incident response policies should define events, cybersecurity incidents, investigations, and related terms. The record should also distinguish an incident declaration from later categorization, severity, priority, escalation, elevation, notification, and recovery decisions.

Record assumptions and known false positives as carefully as confirmed facts. If automation declares a confirmed incident, preserve the rule, tool result, relevant input, and routing outcome so a reviewer can understand why the plan started. If a human overrides or reverses a decision, retain both decisions and the new evidence.

Review criteria after missed detections, repeated false positives, changes to assets or services, new threat information, policy changes, exercises, or incidents. Rev. 3 does not set a review interval; the organization should define one and assign the policy owner.

Use incident coordination to align internal and external responders on current and planned actions. Use incident notification to inform affected customers, employees, partners, regulators, law enforcement, or others when the plan or an applicable requirement calls for it. Route public communication through approved media procedures, and use incident information sharing only with designated stakeholders under response plans and information-sharing agreements.

Prepare these paths before an incident. Procedures should say what must be reported, to whom, and at what times, including initial notices and regular updates. For major incidents, update senior leadership. For malicious insider activity, involve human resources as appropriate. During recovery, continue secure status reporting and coordinate with critical suppliers under contract.

Keep one communication log that labels each entry as incident coordination, incident notification, public communication, or incident information sharing. Record the audience, purpose, facts known and unknown, approved content, sender, approver, channel, timestamp, sensitivity, handling restriction, and the law, regulation, policy, contract, plan, or agreement supporting the decision.

Capture lessons from three sources named in ID.IM: evaluations such as self-assessments, third-party assessments, and independent audits; security tests and exercises, including work with suppliers and other relevant third parties; and actual operations, including incident response and recovery. Follow-up reports and lessons-learned meetings are useful, especially near the end of a major recovery, but Rev. 3's continuous-improvement model also supports changes while the incident is active.

For each lesson, separate the observation, analysis, and approved improvement. Record what happened, the supporting facts, root or contributing causes where they can be established, affected CSF outcome, risk and recurrence potential, selected action, owner, resources, dependencies, target date, and effectiveness test. A plausible observation may warrant investigation without yet proving a systemic cause.

Prioritize the improvement against other cybersecurity and enterprise risks. Decide whether to correct an immediate operating problem, change the incident-response program, update another cybersecurity activity, accept or defer the risk, or collect more evidence. For example, a missed indicator may lead to a detection change, while a failed supplier handoff may require a contract, contact path, procedure, and joint exercise rather than a technical control.

Make urgent changes during an active incident only through controlled decision and change processes so the team does not disrupt response or destroy evidence. Protect sensitive incident information when communicating the lesson, and give participants enough information to understand the change and their responsibilities.

At recovery closure, prepare an after-action report that records the incident, response and recovery actions, and lessons learned. The report is one input to ID.IM; it does not show that an improvement worked until the assigned change is implemented and tested.

Keep the observation, supporting incident facts, analysis, priority, approved improvement, owner, due date, implementation evidence, and effectiveness result together. Link the improvement to the affected CSF 2.0 outcome and incident record. If the action changes an incident response, business continuity, vulnerability management, or other operational plan, record the plan version, communication or training step, and any exercise used to verify it.

Close an improvement only when the record shows the approved acceptance condition. A completed ticket may prove implementation but not effectiveness. Use the defined test, measure, assessment, exercise result, or later operational evidence to decide whether the change worked and whether another action is needed.

Review open actions on the organization's chosen cadence and reassess them after new incidents, exercises, evaluations, supplier changes, major technology or process changes, or evidence that the control is ineffective. SP 800-61 Rev. 3 recommends periodic plan review and review when significant improvement is needed, but it does not set a universal interval.

Record investigation actions as they occur and safeguard those records because they can contain exploited-vulnerability details, breach information, or information about users. NIST examples of recording methods include a paper logbook, audio or video recordings, and automatic session monitoring and logging, where the incident-response plan and policy permit them. Limit access to authorized personnel.

Separately collect the incident data and metadata needed to establish the sequence, affected assets, magnitude, and root causes. Preserve integrity and provenance from the original source through export, analysis, transfer, and storage. Identify derived items so a reviewer does not mistake a transformed result, screenshot, or analyst note for the source record.

Rev. 3 says formal evidence gathering and chain-of-custody procedures might not be performed for every incident, but it still treats collected incident data as evidence. Decide the handling level from the investigation purpose, possible prosecution or litigation, policy, legal advice, and other applicable requirements. Most routine malware cases may not lead to prosecution, which is NIST's example of why one formal process does not fit every incident.

Apply the organization's evidence-preservation and retention rules. If litigation, prosecution, regulation, contract, insurance, a legal hold, or another authority may affect retention, have the responsible legal or records owner determine the case-specific requirement rather than inventing one from Rev. 3. Record conflicting retention or deletion duties and the approved resolution.

Plan for later access, not only storage. NIST says to consider the cost of retaining the data and the hardware and software needed to access it in the future. Preserve required keys, formats, tools, system versions, and explanatory metadata, or document why continued readability cannot be guaranteed.

The evidence register should identify what was collected, the source asset, collection time and method, collector, storage location, access restrictions, integrity check, provenance, and any known gap. Link each item to the incident analysis, recovery decision, notification assessment, after-action report, or improvement it supports.

Document the retention authority, review or disposition date, responsible owner, and any dependency needed for future access. A legal hold, chain-of-custody record, or special forensic method belongs in the register when another applicable procedure or authority requires it; Rev. 3 does not make those controls universal.

Keep investigation-action records and collected data linked but distinguishable. For an action record, capture who did what, when, under which authority, and with what result. For a collected item, capture source, method, integrity information, provenance, storage, access, and disposition. One record may refer to the other without replacing it.

At closure or disposition review, confirm that required incident documentation is complete, access remains restricted, holds and retention authorities are current, and future-access dependencies still work. Destruction or transfer should follow the approved records process and leave the evidence required by that process.

Start by identifying the instrument that creates the duty. Determine its covered organization, sector, geographic and customer locations, incident or breach category, jurisdiction, trigger, deadline, calculation rule, recipient, content, update requirements, exceptions, and submission route. Do not copy a headline deadline into the plan without its conditions and exclusions.

Assess each instrument separately. One incident may require internal status updates, a supplier or customer notice under contract, notification to affected people, a regulator filing, or contact with law enforcement, and each may use a different definition and starting fact. A NIST incident declaration can be relevant evidence without being the legal trigger.

Build the resulting clocks into the incident-response plan and notification procedure. Assign an assessment owner, an authorized reporter, an approval path, and backup coverage. Prepare recipient details, portal access, required templates, secure communication methods, and an out-of-hours path before an incident occurs.

Incident coordination covers operational communication among parties with response roles. Incident notification formally informs affected customers, employees, partners, regulators, or others. NIST separately identifies public communication and usually voluntary incident information sharing. Label these paths so a status update, press statement, or threat-information exchange is not mistaken for a required notice.

NIST recommends notifying affected third parties under regulatory, legal, and contractual requirements and contacting law enforcement or regulators using plan criteria, management approval, applicable law, and organizational procedures. Designated individuals should make those contacts. Rev. 3 does not decide that a report is required or authorize a particular disclosure.

When facts remain uncertain, record the uncertainty and apply the controlling instrument's rules for preliminary, phased, corrected, or final reports. Do not delay merely to complete the technical investigation unless the instrument permits it, and do not invent a preliminary-report duty that the instrument does not contain.

Keep a clock register that identifies the instrument and provision, covered actor and incident type, jurisdiction, trigger, calculation method, deadline, recipient, required content, submission route, approval authority, and update or final-report duties.

Link the register to the technical incident record without treating detection, triage, declaration, scope confirmation, or rule-specific awareness as interchangeable. The responsible legal, compliance, privacy, contractual, or regulatory owner should confirm any interpretation that depends on case-specific facts.

For every live clock, retain the trigger analysis, source facts, timestamps and time zone, calculation, owner, approvals, submitted content, transmission result, acknowledgment, corrections, and later reports. If the team concludes that no notice is required, retain the provision, facts, analysis, decision owner, and reassessment condition.

Exercise the clock register with technical responders, legal and privacy owners, communications staff, leadership, and relevant suppliers. Test recipient data, portal credentials, approval coverage, secure sharing, and the ability to assemble the required facts under uncertainty. Record and close any gap found.

Reassess a live decision when scope, affected people or systems, data impact, incident category, jurisdiction, customer location, provider facts, or a controlling rule changes. Periodic register review does not replace incident-specific reassessment.

Use severity as one documented input to incident management, not as a substitute for incident declaration or a complete risk assessment. Validate the report first. Estimate severity and urgency from the facts available, and mark assumptions or missing information that could change the result.

Use organization-defined factors consistently. Rev. 3 examples are asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization, and recoverability. Define each factor, its evidence, how factors combine, who decides, and when judgment may override the calculated result.

Categorize the incident separately by type, such as data breach, ransomware, account takeover, or denial of service. For prioritization, consider scope, likely impact, time-critical nature, and resource availability. Incidents should not be handled first-come, first-served when risk and resource limits require a different order.

Use the result to choose response priority and strategy, decide whether more resources or management involvement are needed, and apply recovery-initiation criteria. Escalation generally increases resources or response time frames; elevation usually involves higher management. Record either decision and its operational consequence.

Example: ransomware disrupting an essential service, affecting many assets, with uncertain persistence and no verified clean restoration source may warrant a higher response priority than a contained account compromise on a noncritical asset. This is an illustration, not a NIST severity level; the organization's approved factors and the actual evidence control the result.

Keep magnitude and severity distinct. Magnitude asks how broad the incident is and should be validated by looking for compromise indicators, persistence, and related activity on known and potential targets. A small confirmed scope can still be urgent, while a broad but contained incident may require a different strategy.

A severity label alone does not determine an external reporting duty, contractual notice, insurance classification, recovery target, or public statement. Apply those instruments independently and retain the cross-reference when severity evidence informs them.

Document the severity and urgency decision, the facts and assumptions used, the applicable criteria, the main factors, the decision owner, and the operational consequences. Show why the incident has its current rating and which new fact would require reassessment.

Track severity separately from incident category, response priority, escalation, elevation, recovery status, magnitude, and external notification classification. These decisions can influence one another, but Rev. 3 does not define them as a single scale.

For each factor, retain the source evidence and time assessed. Record conflicting signals, unavailable evidence, manual overrides, the approving authority, and the action that follows. A label without its rationale and consequence does not show that prioritization worked.

Track incident status with a current summary, relevant indicators of compromise, assigned actions, expected time frames, and next steps. Validate the status often enough to identify incidents that need more resources or a different response strategy; the organization should define the cadence for each priority.

Review the severity method after exercises, incidents, missed service targets, repeated overrides, material changes to assets or dependencies, and changes in risk appetite or external requirements. Keep the prior method and decision record when a later reassessment changes the rating.

Apply the plan's recovery-initiation criteria to what is known and assumed about the incident, including the disruption recovery itself may cause. Recovery can start during or after response, so containment, eradication, investigation, and restoration may overlap. Record the decision, authorization, dependencies, residual uncertainty, and any reason to delay or change a planned action.

Select actions using the incident-response plan, available resources, mission priorities, timeliness, precision, and reliability. NIST examples include restoring from clean backups, rebuilding systems, replacing compromised files with clean copies, installing patches, changing passwords, and tightening security controls. If a sophisticated threat actor's full tactics remain unknown, replacing compromised hardware may be necessary; treat that as a case-specific option, not a default.

Choose the scope deliberately. Restoring only affected files may be faster and more precise, while rebuilding a broader set of systems may provide more confidence when magnitude or persistence remains uncertain. Reassess the plan when incident facts, business needs, dependencies, or available resources change and record why the selected action changed.

Before using restoration assets, check them for indicators of compromise, corruption, and other integrity problems. Before production use, check restored assets for compromise, remediate root causes, and verify that each restoration is correct and adequate. A successful boot or completed backup job is not enough if the service is still unsafe, incomplete, or unable to meet its approved operating need.

Validate that essential services return in the appropriate order, monitor restored systems to test whether restoration is adequate, and have system owners confirm successful restoration and normal operation. Coordinate progress with designated internal and external stakeholders, follow supplier information-sharing clauses, and use approved methods for public updates.

Declare recovery complete only when the plan's criteria are met. Complete the incident documentation and after-action report, but keep longer-running remediation or improvement work open under its own owner and acceptance condition. Applicable contracts, continuity plans, legal duties, or sector requirements may impose recovery targets or evidence beyond Rev. 3.

The recovery record should show the initiation decision, what was restored, why actions were prioritized in that order, who authorized and performed them, how restoration assets and restored systems were checked, what root causes were remediated, how restored systems were monitored, and who confirmed operational readiness. Record changes to the plan as needs, resources, or incident facts change.

For each restored service, retain the dependency and priority decision, selected recovery source, integrity result, change or rebuild record, compromise checks, functional test, monitoring result, owner acceptance, and time returned to service. Note uncertainty and residual risk instead of presenting partial restoration as complete.

For recovery closure, retain the criteria applied, approving authority, unresolved work, status communications, final operational confirmation, completed incident documentation, and links to the after-action report and ID.IM actions. A later recurrence or failed acceptance condition should create a new decision record or reopen recovery under the organization's procedure.

Start with incident leadership and handling. Leadership oversees the capability, funds it, and may approve high-impact actions such as shutting down or rebuilding a critical service. Incident handlers verify incidents, collect and analyze data and evidence, prioritize work, limit damage, find root causes, and help restore operations.

Add the specialists and owners the incident requires. Technology professionals investigate and restore their systems; legal advises on applicable law, privacy, contracts, and legal consequences; public affairs manages approved media communication; human resources supports personnel matters; facilities teams support physical incidents and access; and asset owners set business and recovery priorities and confirm status.

Choose a staffing model that fits the organization. Incident handlers may be on staff, under contract, or available from a parent organization, specialist provider, business partner, or law-enforcement agency. An organization may combine these approaches. If several internal teams cover different regions or technology segments, coordinate them as one entity so procedures, training, and incident information remain consistent.

When a provider performs part of detection, response, or recovery, document the shared responsibility model in the contract. Include information flows, coordination, authority to act, restrictions on sharing or operational decisions, access protections, and the responsibilities that remain with the organization. For example, state whether a cloud provider or internet service provider may automatically isolate a service, whether an MSSP may share sanitized indicators with other customers, and who preserves provider-side logs.

Provider access creates its own risk. NIST notes that service providers may have privileged system access and sensitive data, so plans and contracts should address provider compromise, malicious insiders, confidentiality, and loss of access when the relationship ends. A provider's capability to correlate activity across customers can improve detection, but it does not replace organization-side ownership.