What are the steps of incident response?

Incident response follows seven practical steps: preparation, detection and triage, containment, investigation, eradication, recovery and lessons learned. These steps come from NIST SP 800-61, whose Revision 3, published in April 2025, now organises them under the six Functions of the NIST Cybersecurity Framework 2.0. In a real incident, several steps run at the same time.

This article looks at each step in turn. For the full picture, from first alert to final report, see our guide How does incident response work?.

What changed with NIST Revision 3

For more than a decade, the reference was NIST SP 800-61 Revision 2 (2012) and its four-phase lifecycle: preparation; detection and analysis; containment, eradication and recovery; post-incident activity.

Revision 3, finalised in April 2025, supersedes Revision 2. Rather than a standalone lifecycle, it embeds incident response in wider cybersecurity risk management, using the six CSF 2.0 Functions:

• Govern, Identify, Protect: preparation. Governance, asset knowledge, protective measures.
• Detect, Respond, Recover: the response itself. Detection, analysis, mitigation, communication and recovery.
• Improvement (a Category within Identify): lessons from each incident feed the next round of preparation.

The point is simple: incident response does not start when the alert fires. It is prepared continuously.

The seven steps in practice

Step	Goal	NIST Revision 2	CSF 2.0 Function
1. Preparation	Be ready before anything happens	Preparation	Govern, Identify, Protect
2. Detection and triage	Confirm the incident and its severity	Detection and analysis	Detect
3. Containment	Stop it spreading	Containment, eradication and recovery	Respond
4. Investigation	Understand the attack	Detection and analysis	Respond
5. Eradication	Remove the attacker and their access	Containment, eradication and recovery	Respond
6. Recovery	Restore operations safely	Containment, eradication and recovery	Recover
7. Lessons learned	Improve	Post-incident activity	Identify (Improvement)

1. Preparation

Up-to-date emergency contacts, an escalation procedure, tested backups, retained logs, an EDR in place and an agreement with a response team. This is what saves hours on the day. See What is an incident response retainer?.

2. Detection and triage

An alert is not yet an incident. The analyst rules out a false positive, then assesses scope and severity. Triage decides how many people are mobilised. See What happens when a managed SOC detects an attack?.

3. Containment

Compromised endpoints and servers are isolated, suspicious accounts disabled and abnormal outbound traffic blocked. Containment must be fast but deliberate: switching a machine off destroys evidence. See How do you contain a system without destroying evidence?.

4. Investigation

Analysts rebuild the timeline: entry point, accounts used, machines affected, data accessed or exfiltrated. Without investigation, you do not know what to eradicate.

5. Eradication

Removing the attacker’s tools, rogue accounts, scheduled tasks and persistence; fixing the initial weakness; resetting credentials. See How do you know the attacker is gone?.

6. Recovery

Bringing systems back gradually from clean builds and verified backups, under closer monitoring. See When can you restart production after an attack?.

7. Lessons learned

Incident report, root causes, corrective actions and updated procedures. This closes the loop and strengthens preparation.

What runs in parallel

Three workstreams continue throughout:

• Evidence preservation, needed for the investigation, the insurer and any police report.
• Regulatory reporting: for entities in scope of NIS2, Article 23 of the directive provides for an early warning within 24 hours, a notification within 72 hours and a final report within one month. For a personal data breach, Article 33 of the GDPR provides for notification to the supervisory authority within 72 hours. Your legal adviser can confirm what applies to your situation. See Is incident response mandatory?.
• Communication with management, staff, customers and partners.

How Cyna handles these steps

At Cyna, the 24/7 managed SOC, run from France by in-house teams, handles detection and triage. The CERT, a member of InterCERT France, works with the SOC teams and can be mobilised quickly for containment, investigation and eradication. The incident response on-call team is available 24/7 from the Report an incident page. The terms of the SOC service (scope, licences) are set out in the contract agreed with the partner MSP. The partner MSP remains the client’s point of contact and leads recovery on its side.

Talk to an expert

Want to check that your procedures cover every step, for your own organisation or for your clients? If you work with a Cyna partner MSP, they are your first point of contact. Otherwise, get in touch.

Under attack? Report an incident: Cyna’s on-call team is available 24/7.

Frequently asked questions

Is the NIST four-phase lifecycle still valid?

It remains a useful teaching model, but Revision 2 (2012) was superseded in April 2025 by Revision 3, which is built on the CSF 2.0 Functions. Both describe the same activities, organised differently.

Is there a European or French equivalent?

ANSSI, the French national cybersecurity agency, publishes the 'Cyberattacks and remediation' guides, which frame incident response as investigation, remediation and crisis management combined. They complement NIST well on decision-making and steering.

Can the lessons learned step be skipped?

It is the step most often forgotten, yet it is what prevents the same incident from happening again. NIST links it to the CSF 2.0 Improvement Category, which feeds the next round of preparation. See What does an incident report contain?.

Who triggers incident response?

Usually the SOC, when it escalates an alert to an incident, or a user who reports unusual behaviour. The decision to engage the CERT then sits with the client and its MSP, following the agreed escalation procedure.