The MSSP NIS2 Compliance Paradox: Why Security Service Providers Face Double Obligations Under Annex I and CIR 2024/2690

Where MSSPs Sit Under NIS2: Annex I, Sector 9

Most compliance guidance describes NIS2 as something that happens to your clients. For managed security service providers, that framing is wrong at the regulatory level.

NIS2 Directive (EU) 2022/2555, Annex I, Sector 9, lists two entity types under “ICT service management (business-to-business)”: managed service providers and managed security service providers. Annex I covers sectors of high criticality — the same list that includes energy grids, banking infrastructure, and hospitals. MSSPs are not in the lighter Annex II category; they sit alongside digital infrastructure providers because of how deeply integrated their operations are into the networks they protect.

Article 6 of the Directive defines the scope precisely. Under Art.6(39), a managed service provider is “an entity that provides services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other network and information systems, via assistance or active administration carried out either on customers’ premises or remotely.” Under Art.6(40), an MSSP is a managed service provider “that carries out or provides assistance for activities relating to cybersecurity risk management.”

Whether a specific MSSP qualifies as an essential or important entity depends on size, per Art.3:

Classification	Threshold (Annex I entities)	Supervision model	Maximum fine
Essential entity	250+ employees OR €50M+ annual turnover	Proactive, ex-ante audits	€10M or 2% global turnover
Important entity	Below essential thresholds, 50+ employees OR €10M+ turnover	Reactive, ex-post only	€7M or 1.4% global turnover

The penalty figures come from Art.34(4) and (5) of the Directive, and apply to breaches of Art.21 (security measures) or Art.23 (incident reporting). An MSSP below 50 employees and €10M turnover falls outside the scope entirely; all others are in scope and must determine which tier applies to them.

One practical point: NIS2 applies a group-level turnover calculation for the size test. An MSSP that is a subsidiary of a larger technology group may qualify as an essential entity even if its own headcount is modest.

The Dual Compliance Obligation

Being named in Annex I creates the first obligation: the MSSP must comply with Art.21 risk-management measures for its own network and information systems. That is the same obligation every other regulated entity faces — documented policies, management governance, technical controls, incident procedures.

The second obligation is less obvious and more operationally disruptive. Because MSSPs deliver security services to clients who are themselves regulated under NIS2, the MSSP’s compliance posture directly determines whether those clients can satisfy their own Art.21(2)(d) supply chain security requirement. Art.21(2)(d) obliges entities to address supply chain security “taking into account the vulnerabilities specific to each direct supplier or service provider.” For an NIS2-regulated organisation that has outsourced SOC operations or endpoint monitoring to an MSSP, that MSSP is a critical direct supplier. Its security posture is the client’s supply chain risk.

Recital 86 of the Directive makes the legislative intent explicit: MSSPs “play a particularly important role in assisting entities in their efforts to prevent, detect, respond to or recover from incidents.” The recital also notes that MSSPs “have also themselves been the target of cyberattacks” because of their close integration in client operations. The legislature understood the structural risk; the compliance obligation follows from that understanding.

The practical result is two compliance layers running in parallel:

Obligation layer	What it requires	Who in the MSSP owns it
Own-entity Art.21 compliance	All 10 Art.21(2) measures documented and implemented for the MSSP’s own infrastructure, staff, and operations	CISO / IT Security Lead
Client-facing supply chain position	Evidence that the MSSP’s own compliance enables clients to satisfy Art.21(2)(d); audit-ready documentation; contractual clauses complying with CIR 2024/2690 §5.1.4	Compliance Officer / Account Management

This dual structure is what general MSP and MSSP scope guidance does not address in depth. Knowing you are in scope is step one. Operating as both an obligated entity and a compliance enabler for dozens of clients simultaneously is the harder operational problem.

CIR 2024/2690: The Technical Standard That Directly Binds Every MSSP

The Directive’s Art.21(5) mandated that the Commission publish technical implementing requirements specifically for managed service providers and managed security service providers by 17 October 2024. Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690) is the result. Unlike the Directive itself, which sets principles, the CIR specifies exact control requirements. It applies directly to MSSPs; no national transposition step mediates its effect.

Several CIR sections carry particular weight for MSSP operations:

