NIS2 and MSSPs: Who Must Notify CSIRT When Your SOC Detects a Client Incident?

Your SOC analyst flags an event at 02:17. A staging server inside a client’s network is communicating with a known command-and-control address. Within minutes, lateral movement confirms: this is not a false positive. The client is a mid-sized energy supplier and a NIS2 essential entity.

The first operational question is containment. The first compliance question is different: who calls CSIRT?

The answer is not the MSSP. Under Article 23 of Directive (EU) 2022/2555, the notification obligation sits with “essential and important entities” themselves — the regulated organisations whose services NIS2 is designed to protect. When an MSSP’s SOC discovers a significant incident in a client’s infrastructure, the obligation to notify the national CSIRT or competent authority belongs to that client entity. The reporting obligation cannot be delegated to a managed security service provider; the entity itself is responsible for timely reporting. [5]

What belongs to the MSSP is the contractual obligation to notify the client fast enough that the client can act on its regulatory deadline. The gap between SOC detection and client awareness determines whether the client’s 24-hour early warning window stays intact or starts running out before the client knows anything happened.

Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

The general Article 23 notification timeline — 24-hour early warning, 72-hour detailed notification, one-month final report — is examined in our Article 23 incident notification guide. This article focuses on the specific obligations that arise when an MSSP SOC is the detection source: the obligation cascade, the clock trigger, the dual-entity scenario, and the contractual language required under Article 21(2)(d).

MSSP, SOC Operator, and Client — Mapping the Three-Party Relationship

Before tracing the notification obligation, it helps to establish precisely who the parties are under NIS2 and what status each holds.

The client entity is the NIS2-regulated organisation — the essential or important entity whose services NIS2 protects. Its designation is based on sector (Annexes I or II of Directive 2022/2555) and size thresholds: typically essential if 250 or more employees or €50 million or more annual turnover, important if between 50 and 249 employees or €10 million to €50 million turnover. When a significant incident affects its networks or services, this entity carries the Article 23 notification obligation to its designated CSIRT or competent authority.

The managed security service provider (MSSP) is defined at Article 6(40) of Directive 2022/2555 as a managed service provider — itself defined at Article 6(39) as an entity providing services “via assistance or active administration” — that “carries out or provides assistance for activities relating to cybersecurity risk management.” [2] In practice, the MSSP runs the SOC, monitors client environments, and responds to security events, often detecting significant incidents before the client’s own team has been alerted.

The SOC operator is the MSSP’s front-line detection function. It is not a separate legal entity under NIS2 and carries no independent Article 23 obligation; its obligations derive from the MSSP’s contractual relationship with each client.

The MSSP itself may also be a NIS2-regulated entity. Under Annex I of Directive 2022/2555, “ICT service management (business-to-business)” is a covered sector, which includes managed service providers and managed security service providers that meet the applicable size thresholds. An MSSP with 50 or more employees or €10 million or more annual turnover falls within NIS2 scope as an important entity; at 250 employees or €50 million turnover it qualifies as essential. [7] This dual status — regulated entity in its own right while simultaneously serving regulated clients — is the source of the parallel-obligation scenario examined in Section 4.

As we detail in our guide to MSP and MSSP obligations under NIS2, that status carries non-delegable Article 21 security requirements that cannot be contracted out to clients or sub-processors. The notification chain flows through both relationships simultaneously, but the chains are legally separate.

Party	NIS2 status	Art.23 notification obligation
Client entity (NIS2-regulated)	Essential or important entity	Notifies own CSIRT for significant incidents affecting own services
MSSP (Annex I threshold met)	Essential or important entity for own managed service	Notifies own CSIRT for significant incidents affecting own managed service — legally separate from client’s obligation
MSSP (below NIS2 thresholds)	Out of NIS2 scope as regulated entity	No direct Art.23 obligation; contractual duty to notify client only
SOC operator (under MSSP contract)	Not a separate legal entity under NIS2	No independent Art.23 obligation

Article 23(1): The Notification Obligation Belongs to the Client Entity

Article 23(1) of Directive 2022/2555 is precise about who files the notification:

“Each Member State shall ensure that essential and important entities notify, without undue delay, its CSIRT or, where applicable, its competent authority.” [1]

