What Is Cyber Incident Response? Stages, Roles, Frameworks

An analyst can often close out a single alert quickly. Establishing what else the attacker touched is slower, sometimes days or weeks. The distance between a verdict on one alert and a defensible statement of scope is where cyber incident response programs often lose time. The work after detection still runs on whoever is awake, whichever logs survived retention, and how fast someone can get a decision out of legal.

TL;DR:

• Responses tend to stall between spotting malicious activity and establishing a defensible scope, especially when the logs needed to trace the attacker are scattered or already deleted.
• NIST SP 800-61 Rev. 3 reframes incident response around the CSF 2.0 functions, and SANS now teaches a looping model. Phase-based runbooks still work, but their references and governance mapping need a review.
• Identity is a recurring containment gap: a password reset or host isolation can leave refresh tokens, OAuth grants and attacker-registered MFA devices in place.
• MDR and specialist IR cover different work: MDR handles investigation and containment within an agreed scope that varies by provider, while forensic breach response comes from specialist IR, whether contracted separately, bundled or delivered through a partner.

What Cyber Incident Response Is

Cyber incident response is the coordinated work of confirming that an adverse event is an incident, scoping it, removing the attacker's access, restoring affected systems, and feeding the lessons back into controls. NIST SP 800-61 Rev. 3 defines an incident as an occurrence that actually or imminently jeopardizes information or an information system without lawful authority, or that violates or imminently threatens to violate law, security policies, security procedures or acceptable use policies.

Rev. 3 places incident response itself across Detect, Respond and Recover. The span starts with analyzing possible attacks before anyone has confirmed an incident and ends with restoration under Incident Recovery Plan Execution (RC.RP). Govern, Identify and Protect sit underneath as broader risk management activities that also support response.

The Lifecycle, Stage by Stage

The stages below follow the order responders usually work in. Real incidents loop back: attackers return after containment, scope turns out larger than first estimated, and eradication misses a persistence mechanism.

1. Preparation

Preparation is the policy, logging, patching and role-definition work done before any alert fires. Patch latency is a frequent weak spot: exploitation of vulnerabilities was the most common initial access vector in the 2026 Verizon DBIR, at 31% of breaches, overtaking credential abuse. Security leadership owns preparation, with IT operations carrying the patching.

2. Detection and Triage

Triage struggles with volume and with the quality of the detections feeding it. In SANS's 2025 detection engineering survey, 64% of respondents cited high false-positive rates in vendor-provided detections as a top challenge. Analysts on the alert queue own triage, and detection engineers own the content that generates the alerts.

Triage uses severity, alert metadata and basic enrichment to decide what gets investigated and by whom, while the verdict on whether an alert is real comes from investigation. Triage exists because full investigation is expensive. Once every alert can be investigated, the filtering step becomes largely unnecessary, though confirmed incidents still have to be prioritized.

3. Investigation and Scoping

Scoping is slow because the evidence is spread across endpoint, identity, cloud and SaaS records, and anything that has aged out of retention can leave the initial access vector permanently unconfirmed.

Incident handlers and DFIR specialists own this stage, and threat hunters are often pulled in to sweep for lateral movement and persistence. Their output is a scope statement: which systems, identities and data the attacker touched, and how they got in. Incident triage, a separate step from alert triage, turns the confirmed findings into severity, impact and a containment plan, and responders revisit it as the scope grows.

4. Containment

Containment is weakest on identity. A password reset alone can leave some existing refresh tokens and sessions valid, so Microsoft's emergency guidance treats disabling the account, revoking refresh tokens and disabling the user's devices as separate steps. Sessions issued by individual applications may need revoking in those applications as well.

Attackers exploit that gap. Scattered Spider registers its own MFA tokens and deploys remote monitoring and management tools after compromising an account, according to a 2025 joint advisory from the FBI, CISA and partner agencies. Isolating one laptop may cut remote access to that host, but the attacker's MFA methods stay in place. The response team executes containment with IT operations, and Rev. 3 notes that leadership may hold decision authority on high-impact actions such as shutting down or rebuilding critical services.