CIR §5.1 — Supply chain security policy: MSSPs must establish and apply a supply chain security policy governing their own suppliers. This means the tools an MSSP uses — RMM platforms, PSA systems, SIEM infrastructure, cloud orchestration layers — must be assessed, classified by criticality, and covered by contractual clauses. The Kaseya VSA compromise of July 2021 (CVE-2021-30116), which reached 60 MSSPs and 800–1,500 downstream businesses through a single authentication bypass vulnerability, illustrates what an unmanaged MSSP supply chain risk looks like in practice: the RMM platform itself was the blast radius.

CIR §6.7 — Network security: MSSPs must document their network architecture comprehensively and apply controls to prevent unauthorised access to internal domains. A SOC environment where analysts access multiple client tenants from a shared workstation network fails this requirement.

CIR §6.8 — Network segmentation: Systems must be segmented “in accordance with the results of the risk assessment” and separated from third-party systems. For MSSPs managing multi-tenant environments, this means each client’s monitoring data and alert stream must be logically isolated. An MSSP that allows a misconfiguration in one client tenant to expose another client’s network topology violates §6.8.

CIR §6.9 — Protection against malicious and unauthorised software: Entities must implement measures that detect or prevent malicious software and must equip their systems with “detection and response software, which is updated regularly in accordance with the risk assessment.” This maps directly to SOC operations and is addressed in the next section.

CIR §6.10 — Vulnerability handling: MSSPs must monitor vulnerability channels, perform periodic scans, and address critical vulnerabilities “without undue delay.” For MSSP infrastructure including RMM agents and SIEM connectors, this creates an explicit patch-prioritisation obligation tied to criticality assessment rather than a generic quarterly patching schedule.

The SOC Compliance Loop: Where Service Delivery and Own Compliance Converge

CIR §6.9.2 requires MSSPs to equip their network and information systems with “detection and response software.” For an MSSP that operates a Security Operations Centre, that language describes the SOC itself. The SIEM platform, the SOAR tooling, the endpoint detection agents feeding into analyst dashboards — these are not just commercial service infrastructure. They are the detection and response capability that satisfies the MSSP’s own CIR §6.9.2 obligation.

This is the SOC compliance loop: the same capability an MSSP delivers to clients to help them satisfy their Art.21 monitoring obligations is simultaneously the mechanism through which the MSSP satisfies its own CIR requirement. The service and the compliance control are the same system.

The problem is documentation. Most MSSPs describe their SOC capabilities in sales materials, SLAs, and client onboarding packs. Almost none document the SOC as an internal Art.21 control. That distinction matters to an auditor. A competent authority examining an MSSP’s compliance programme will ask for the risk register entry that covers malware detection, the policy governing detection rule updates, and the evidence that the update cadence follows the risk assessment. A service description written for clients answers none of those questions.

Three documentation gaps appear most consistently in this area:

• Gap 1 — Missing internal detection policy: CIR §6.9.2 requires “detection and response software” to be maintained per the risk assessment. An SLA describing the service to clients is not a policy governing the MSSP’s own use of that software.
• Gap 2 — Undocumented update cadence: §6.9.2 requires updates “in accordance with the risk assessment.” A standard monthly update schedule with no documented risk-based rationale fails the control.
• Gap 3 — Missing production/test segregation: CIR §6.8.2(h) explicitly requires separation of production systems from development and testing, including backups. Multi-tenant SIEM environments that share infrastructure between test tenants and production clients violate this requirement directly.

Closing these gaps means treating the SOC as a compliance artefact as well as a commercial service: the same policies, the same governance documentation, the same evidence trail — but written from the perspective of the MSSP’s own Art.21 obligations rather than the client’s service experience.

What Your Clients Can Contractually Demand Under CIR §5.1.4

The same CIR that governs the MSSP’s own obligations also governs what the MSSP’s clients must put in their supplier contracts. CIR §5.1.4 requires NIS2-regulated entities to ensure their contracts with suppliers and service providers specify, where appropriate through SLAs:

• (a) Cybersecurity requirements for the MSSP, including ICT service acquisition security standards
• (b) Awareness, skills and training requirements, including certifications required from the MSSP’s employees
• (c) Requirements regarding background verification of the MSSP’s employees with access to client systems
• (d) An obligation on the MSSP to notify the client, “without undue delay,” of incidents that present a risk to the client’s network and information systems
• (e) The client’s right to audit the MSSP, or to receive audit reports in lieu of direct audit access
• (f) An obligation on the MSSP to handle vulnerabilities presenting a risk to the client’s systems