The subject of the obligation is the essential or important entity — the client. There is no provision in Article 23, or anywhere else in the Directive, that permits a regulated entity to discharge its notification duty by having its MSSP file on its behalf. The reporting obligation cannot be delegated to a managed security service provider; the entity itself is responsible for timely reporting. [5]

The MSSP can assist operationally — preparing the technical data, drafting the incident description, coordinating with the client’s compliance team. But the client entity is the notifying party and remains the liable party under Article 34(4) of the Directive, which sets fines of up to €10 million or 2% of global annual turnover for essential entities that fail to meet Article 23 obligations.

This distinction matters for three practical reasons.

The client holds the context CSIRT needs. A 72-hour notification must describe the entity’s affected services, the estimated number of users impacted, and the entity’s own mitigation actions. An MSSP serving clients across multiple sectors and jurisdictions holds the technical incident data, but not the business impact picture, the sector-specific reporting channel, or the specific competent authority the client must reach. The client must provide that context in its own name.

The notification is jurisdiction- and sector-specific. Each NIS2-regulated entity notifies its own designated CSIRT or competent authority, determined by the member state in which the entity is established or provides its services. An MSSP simultaneously serving 50 clients across a dozen EU member states cannot navigate that landscape on behalf of each client. National competent authorities require that regulated organisations in vital sectors file directly through established national channels — a relationship the client holds, not the MSSP.

Regulatory liability stays with the client. Even if an MSSP contacts the CSIRT unilaterally, that action does not satisfy the client’s regulatory obligation and may generate inconsistencies in the regulatory record that invite additional scrutiny. The MSSP faces separate contractual liability to the client for breaching SLA terms, but the Art.23 penalty exposure belongs solely to the regulated entity.

The Clock Problem: When the Client’s 24-Hour Window Actually Starts

Article 23 requires the early warning to be submitted within 24 hours of becoming aware of the significant incident. [1] The reporting timelines are strict and begin when the entity becomes aware, not when the investigation is complete. [5] In an outsourced SOC relationship, “when the entity becomes aware” is a specific moment — and it is not the same as when the MSSP’s analyst first flags the event.

When the SOC detects anomalous activity at 02:00 and the MSSP’s incident response lead confirms it is likely significant at 04:00, the MSSP has become aware. The client entity has not. The client’s 24-hour window has not started. What starts it is the MSSP’s notification to the client — and every minute between MSSP awareness and client notification is a minute subtracted from the client’s compliance window.

MSSP detects at	MSSP notifies client at	Client window remaining for early warning
02:00	02:30 — immediate escalation	23.5 hours
02:00	08:00 — next business-hours contact	18 hours
02:00	12:00 — after root-cause confirmation	14 hours
02:00	26:00 — following day	Client in breach of Article 23

The last row is not hypothetical. MSSPs that delay notification until an incident is confirmed as significant — a cautious practice driven by concern about false-positive escalation — can consume the client’s entire compliance window before they make contact. By the time the client learns what happened, fewer than 12 hours may remain for its team to prepare and submit a meaningful early warning.

The correct posture is to escalate on reasonable grounds of significance, not on confirmed significance. Article 23’s early warning stage is explicitly preliminary: it requires only that the entity indicate whether the incident is “suspected to have been caused by unlawful or malicious acts” and note any cross-border implications. [1] The word “suspected” acknowledges that certainty is not yet available. Waiting for certainty before notifying the client inverts the regulatory intent.

This creates a specific SLA requirement: the MSSP contract must define a maximum notification time for suspected significant incidents. Without that clause, the MSSP has no contractual obligation to escalate outside business hours, and the client has no recourse when its compliance window is consumed without its knowledge. Industry practice for managed security contracts generally treats 24 hours as the ceiling — the floor that lets the client meet its own NIS2 obligations — with same-day or sub-four-hour notification preferred for incidents suspected to be significant. [6]

Article 23 provides that “the mere act of notification shall not subject the notifying entity to increased liability.” [1] The same principle protects the MSSP operationally: notifying the client of a suspected significant incident that is later reclassified as not significant creates no adverse legal consequence for the MSSP under the Directive.

When the MSSP Is Also a NIS2 Entity: Parallel Obligations Under CIR 2024/2690

