What is incident response in cybersecurity?

Incident response is everything an organisation does once an attack is detected: working out what is happening, containing the threat so it cannot spread, eradicating it, restoring operations and learning from what happened. It is carried out by a specialist team, a CERT or CSIRT, and it has to be prepared before an attack, not improvised during one.

This article is the starting point of our series on what incident response is and what it covers. For a step-by-step account of how it unfolds in practice, see How does incident response work?.

A precise definition

The NIS2 Directive offers a useful definition. It calls “incident handling” any actions and procedures aiming to prevent, detect, analyse and contain, or respond to and recover from, an incident (Article 6). An incident is defined as an event that compromises the availability, authenticity, integrity or confidentiality of data or of the services provided by network and information systems.

In practice, incident response tries to answer four questions, in this order:

1. What is going on? Type of attack, systems affected, severity.
2. How do we stop it? Isolate devices, cut access, lock compromised accounts.
3. How did the attacker get in, and are they still there? Investigation, hunting for persistence.
4. How do we restart safely? Clean-up, recovery, heightened monitoring.

To tell an incident apart from a mere security event, see What is a cybersecurity incident?. The main families of attack (ransomware, business email compromise, data leaks, denial of service and more) are described in Types of cybersecurity incidents.

The main phases

Reference frameworks all describe a similar cycle. In Revision 3 of its SP 800-61 publication (April 2025), NIST now ties incident response to the whole of cybersecurity risk management under its Cybersecurity Framework 2.0, from preparation through to recovery. On the ground, the same stages always appear:

Phase	Goal	Typical actions
Preparation	Be ready before the attack	Contract, contacts, escalation procedure, tested backups
Detection and triage	Confirm the incident and its severity	SOC alert analysis, first indicators
Containment	Stop it spreading	Network isolation of devices, account lockout
Eradication	Remove the attacker’s foothold	Remove persistence, apply patches
Recovery	Resume operations	Restore, monitored return to production
Lessons learned	Prevent a repeat	Report, improvement plan

Each step, and how they play out in a real case, is covered in our pillar on how incident response works and in What are the steps of incident response?.

Who carries out incident response?

Incident response is the core job of CERTs (Computer Emergency Response Teams) and CSIRTs (Computer Security Incident Response Teams). In practice both terms describe the same kind of team: the first is historical, the second is the one used in EU legislation. See What is a CERT in cybersecurity?.

The SOC plays a different but complementary role: it monitors continuously and detects. It is often the SOC that triggers incident response by handing the CERT a triaged alert. See CERT, CSIRT and SOC: what are the differences?.

In France, ANSSI qualifies security incident response providers (PRIS) against a requirements framework. The qualification is not mandatory for most businesses, but it is a useful benchmark, including outside France. See PRIS: France’s qualified incident response providers.

What an engagement covers

An incident response engagement usually includes technical investigation (logs, endpoints, mailboxes), steering containment, eradication and support with recovery, followed by a report. It may or may not include data restoration and system rebuilds, depending on the contract and on who runs the infrastructure day to day.

Two articles look at that scope in detail:

• What does incident response cover?
• Does incident response include data recovery?

For a business that relies on an MSP, the split is often: the CERT investigates and guides, the MSP carries out actions on the infrastructure and leads restoration. See Managed SOC and MSP: who does what?.

Incident response and crisis management: two levels

Incident response is technical. Crisis management is organisational: it deals with leadership decisions, internal and external communication, and relations with customers, authorities and insurers. Both run in parallel during a serious attack and must stay in constant contact. See Incident response vs crisis management.

Is it mandatory?

There is no general obligation to sign an incident response contract. But several laws deal with how incidents are handled and reported:

• NIS2: the directive provides that essential and important entities have incident handling in place (Article 21(2)(b)) and report significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month (Article 23). As of 10 September 2026, France had not yet adopted its transposition law, but the content of the directive is known. See Who does NIS2 apply to?.
• GDPR: after a personal data breach, Article 33 provides for notification to the supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals.

Meeting those deadlines without a prepared response capability is very hard, because the facts needed for each report come straight from the investigation. Details in Is incident response mandatory?. To find out exactly what applies to your organisation, talk to your legal adviser.

Preparing before an incident

The most expensive time to look for a provider is in the middle of an attack, when contracts, access and scope all have to be agreed under pressure. The organisations that cope best have prepared three things:

1. A named responder: a CERT that can be mobilised quickly, under a contract signed in advance. That is the idea behind an incident response retainer. See What is an incident response retainer?.
2. A contact list: provider, MSP, leadership, insurer, authorities. See Who to contact after a cyberattack.
3. Continuous detection: the earlier an attack is spotted, the shorter the response and the lighter the damage. See What happens when a managed SOC detects an attack?.

Habits that make response harder

Under pressure, some well-meant reactions get in the way of the investigation:

• Switching off or reimaging affected machines before analysis, which destroys traces of how the attacker got in.
• Restoring too quickly from a backup without knowing how long the attacker has been present, which can reintroduce the backdoor.
• Coordinating over a compromised mailbox, where the attacker can read every message about the response.
• Negotiating alone with a ransomware group, without advice or coordination with the insurer and authorities.

An experienced CERT helps avoid exactly these mistakes in the first hours.

How Cyna approaches incident response

At Cyna, the managed SOC comes with a CERT, a member of InterCERT France, that works with the SOC teams and can be mobilised quickly. Cyna’s incident response on-call team is available 24/7 from the Report an incident page.

Because the SOC and the CERT are part of the same offer, an alert triaged by the SOC can be passed to the CERT without bringing in another provider. Cyna works through its partner MSPs, who own the relationship with their clients. Cyna’s certifications and security documents are available on its Trust Center. For real cases handled, see Lessons learned from cyberattacks handled by Cyna’s SOC and CERT in 2025.

After the incident

Response does not end when systems restart. You need to confirm the attacker has gone, close the entry point, step up monitoring and produce a report that is useful for leadership, the insurer and, where relevant, the authorities. Those topics are covered in our series on how response unfolds, starting with How does incident response work? and How to prevent a second attack.

Talk to an expert

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

Want to prepare your incident response capability, or your clients’? If you already work with a Cyna partner, they are your first point of contact. Otherwise, get in touch.

Frequently asked questions

Is incident response only for large companies?

No. A small business hit by ransomware needs the same steps: contain, understand, clean up, restart. What differs is how it gets access to that capability, often through its MSP and a partner SOC.

How long does incident response take?

It depends on the scale of the attack: a few hours for a well-contained compromised account, several weeks for widespread ransomware. See How long does incident response take?.

Can you handle an incident in-house?

An internal team can handle simple incidents. For a wide-scale attack, forensic investigation and hunting for persistence call for scarce skills. See Incident response: in-house or external?.

Should you report a cyberattack to the police?

It is generally advisable. If you have cyber insurance, the steps it expects are set out in your policy: check them with your insurer or broker. Reporting does not hold up the technical response, which is best started immediately. See Who to contact after a cyberattack.