An incident rarely begins with certainty. It may emerge as an alert, a user report, unusual behavior, or an operational failure. The initial challenge is making useful decisions without erasing the context that will help explain what happened.
This article organizes the first steps — from triage to containment — and explains why the order of actions matters as much as the actions themselves.
First: event, adverse event, and incident
Three words that seem synonymous but are not. NIST distinguishes them precisely, preventing noise from being treated as a crisis:
- Event: any observable occurrence in a system. A login attempt is an event.
- Adverse event: an event with a negative consequence, from any cause — including a power failure or operational error.
- Incident: an occurrence that actually or imminently compromises the integrity, confidentiality, or availability of information or a system; or violates security policies.
The practical consequence: an alert is an event until analysis elevates it to an incident. Declaring an incident too early mobilizes people unnecessarily; declaring it too late costs containment time. Triage exists precisely to make this decision based on evidence.
The model has changed: from a four-phase cycle to six functions
Anyone who studied incident response probably learned the four-phase cycle from NIST’s previous revision: preparation → detection and analysis → containment, eradication, and recovery → post-incident activity.
Revision 3 of SP 800-61, published in April 2025, moved away from this model. The document explains why: when the cycle was created, incidents were relatively rare, narrow in scope, and resolved within one or two days — making it realistic to treat response as a separate set of activities performed by a separate team. Today incidents are frequent, recovery takes weeks or months, and lessons learned must circulate as they emerge, rather than after recovery ends.
The current model organizes response around CSF 2.0’s six Functions:
| Function | Role in response |
|---|---|
| Govern | Defines roles, policies, and decision criteria — before the incident |
| Identify | Knows assets, risks, and what is critical |
| Protect | Reduces the likelihood and impact of incidents |
| Detect | Discovers adverse activity |
| Respond | Contains, eradicates, communicates, and manages |
| Recover | Restores and validates the return to operations |
Govern, Identify, and Protect are ongoing and involve the whole organization; Detect, Respond, and Recover come into play during an incident. The underlying change is conceptual: incident response has become part of risk management, integrated into operations, rather than an isolated process.
In practice, the guidance below remains valid under any model. If your organization uses the four-phase cycle, it is not wrong — NIST itself says each organization should use the model that best serves its needs.
First, record what you know
Note the time with time zone, alert source, affected asset, people contacted, and actions already taken. Preserve relevant identifiers: account, host, source address, session, and related events. This timeline prevents the investigation from depending on memory or scattered chat messages.
A useful record separates three columns:
| Time (UTC) | Observation | Classification |
|---|---|---|
| 14:02 | Login by j.silva from an unusual ASN | Fact |
| 14:03 | MFA approved on the first attempt | Fact |
| 14:05 | Account possibly compromised | Hypothesis |
| 14:07 | Check whether a new MFA method was registered | Next test |
“The account may be compromised” differs from “the account was used by a third party”. Separating fact, interpretation, and next test improves communication with risk decision makers — and prevents a hypothesis from becoming a conclusion through repetition.
Define impact and urgency
Ask which systems and data may be involved, whether activity is ongoing, and what waiting would mean. Priority should not depend on alert volume: a rare occurrence on a critical system may require action before a noisy sequence in a low-risk environment.
Criteria supporting the decision:
- asset criticality — what stops if it stops;
- account privilege — what it can reach beyond itself;
- data exposure — nature and volume;
- persistence — is there evidence of maintained access?
- propagation — can it reach other systems?
If these criteria do not exist in the organization, record the gap so the process can improve later — and decide with what you have, documenting the reasoning.
Contain without destroying the investigation
Sometimes it is necessary to revoke a session, disable an account, isolate a machine, or block an indicator. The action must reduce immediate risk and be proportionate to confidence in the evidence.
Order matters. On a suspicious host, collecting before shutdown preserves what exists only in memory:
- Isolate the network before modifying the host — this interrupts access without erasing state.
- Preserve volatile memory, if the capability exists, before any restart.
- Collect the logs supporting the decision, including those that may rotate soon.
- Then perform more invasive containment.
Shutting down a machine erases running processes, open connections, and often the evidence explaining how access occurred. Restarting “to clean things up” is the most common way to destroy an investigation with good intentions.
Avoid broad reflexive actions. When risk demands rapid containment and there is no time to collect, document who decided, why, and what was not collected — that note is more valuable than it seems during the later review.
Coordinate communication and recovery
Define who updates the parties involved, how often, and through which channel. If compromise of the corporate environment is suspected, consider a channel outside it: discussing response in a system the attacker may be reading is a costly mistake.
Clear communication does not require unnecessary technical details. A format that works: current impact · action underway · pending decision · next update time. The last item reduces an incident’s biggest source of noise: people asking whether there is news.
After containment, address the cause that enabled the incident and confirm that recovery works. A fix is complete only when you can verify that the behavior does not recur and detection controls remain useful.
Close the loop
Produce a short review: timeline, impact, evidence, decisions, improvements, and owners. The aim is not to assign blame; it is to make the organization better at recognizing and responding to the next relevant signal.
Two questions offer more than a long report:
- What made us notice? If it was a user rather than detection, there is a telemetry gap to address.
- What delayed us? Missing access, contacts, logs, or criteria — each has a different fix.
Under the current model, these lessons should be shared as soon as they emerge, not saved for a final report weeks later.
Next step
You do not need an incident to practice this. Choose a recent alert from your environment — even a false positive — and write a three-column timeline for it. In minutes, the exercise reveals missing log fields, people you did not know to contact, and priority criteria that do not exist in writing.
In real situations, organizational procedures, legal obligations, and designated owners must take precedence. This guide supports preparation and reasoning rather than replacing an approved response plan. Practice only in environments you own or with explicit authorization.