The analysis above describes the baseline scenario: client holds Art.23, MSSP holds the contractual notification duty to the client. That baseline changes when the MSSP is itself a NIS2-regulated entity and an incident crosses the significance thresholds for the MSSP’s own managed service.

Commission Implementing Regulation (EU) 2024/2690 defines those thresholds specifically for managed service providers and managed security service providers. An incident is significant for the MSSP’s own managed service when it meets any of the following criteria: [8]

Criterion	Threshold
Complete unavailability	Managed service completely unavailable for more than 30 minutes
Partial unavailability	Availability limited for more than 5% of Union users, or more than 1 million Union users (whichever is smaller), for more than one hour
Data compromise — malicious	Integrity, confidentiality, or authenticity of data compromised as a result of a suspected malicious action
Data compromise — impact-based	Breach impacting more than 5% of Union users or more than 1 million Union users (whichever is smaller)
Financial loss	Direct financial loss exceeding €500,000 or 5% of annual turnover, whichever is lower

These thresholds apply to the MSSP’s own managed service — its monitoring platform, its remote monitoring and management infrastructure, its SOC toolchain. A ransomware attack discovered inside one client’s isolated internal network does not automatically trigger these criteria for the MSSP. What triggers them is if the attack has compromised the MSSP’s shared infrastructure, crossed into other client environments via the MSSP’s management plane, or disrupted the MSSP’s own service delivery.

The resulting decision matrix:

Where is the incident?	MSSP’s own service affected?	Who files Art.23
Client’s infrastructure only (isolated)	No	Client entity notifies its CSIRT only
Client infrastructure + MSSP shared platform	Yes — CIR thresholds met	Client notifies its CSIRT + MSSP notifies its own CSIRT (parallel, separate filings)
MSSP’s own platform (affecting multiple clients)	Yes	MSSP notifies its CSIRT; each affected client assesses own Art.23 obligation independently

The second row — parallel obligations — is the scenario that Recital 86 of the Directive (non-binding interpretive context) anticipated when it observed that MSSPs “have themselves become cyberattack targets due to their close integration in the operations of entities.” [4] The 2021 Kaseya VSA compromise illustrates the mechanics: a vulnerability in the MSSP’s own remote monitoring platform was exploited across approximately 60 MSSPs, affecting an estimated 800 to 1,500 downstream businesses. Under today’s NIS2 framework, each compromised MSSP would file its own Art.23 notification for the disruption to its managed service — crossing the 30-minute complete-unavailability threshold within the first hour of service loss — while each affected client entity would simultaneously assess whether the disruption to its own services met the Art.23(3) significance criteria and file its own separate notification. Two notification chains, to potentially separate CSIRTs, on the same 24-hour clock.

Dual-status MSSPs — those qualifying as Annex I entities in their own right — should maintain two parallel incident response tracks: one supporting each client’s notification workflow, and one assessing the MSSP’s own Art.23 exposure against CIR 2024/2690. These tracks serve different purposes, have different owners, and must be documented separately in the MSSP’s own incident handling procedures.

What the MSSP Contract Must Say Under Article 21(2)(d)

Article 21(2)(d) requires NIS2-regulated entities to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” For a client entity using an MSSP with privileged access to its most sensitive systems, that obligation translates directly into the contractual terms governing the MSSP relationship.

As we examine in our guide to MSP toolchain supply chain assessment, the MSSP qualifies as a Tier 1 critical supplier under any rational risk-tiering framework — remote management access, multi-client blast radius, and code execution capabilities at scale. The contractual terms must reflect that classification. The following five clauses represent the minimum provisions that make an MSSP relationship Art.21(2)(d)-compliant, and they exist specifically to protect the client’s ability to meet its Art.23 obligations when an incident is first detected by the MSSP’s SOC.

1. Incident notification obligation with a defined time threshold
The contract must require the MSSP to notify the client of any suspected significant incident affecting the client’s infrastructure without undue delay, with a defined maximum notification time. Industry practice for managed security contracts treats 24 hours as the ceiling — the floor that lets the client meet its own NIS2 obligations — with sub-four-hour notification preferred for suspected significant incidents. [6] The notification must include: which systems are affected, the suspected attack type, and the time of first MSSP detection. This is the minimum information the client needs to begin its Art.23 early warning.