For the full context of how this sits within the ICT managed services supply chain risk picture, these clauses change the contractual dynamic at renewal. Clients who have engaged compliance advisors will arrive at their next contract review with a clause checklist derived directly from CIR §5.1.4. MSSPs that have not prepared for this face renegotiation pressure — or, in some cases, contract termination when a client’s auditor identifies an MSSP that cannot satisfy the Art.21(2)(d) evidence requirement.

The proactive response is to assemble an evidence package that clients can file in their supply chain audit trail:

• ISO 27001:2022 certificate (if held) — maps to multiple Art.21(2) measures and addresses many CIR §5.1.2(a) criteria for cybersecurity practices
• SOC 2 Type II report — covers detection and response controls; satisfies §5.1.4(e) audit right by providing a third-party report in lieu of direct client audit access
• Written incident notification procedure — specifically, the timeline and escalation path for notifying clients when an incident in the MSSP’s own infrastructure may affect client environments (§5.1.4(d))
• Employee background check policy — covering staff with privileged access to client tenants (§5.1.4(c))

MSSPs that prepare this package proactively convert a client pressure point into a commercial differentiator. See also the NIS2 scope guide for determining which of your clients are themselves NIS2-regulated and therefore likely to raise these demands.

Art.23 and the Double Notification Problem

Article 23 of the Directive requires entities to notify their national CSIRT of any significant incident within 24 hours of becoming aware of it (early warning), with a detailed notification within 72 hours, and a final report within one month. For a standard NIS2 entity, Art.23 runs on a single track: the entity notifies its CSIRT about incidents affecting its own network and information systems.

For MSSPs, a significant incident in their own infrastructure triggers a two-track notification obligation:

Track 1 — MSSP’s own Art.23 obligation: A breach of the MSSP’s RMM platform, SIEM infrastructure, or management network is an incident affecting the MSSP’s own systems. The MSSP must notify its national CSIRT within 24 hours of becoming aware that the incident meets the significance threshold.

Track 2 — CIR §5.1.4(d) contractual obligation to each affected client: Because the same incident may present a risk to client environments — particularly in multi-tenant configurations where the compromised RMM or SIEM has agent-level access to client endpoints — the MSSP must notify each affected client “without undue delay.” Those clients must then assess independently whether the incident, as it affects their own systems, reaches their Art.23 significance threshold and whether they in turn must notify their own CSIRT.

The 24-hour clock starts at awareness, not at root-cause confirmation. An automated alert indicating anomalous access to an MSSP’s RMM management console constitutes awareness for Art.23 purposes even before any forensic investigation begins. MSSPs that wait for incident confirmation before opening the notification procedure breach Art.23 from the moment awareness occurred.

The consequence is that an MSSP managing 50 NIS2-regulated clients needs a pre-written notification cascade covering three parallel tracks: the MSSP’s own CSIRT notification, the client alert procedure with defined escalation paths per client, and a template that clients can use in their own CSIRT notifications. That cascade must be rehearsed in tabletop exercises because under time pressure, improvised multi-party notification consistently misses the 24-hour early-warning window for at least one recipient.

MSSPs without a documented and rehearsed cascade face the highest near-term enforcement risk in this area. Competent authorities examining incident response evidence have found that the absence of a pre-written multi-party notification procedure is one of the most common single failure points in MSSP Art.23 compliance.

MSSP NIS2 Compliance Roadmap: Eight Steps in Priority Order

The following sequence reflects the order in which steps produce the most risk reduction relative to enforcement exposure. Start with scope and contracts; build internal controls in parallel; complete evidence packaging last.