5. Eradication and Recovery

Moving fast at this stage can destroy evidence responders still need. Reimaging a host before imaging the original drive removes the forensic baseline, and clearing logs or patching before documenting can obscure initial access and tip off a live attacker. CISA's federal response playbooks, published in November 2021, set a precondition for eradication. Responders should first "ensure that all means of persistent access into the network have been accounted for, that the adversary activity is sufficiently contained, and that all evidence has been collected."

IT and infrastructure teams, cloud engineers and asset owners own eradication and rebuild.

6. Post-Incident Review

Post-incident reviews fail when blame discourages people from raising issues and when action items go untracked. Findings without owners and due dates leave a postmortem as a record of what happened, with nothing changed. The incident commander typically runs the review and tracks the resulting changes. Rev. 3 also says lessons should often be shared as soon as they are identified, while recovery is still under way.

Frameworks in Brief: NIST and SANS

NIST SP 800-61 Rev. 3, released April 3, 2025, is the current edition, and Rev. 2 was withdrawn the same day. Rev. 3 replaces the four-phase lifecycle with a CSF 2.0 Community Profile across Govern, Identify, Protect, Detect, Respond and Recover, and leaves organizations free to use whichever lifecycle model suits them. Rev. 3 argues that incidents now occur frequently, recovery often takes weeks or months, and incident response belongs inside risk management across the organization.

SANS taught a six-step process for years, usually called PICERL: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. In September 2026 SANS published its successor, the Dynamic Approach to Incident Response (DAIR), which treats scoping, containment, eradication and recovery as a loop responders re-enter as new evidence appears. Runbooks written against the older phases still work operationally, but references to Rev. 2 and their governance mapping need updating. A common pattern pairs NIST as the governance reference with a SANS-style runbook for day-to-day execution.

Plans, Playbooks and Templates

A plan's main job is to settle authority before the incident: who declares an incident, who can contain, and who escalates. NIST no longer tries to capture procedural detail in one document, because IR details change too often and vary too much to maintain in a single static publication.

A company runbook has the same problem: version the plan, review it on a schedule even when nothing has happened, and treat each incident as a test of it. A working incident response plan also sets up out-of-band communications and maps who does what across managed and retained vendors.

Why the Playbook Changes for Cloud, SaaS and Identity Incidents

In these incidents the evidence is time-boxed, the workloads are ephemeral, and containment usually targets credentials, which changes every stage. Identity log retention often depends on license level: Microsoft Entra keeps sign-in and audit logs for seven days on the Free edition and 30 days on P1 and P2, and older records are gone unless they were exported or kept through a longer retention option. Containers and instances can terminate before responders collect from them, so cloud IR procedures should capture disk and memory snapshots automatically where possible.

Scoping follows the API trail. Responders may need to query cloud audit records for every call made with compromised temporary credentials, and that analysis takes time. In SaaS incidents involving abused OAuth tokens, responders review connected third-party integrations before investigating downstream systems. Cloud incidents therefore need forensic logging and identity-focused containment planned in advance.

Who Runs the Response: In-House, MDR or IR Retainer

Buyers often treat MDR and an IR retainer as interchangeable. MDR response covers containment and remediation inside the provider's own investigations, and its scope varies by provider. A retainer buys forensic-grade breach response from an IR firm and can reduce procurement delays during a crisis. Some MDR providers bundle IR or partner with an IR firm, and the terms differ enough that buyers should confirm scope, response authority and evidence handling in advance.

Cyber insurance can narrow the choice further. Policies such as Coalition's cover breach response costs only with the insurer's prior written consent and pre-approve forensic and legal fees from panel providers.

In-house response works when the team has 24/7 staffing, its own DFIR depth and tested authority to contain. In SANS's 2023 incident response survey, 59% of respondents kept IR fully in-house. A frequent structural failure is that detection lives in the SOC while response sits with IT operations or behind an external phone call, with different tooling, managers and KPIs on each side.