2. Evidence preservation before remediation
The MSSP must preserve all relevant logs, forensic artefacts, and investigation records for the period required to support the client’s Art.23 final report — due within one month of the incident notification — and any subsequent supervisory investigation. Containment or remediation steps that destroy forensic evidence before preservation is confirmed can place the client in breach of its reporting obligations and impede competent authority review.

3. Cooperation with the client’s CSIRT notification
The MSSP must cooperate with the client’s regulatory submission by providing indicators of compromise, attack timelines, affected data categories, and current containment status in a format compatible with the 72-hour detailed notification. This obligation must be explicit in the contract. Without a written duty to share, MSSPs may cite operational priorities or confidentiality constraints to withhold data the client needs for its regulatory filing.

4. Prohibition on unilateral CSIRT contact
The MSSP must not contact the client’s CSIRT or competent authority on the client’s behalf without express written authorisation for that specific incident. Unilateral MSSP disclosure does not satisfy the client’s regulatory obligation and may create inconsistencies in the regulatory record that invite additional scrutiny. If the MSSP is itself a NIS2-regulated entity filing its own Art.23 notification for its managed service, that is a separate filing in the MSSP’s own name — it does not affect the client’s obligation.

5. Sub-contractor notification chain
If the MSSP uses sub-processors for threat intelligence, forensic analysis, or specialist incident response, those sub-contractors must be contractually bound to notify the MSSP on the same timescales. The MSSP is the client’s single contractual point of contact. Delays in the sub-contractor chain cannot excuse the MSSP’s own notification delay to the client.

The SOC Discovery Protocol: From Detection to CSIRT Notification

When a SOC analyst flags a potentially significant event, the response sequence must run in minutes, not hours. The following steps apply the Article 23 cascade to an MSSP operational environment.

Step 1 — Classify the event’s location
Is the incident contained within the client’s isolated infrastructure, or has it reached the MSSP’s shared platform, management network, or toolchain? Location determines which Art.23 obligations activate. If the client’s environment is isolated and the MSSP’s own infrastructure is unaffected, this is a client-only Art.23 trigger.

Step 2 — Apply the Art.23(3) significance test
Has this caused, or could it cause, severe operational disruption or financial loss to the client? Has it affected, or could it affect, other persons with considerable material or non-material damage? [1] If either criterion is plausible — not confirmed, plausible — the incident is presumptively significant and escalation begins immediately.

Step 3 — Escalate to the MSSP’s incident response lead
A presumptively significant incident requires a named individual accountable for the notification timeline — not just a client ticket in the queue. The IR lead owns both the client-facing notification track and the MSSP’s own Art.23 exposure assessment.

Step 4 — Notify the client without undue delay
Contact the client’s designated security or compliance contact with sufficient information to begin its Art.23 early warning: affected systems, suspected attack type, and time of first MSSP detection. This notification is what starts the client’s 24-hour window. Every minute spent on internal confirmation before this call is a minute the client cannot recover.

Step 5 — Preserve evidence before remediation
Do not proceed with containment or remediation actions that would destroy forensic artefacts without the client’s explicit direction. The client’s Art.23 final report requires a root-cause description. That description requires preserved evidence.

Step 6 — Support the client’s 72-hour notification
Provide technical data in a structured format: indicators of compromise, initial attack vector, affected data categories, event timeline, and current containment status. This is the MSSP’s primary technical contribution to the client’s detailed 72-hour submission to the CSIRT.

Step 7 — Assess the MSSP’s own Art.23 exposure
In parallel with Steps 4 to 6: review CIR 2024/2690 significance thresholds for the MSSP’s own managed service. If the MSSP’s service has been disrupted or its data compromised, the MSSP files its own Art.23 notification to its own CSIRT — a separate process, on the same 24-hour clock, with different content.

Step 8 — Document the timeline
Record with timestamps: when the MSSP first became aware; when the client was notified; what information was provided; when the client acknowledged receipt. This documentation is the MSSP’s evidence of contract compliance and the evidentiary record for any supervisory review of the client’s Art.23 submissions.

