How does incident response work?

Incident response works in seven stages: the alert, triage of the incident, containment to stop it spreading, investigation to understand what happened, eradication of the attacker, recovery of systems, then the report and lessons learned. The first hours are decisive, and the work carries on after systems restart.

This article walks through a real-world response. For the definition and scope of incident response, see What is incident response?. Each stage has its own detailed article, linked as we go.

The process at a glance

Stage	Goal	Who leads
1. Alert	Know something is happening	SOC, user, MSP
2. Triage	Confirm the incident, assess severity	SOC, CERT
3. Containment	Stop the spread without destroying evidence	CERT, MSP
4. Investigation	Understand entry point, scope, data affected	CERT
5. Eradication	Remove all attacker access and tools	CERT, MSP
6. Recovery	Bring clean systems back into service	MSP or internal IT, guided by the CERT
7. Closure	Report, lessons learned, improvement plan	CERT, management, MSP

Alongside these technical stages, two threads run from start to finish: crisis management (decisions, communication, business continuity) and legal duties (police report, notifications). For the difference between the two, see Incident response vs crisis management.

A reference framework: NIST SP 800-61

No single method is mandatory, but NIST SP 800-61 is the most widely cited reference. Revision 3, published in April 2025, supersedes Revision 2 and places incident response within overall cybersecurity risk management, aligning it with the six functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. The classic lifecycle (preparation, detection and analysis, containment, eradication and recovery, post-incident activity) is still the model most teams use in the field. For each phase in detail, see What are the steps of incident response?.

Stage 1: the alert

It all starts with a signal. At best, the SOC spots abnormal behaviour: an unusual sign-in, suspicious execution on an endpoint, antivirus being disabled, a large data transfer. In other cases, a user finds their files encrypted or a customer receives a fraudulent email.

What matters is that the alert quickly reaches someone who can act, day or night. That is the whole point of 24/7 monitoring and a clear escalation path between the SOC, the MSP and the client. See What happens when a managed SOC detects an attack?.

Stage 2: triage

Not every alert is an incident. Analysts first check whether it is a false positive, a harmless event or a real compromise. If the incident is confirmed, they assess its severity: how many machines are affected, whether privileged accounts are compromised, whether sensitive data is exposed, the impact on the business.

Triage decides what comes next: routine handling by the SOC, or bringing in the CERT and setting up a crisis team. For the kinds of incidents you may face, see What are the different types of cybersecurity incidents?.

Stage 3: containment

The goal is to stop the attacker going further: isolate compromised endpoints and servers from the network, disable stolen accounts, shut exploited remote access, protect backups. An EDR can often isolate a machine remotely in seconds while keeping it available for investigation.

The classic trap is acting too bluntly. Switching a machine off wipes its memory, which sometimes holds the most useful traces. French government guidance therefore recommends disconnecting affected machines from the network without switching them off, unless encryption is still running. See How to contain an attack without destroying evidence.

These first hours carry the heaviest decisions. For the list of actions, see What to do in the first hours of a cyberattack.

Stage 4: investigation

Once the attack is contained, the team works out what happened. CERT analysts rebuild the timeline from logs, EDR telemetry and system copies: how the attacker got in, since when, which accounts they used, which machines they reached, which data they may have taken.

The investigation serves three purposes. It guides eradication, because you can only remove what you have found. It feeds notifications: the data protection authority wants to know which personal data is involved, and NIS2 authorities expect a description of the incident. Finally, it forms the basis of the final report.

Stage 5: eradication

Eradication means removing everything the attacker left behind: malware, backdoors, accounts they created, scheduled tasks, mail forwarding rules. It also means closing the door they came through: patching the exploited vulnerability, hardening remote access, resetting passwords, especially for privileged accounts.

Incomplete eradication is the leading cause of reinfection. The question “is the attacker really gone?” needs an evidence-based answer before restart. See How do you know the attacker is gone?.

Stage 6: recovery