Metrics That Show Whether It Is Working

MTTR and MTTD are standard measures of security operations, and both can mislead when start points, end points or closure criteria shift, for example when containment is declared early or one incident is split into several. FIRST's metrics guidance favors medians over means for task timing metrics and suggests pairing them with percentiles, because a few long incidents distort an average. Give acknowledgment its own clock, and pair speed measures with reopened-incident rate, so a fast MTTR cannot hide a containment that did not hold.

How to Choose a Cyber Incident Response Model

The right mix depends on staffing, insurance and regulatory exposure, where the attack surface sits, and how you measure results:

1. If you have a 24/7 team and your own detection engineering, keep investigation and containment in-house and pre-contract a retainer for the forensics and notification work your team should not start from scratch under a regulatory clock. Where privilege matters, have counsel engage it per incident.
2. If your security team is one to three people with no 24/7 coverage, buy investigation and containment as a managed service and confirm where forensic IR comes from. An MDR contract that does not name who executes containment leaves the 2 a.m. handoff on your team.
3. If you carry cyber insurance, confirm panel requirements and written-consent conditions before retaining a responder.
4. If NIS2, DORA or SEC disclosure rules apply, settle reporting triggers and owners with counsel ahead of time.
5. If most of your attack surface is identity and SaaS, choose a responder whose containment actions include revoking sessions, tokens and OAuth grants in addition to isolating endpoints.
6. If your MTTR stops at first containment, add reopened-incident rate ahead of any provider change; without it you cannot tell whether the new model worked.

Whatever the mix, settle in advance which side owns containment. Daylight's AI-native MDR keeps containment with the team that ran the investigation.

Frequently Asked Questions About Cyber Incident Response

When Does the Regulatory Clock Start, and Can Scoping Finish First?

The clocks start at awareness or at the materiality determination, so reporting is often due before scoping finishes. Under the SEC's 2023 disclosure rule, a domestic registrant files Form 8-K Item 1.05 within four business days of determining that an incident is material, and must make that determination without unreasonable delay after discovery.

For personal data breaches, GDPR Article 33 expects notification without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to put individuals at risk, and it lets information arrive in phases. The NIS2 directive requires an early warning within 24 hours and an incident notification within 72 hours of becoming aware of a significant incident, as transposed into national law.

Materiality can also change mid-investigation: Trio-Tech judged a March 11, 2026 ransomware incident at a Singapore subsidiary not material, then concluded after data was disclosed on March 18 that it may be material.

How Long Does Cyber Incident Response Take?

It depends on scope and recovery needs, and much of the elapsed time passes before anyone notices the breach. The 2026 IBM breach study puts the mean time to identify and contain a breach at 247 days, a period that includes the time before discovery, and at 209 days when organizations' own IT or security teams did the identifying and containing.

Who Should Hire the Forensics Firm?

Usually breach counsel, under an engagement written for the specific incident, though putting counsel's name on the contract is not enough on its own. In the McMenamins and Samsung breach cases in 2023 and 2024, courts ordered forensic material produced because the work served a business purpose and was shared widely inside the company. Keeping the report's scope tied to legal advice and limiting who receives it carry as much weight as who signs, and the law varies by jurisdiction.

How Much Log Retention Does Incident Response Actually Need?

Enough to reach back past the attacker's dwell time, which default settings often don't. Across Mandiant's investigations in M-Trends 2026, the global median dwell time was 14 days, and espionage intrusions ran to a median of 122 days. AWS CloudTrail event history keeps 90 days of management events and nothing on data access. Without a configured trail or event data store capturing data events, nothing records what the attacker read or changed.

Is MTTR Still a Meaningful Metric Once Triage Is Automated?

Only if you baseline first and keep the definition fixed. Record MTTR, MTTD and false-positive rates before any AI deployment. One practitioner on Gartner Peer Community reported that tools advertised at 60 to 70% alert reduction delivered closer to 10 to 15% in testing; it is one anecdote, but only a baseline would expose a gap like that.