Action	MSSP / SOC	Client entity
Detect the incident	Primary	Secondary — learns from MSSP
Assess significance for client’s services	Advises; provides technical data	Decides — owns the significance assessment
File Art.23 early warning to CSIRT	Not applicable unless MSSP’s own service is affected	Yes — within 24 hours of becoming aware
Notify client’s service recipients	Not applicable	Art.23 obligation when adverse impact is likely
Assess MSSP’s own service significance	Yes — applies CIR 2024/2690 thresholds	Not applicable
File Art.23 for MSSP’s own managed service	If CIR thresholds are met	Not applicable
Preserve forensic evidence	Contractual obligation — preserve before remediation	Required for Art.23 final report

Frequently Asked Questions

Can the MSSP notify CSIRT on the client’s behalf?
No. Article 23(1) places the obligation on “essential and important entities” — the client entity. The reporting obligation cannot be delegated to a managed security service provider. [5] The MSSP can prepare the notification data and assist in its submission, but the client files it in its own name and remains the liable party. An MSSP contacting the CSIRT unilaterally does not satisfy the client’s regulatory obligation and may create inconsistencies in the regulatory record that complicate the client’s own submission. [1]

If the MSSP files its own Art.23 notification for its managed service, does that satisfy the client’s obligation?
No. The MSSP’s Art.23 filing covers the impact on the MSSP’s own managed service, assessed against CIR 2024/2690 significance thresholds. [8] The client’s Art.23 obligation covers the impact on the client’s own services and infrastructure, assessed against the Article 23(3) criteria. [1] These are separate filings, to potentially separate CSIRTs, with different technical content. One does not substitute for the other.

When exactly does the client’s 24-hour clock start?
The clock begins when the client entity becomes aware of the significant incident — not when the MSSP’s SOC first detects it, and not when root-cause investigation is complete. The reporting timelines are strict and begin at awareness, not at investigation conclusion. [5] In an MSSP relationship, client awareness typically begins when the MSSP’s notification reaches the client’s designated contact. MSSP notification speed is therefore a direct compliance variable for the client.

Do the CIR 2024/2690 significance thresholds apply to incidents in the client’s own infrastructure?
No. CIR 2024/2690 defines when an incident is significant specifically for the MSSP’s own managed service — triggering the MSSP’s own Art.23 obligation. [8] For assessing whether an incident in the client’s infrastructure is significant for the client’s own Art.23 purposes, the client applies the general Article 23(3) criteria: severe operational disruption, financial loss, or considerable damage to others. [1] The two significance tests are independent of each other.

What if the client refuses to notify CSIRT despite the incident being significant?
The legal obligation and the regulatory liability lie with the client. The MSSP should ensure its notification to the client is documented in writing with timestamps. If the MSSP is itself a NIS2 Annex I entity and the incident has triggered CIR 2024/2690 thresholds for its own managed service, the MSSP’s own Art.23 obligation may activate regardless of the client’s decision. MSSPs acting as regulated entities in their own right should consider contractual provisions requiring clients to confirm CSIRT notification within the applicable window, or to acknowledge in writing that they have chosen not to file, so the MSSP’s own compliance record is protected.

Key Takeaways

Under Article 23(1), the CSIRT notification obligation belongs to the NIS2-regulated client entity. The reporting obligation cannot be delegated to an MSSP; the entity itself is responsible for timely filing. [5]
The client’s 24-hour window starts when the client becomes aware — in practice, when the MSSP notifies the client. MSSP notification delays directly reduce the compliance window the client has available.
The MSSP contract must include a defined maximum notification time for suspected significant incidents, evidence preservation obligations, cooperation with CSIRT submission, prohibition on unilateral CSIRT contact, and a sub-contractor notification chain.
If the MSSP is itself an Annex I essential or important entity, it carries parallel Art.23 obligations when its own managed service meets CIR 2024/2690 significance thresholds — regardless of the client’s filing.
In the dual-entity scenario — an attack affecting both client infrastructure and the MSSP’s managed service — two separate Art.23 notifications run in parallel, to potentially separate CSIRTs, on the same 24-hour clock.
Maintain two parallel incident response tracks: one supporting the client’s Art.23 workflow; one assessing the MSSP’s own Art.23 exposure. Document them separately, with distinct owners and distinct content.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.