#	Step	Effort	What it addresses
1	Confirm scope: calculate employee count and turnover at group level; determine essential vs important classification	Low	Art.3, supervision model, applicable penalty tier
2	Audit existing client contracts for CIR §5.1.4 clauses; update templates for new engagements	Medium	CIR §5.1.4 — incident notification, audit rights, vulnerability handling
3	Document SOC operations as an internal Art.21 compliance control, not just a client-facing service description	High	CIR §6.9.2 detection and response software; Documentation Gap 1
4	Network segmentation audit: verify tenant isolation in multi-client SIEM and RMM environments; document production vs test separation	High	CIR §6.8 — blast radius containment; Documentation Gap 3
5	Write and rehearse the dual Art.23 notification cascade: CSIRT notification + client alert procedure + client CSIRT notification template	Medium	Art.23 dual notification; CIR §5.1.4(d)
6	Assemble client evidence package: ISO 27001 certificate, SOC 2 Type II report, written §5.1.4(d) notification procedure	Medium	Art.21(2)(d) from client perspective; supply chain audit readiness
7	Obtain formal management body approval of Art.21 measures per Art.20	Low	Art.20 governance — independently enforceable; personal liability of management body members
8	Register with national competent authority as an Annex I Sector 9 entity per the member-state deadline	Low	Art.3(3) registration obligation (17 April 2025 baseline; many NCAs accepting late registrations)

MSSPs that already hold ISO 27001:2022 certification will find steps 3 through 7 significantly shorter. The ISO 27001 control set maps to most Art.21(2) measures, but internal documentation must explicitly reference the NIS2 articles and CIR sections. A generic ISMS policy without those cross-references will not satisfy a competent authority audit. See the NIS2 supply chain security hub for how the MSSP’s own Art.21(2)(d) supplier assessment feeds into the broader compliance picture.

Frequently Asked Questions

Do MSSPs have to comply with NIS2 even if all their clients are outside the directive’s scope?

Yes. NIS2 scope is determined by the MSSP’s own sector classification (Annex I Sector 9) and size, not by the NIS2 status of its client base. An MSSP with 300 employees managing cybersecurity for small businesses that are not regulated under NIS2 is still an Annex I entity subject to Art.21, Art.23, and CIR 2024/2690.

What is the difference between an MSP and an MSSP under NIS2?

Both are listed in Annex I Sector 9 and both face the same Art.21 and Art.23 obligations. The legal distinction lies in Art.6(39) and (40): an MSP provides ICT management and operational services; an MSSP is an MSP that specifically carries out or assists with cybersecurity risk management activities. In practice, the line blurs when an MSP also provides endpoint security, patching, or network monitoring. When that happens, the entity is likely an MSSP for NIS2 purposes regardless of how it describes itself commercially.

If an MSSP holds ISO 27001:2022 certification, does that satisfy NIS2 Art.21?

Partially. ISO 27001:2022 maps closely to several Art.21(2) measures, and competent authorities have generally treated it as evidence of good security practice. However, it does not cover all NIS2 requirements: Art.21(2)(j) MFA obligations and the specific Art.23 incident notification cascade, for example, require supplementary documentation. The certification must also be maintained and re-audited periodically; a lapsed certificate provides no compliance evidence at the time of an audit.

Can an MSSP’s clients recover losses from the MSSP if a breach leads to an NIS2 fine?

NIS2 does not create direct civil liability between the MSSP and its clients. The fine is imposed on the client by the competent authority for the client’s failure to satisfy Art.21(2)(d). Whether the client can then recover from the MSSP depends on the indemnity clauses, limitation of liability caps, and negligence standards in the specific contract. MSSPs should review their master service agreements in light of the contractual rights that CIR §5.1.4 now grants to clients.

When does a security incident in an MSSP’s infrastructure trigger Art.23 notification?

Art.23 is triggered when an incident is “significant” under Art.23(3). Significance arises when the incident causes, or is capable of causing, severe operational disruption or financial loss (Art.23(3)(a)), or significant material or non-material damage to other persons (Art.23(3)(b)). For an MSSP, a breach reaching its RMM platform with agent-level access to client endpoints almost certainly meets the Art.23(3)(b) threshold because of the potential for downstream harm. The 24-hour early-warning clock starts at awareness of the incident, not at the point where significance is formally confirmed.

Sources

• NIS2 Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
• NIS2 Directive (EU) 2022/2555, Article 6 — Definitions (Art.6(39) MSP; Art.6(40) MSSP)
• NIS2 Directive (EU) 2022/2555, Article 3 — Essential and important entities
• NIS2 Directive (EU) 2022/2555, Article 34 — Administrative fines
• NIS2 Directive (EU) 2022/2555 — Annex I Sector 9 and Recital 86 (EUR-Lex)
• Commission Implementing Regulation (EU) 2024/2690 — Technical and methodological requirements (CIR)

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.