Then comes the return to service. Systems are rebuilt from clean images, data is restored from backups that predate the compromise, and applications are checked with users. Restart happens in stages, critical services first, under heightened monitoring.

When to restart is a management decision, informed by the response team. See When can production restart after a cyberattack? and Does incident response include data recovery?.

Stage 7: report and lessons learned

The response closes with an incident report: timeline, root cause, scope, actions taken, data affected, recommendations. Management, the insurer, the authorities and, where relevant, police investigators all use it. See What does an incident report contain?.

The lessons-learned review turns the incident into an action plan: fixes, hardening, stronger monitoring, training, updated procedures. The following weeks are also a risky period, because an attacker who knows the environment may try to come back. See What happens after incident response? and How to prevent a second attack.

In parallel: the legal clock

While the technical team works, several deadlines run:

• GDPR: where personal data is affected, Article 33 provides for notification to the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk, and Article 34 for informing the people concerned if the risk is high.
• NIS2: for entities in scope, Article 23 provides for an early warning within 24 hours, a notification within 72 hours and a final report within one month, to the CSIRT or competent authority. As of 21 September 2026, France had not yet adopted its transposition law.
• Insurance: in France, Article L. 12-10-1 of the Insurance Code, introduced by the LOPMI law, links compensation for cyberattack losses to filing a police complaint, with a 72-hour window. The conditions that apply to your situation depend on your country and policy, and are best checked with your insurer and legal adviser.

According to Cybermalveillance.gouv.fr, the French government’s victim assistance service, it is preferable to file the police report before machines are rebuilt, to preserve evidence. See Who should you contact after a cyberattack?.

How long does incident response take?

There is no standard duration. A mailbox compromise detected early can be dealt with quickly; ransomware that has spread across the whole estate usually takes far longer, especially the recovery stage. Speed of detection, quality of backups and preparation all weigh heavily. See How long does incident response take?.

Who does what: CERT, MSP, management

Incident response involves several players: CERT analysts and experts, the SOC team, the MSP or internal IT, management and, depending on the case, legal, communications and the insurer. Coordination between them matters as much as technical skill. See Who is in an incident response team?.

Can you handle it all in-house? An IT team knows the environment, but rarely has the attack experience, investigation tools and availability a crisis demands. See Incident response: in-house or external?. And if no contract was signed before the attack, see Can you hire an incident response provider without a contract?.

What preparation changes

Much of incident response is decided before the incident. Organisations that come through best tend to share a few things:

• continuous monitoring, to detect early;
• tools already deployed (EDR, log collection), to investigate without delay;
• a named response team and a contract already in place;
• tested offline backups;
• a contact list and roles written down in advance.

How Cyna does it

At Cyna, the managed SOC monitors environments 24/7 from France, with in-house teams. Cyna’s CERT, a member of InterCERT France, works with the SOC teams and can be mobilised quickly. The incident response on-call team is available 24/7 from the Report an incident page. Cyna works through its partner MSPs, who own the relationship with their clients and are involved throughout. See Managed SOC and MSP: who does what?.

Talk to an expert

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

To prepare your organisation or your clients’, your Cyna partner MSP is your first point of contact. Otherwise, get in touch.

Frequently asked questions

Who makes decisions during incident response?

The affected organisation's management keeps the final say on choices that affect the business (shutting a service down, restarting, communicating). The response team recommends and carries out the technical actions, working with the MSP. See Who is in an incident response team?.

Do we have to stop all business activity during the response?

Not always. Containment aims to isolate what is compromised while keeping what can safely continue. How much stops depends on the scale of the attack and the fallback options available.

Is incident response done remotely or on site?

Usually remotely first, using tools already in place (EDR, logs, monitoring console), which saves time. On-site work can be added, for example for isolated machines or disk copies.

Is there a reference framework for incident response?

Yes. The most widely cited is NIST SP 800-61, whose Revision 3 was published in April 2025 and aligns with the NIST Cybersecurity Framework 2.0. See What are the steps of incident response?.