MSPs as Critical NIS2 Suppliers: Annex I Scope, Article 21(2)(d) Cascade Risk, and the Contracts You Need Before Your Clients Get Audited

A single compromised administrator credential at a managed service provider can simultaneously breach the security perimeters of every client that MSP manages. For a 50-person MSP administering 80 business clients — a dozen of whom qualify as essential entities under NIS2 — that is not one security incident. It is a regulatory cascade affecting dozens of organisations, each of which faces its own NIS2 enforcement exposure.

This amplification scenario is precisely why the NIS2 Directive places ICT service management (B2B) in Annex I — the same tier as energy grids, banking infrastructure, and hospitals — rather than the lower-criticality Annex II. The regime demands more from MSPs than most compliance guides acknowledge: you may be directly regulated as an essential or important entity in your own right, you almost certainly appear in your clients’ Article 21(2)(d) supplier assessments, and within weeks of a client’s NCA audit, you will be asked to produce evidence you may not yet have.

This guide maps all three dimensions: the Annex I scope boundary (what counts as ICT service management B2B and what does not), the direct Article 21 and CIR 2024/2690 obligations that apply to classified MSPs, and the five-clause contractual framework your NIS2-regulated clients are already beginning to require.

ICT Service Management (B2B): What Annex I Actually Covers

Annex I of the NIS2 Directive lists 11 sectors of high criticality. Sector 9 is ICT service management (Business-to-Business), which encompasses managed service providers (MSPs) and managed security service providers (MSSPs). The directive’s Article 6 definition of a managed service provider covers 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.

The critical qualifier is “Business-to-Business.” The B2B designation does significant work: it limits the sector to services provided to other organisations, not to consumers. This creates a clean scope boundary that most coverage of NIS2 for MSPs fails to draw clearly.

Service Type	In Scope (Annex I)	Rationale
Managed IT infrastructure for enterprise clients	Yes	B2B delivery of managed ICT systems
Network Operations Centre (NOC) services to businesses	Yes	Active administration of customer networks
Managed helpdesk contracted to business clients	Yes	Management of ICT systems on customers' behalf
Managed Security Service Provider (MSSP)	Yes	Explicitly named in Annex I subsector
Cloud management services for corporate clients	Yes	Management of network and information systems
Consumer PC repair / retail IT support	No	Not B2B — services to individuals, not organisations
Home broadband technical support	No	Consumer-facing, outside the B2B qualifier
In-house IT department of a non-ICT firm	No	Internal function, not providing services to other entities

Two scenarios require closer attention. First, MSPs that serve both business and consumer clients: only the B2B service lines are caught. Your enterprise managed helpdesk is in scope; your consumer tech support division is not. Second, intra-group IT services — an IT subsidiary managing systems exclusively for its own parent group — generally falls outside the sector definition because no service is being provided to third-party entities. However, where the subsidiary also provides services to clients outside the group, that portion of activity is in scope.

A scope determination is not a one-time exercise. If your MSP expands into new B2B verticals, or a corporate restructuring changes how IT services are delivered within a group, the assessment must be repeated. Regulators do not require prior notification of scope status, but they expect you to have documented your reasoning.

Essential vs Important: How Size Determines Your Enforcement Exposure

Classification as an essential or important entity under NIS2 depends on two concurrent factors: operating in an Annex I or Annex II sector, and meeting the applicable size threshold. For MSPs in the ICT service management (B2B) sector, the thresholds operate as follows.

Classification	Size threshold	Supervisory model	Maximum penalty
Essential entity	250+ employees OR €50M+ annual turnover (and €43M+ balance sheet)	Proactive, ex ante supervision; on-site inspections, audits without prior notice	€10 million or 2% of global annual turnover, whichever is higher
Important entity	50–249 employees OR €10M–50M turnover	Reactive, ex post supervision; triggered by incidents or complaints	€7 million or 1.4% of global annual turnover, whichever is higher
Sub-threshold (small/micro)	Fewer than 50 employees AND under €10M turnover	Not directly supervised as an entity	None under NIS2 directly (but see Section 8)

One size-determination trap specific to MSPs: group aggregation. If your MSP is owned by or part of a larger corporate group, employee and revenue figures from partner and linked enterprises may need to be consolidated under the EU SME definition. A 40-person MSP that is a wholly owned subsidiary of a 300-person consultancy group may well be classified as a medium or large undertaking for NIS2 purposes, even though it appears to be a small company when viewed in isolation.

Registration obligations apply once you determine you are a medium or large MSP in this sector. Entities must self-register with their national competent authority (NCA), providing name, contact details, sector, Member States served, and IP address ranges. Non-registration does not grant an exemption; supervisory authorities retain the power to designate entities regardless of self-registration status.

Article 21 Obligations Applied to MSPs — All 10 Measures

Once classified as an essential or important entity, an MSP faces the same Article 21 obligation set as any other NIS2 entity: implement appropriate and proportionate technical, operational, and organisational measures to manage the risks posed to its own network and information systems. The ten measure categories in Article 21(2) apply in full, but their implementation for a multi-tenant MSP environment requires MSP-specific interpretation.

(a) Risk analysis and information system security policies. A standard risk register is insufficient. MSPs must maintain a multi-tenant risk register that isolates customer environment assessments while maintaining consolidated reporting. Risks specific to shared administration tooling (RMM platforms, PSA systems) need explicit treatment.

(b) Incident handling. MSPs carry dual incident-handling obligations: their own reporting timeline to the NCA, and a contractual obligation to notify clients early enough for those clients to meet their own 72-hour NCA reporting window. These timelines interact in ways standard incident response plans do not account for. See Section 9 for the dual-track timeline.

(c) Business continuity, backup management, disaster recovery, and crisis management. SLA commitments to clients must be backed by tested BCM plans. Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) must be documented per client environment, not just at the aggregate MSP level.

(d) Supply chain security. Article 21(2)(d) requires supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. For MSPs, this means assessing the security of the tools, platforms, and sub-vendors that underpin your own service delivery: your RMM provider, your monitoring stack, your cloud infrastructure partners. Article 21(3) further requires evaluating the cybersecurity practices and secure development procedures of these direct suppliers.

(e) Security in network and information systems acquisition, development, and maintenance. Vulnerability management across tools used to manage client environments, patching SLAs, and security testing of custom integrations.

(f) Policies and procedures to assess the effectiveness of cybersecurity risk management measures. Regular control effectiveness testing, including penetration testing where appropriate under CIR 2024/2690.

(g) Basic cyber hygiene practices and cybersecurity training. Mandatory security training for all technical staff, documented and timestamped.

(h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption. Key management lifecycle requirements: generation, rotation, revocation, and destruction protocols for keys used in both MSP infrastructure and client environments.

(i) Human resources security, access control policies, and asset management. Privileged access governance is the critical control here. Every administrator credential that can access multiple client environments is a single point of systemic failure and must be managed with explicit documented controls.

(j) Multi-factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems where appropriate. MFA is non-negotiable for critical system access and all remote administration sessions under CIR 2024/2690.

CIR 2024/2690: The Directly Binding Control Layer

Commission Implementing Regulation (EU) 2024/2690 is the layer of NIS2 compliance most MSPs have not yet fully reckoned with. Unlike the NIS2 Directive itself, which required member-state transposition, the CIR is a regulation: it has been directly applicable across all 27 EU member states since 18 October 2024, without any national implementation step. It explicitly names ICT service management entities (MSPs and MSSPs) as directly covered.

Where Article 21 establishes principle-based obligations, the CIR translates them into 150+ specific, auditable controls organised across 13 Annex sections. Three sections are particularly relevant to MSPs:

Section 5 — Supply chain security. Requires a documented supply chain security policy; assessment of each direct supplier’s cybersecurity practices using defined selection criteria; contractual security requirements in all supplier agreements; and ongoing monitoring of supplier security posture throughout the contract lifecycle. This applies to your own sub-suppliers: the cloud providers hosting your management platforms, the software vendors whose tools touch client environments, and any sub-contracted technical functions.

Section 9 — Cryptographic controls. Specifies algorithm and key management lifecycle requirements beyond Article 21(h)’s general reference to cryptography policies.

Incident significance thresholds. The CIR provides the quantified thresholds absent from Article 21 itself. A “significant incident” for MSPs includes any incident causing financial loss of €500,000 or more, or affecting 5% of annual global turnover. Incidents causing major disruption to service delivery to a large number of clients simultaneously would also meet the threshold, reinforcing the systemic-risk reasoning behind Annex I placement.

Practically, a classified MSP managing its compliance as though only the NIS2 Directive applies is already non-compliant. The CIR demands are real, currently in force, and regulators in jurisdictions with active NIS2 supervisory bodies (Germany’s BSI, the Netherlands’ NCSC, Belgium’s CCB) have begun referencing CIR controls in their published guidance. For detailed logging and monitoring requirements under the CIR, see our CIR 2024/2690 logging requirements guide.

The Cascade Risk Multiplier — Why MSPs Are Annex I, Not Annex II

The placement of ICT service management (B2B) in Annex I — alongside power grids, hospital networks, and banking infrastructure — is not an accident of legislative drafting. It reflects a specific risk architecture that separates MSPs from other business services.

An essential entity in the energy sector whose systems are compromised represents a threat to energy supply. An MSP whose administrative systems are compromised represents a simultaneous threat to every organisation that MSP manages — including multiple essential entities across multiple sectors. The systemic risk is multiplicative, not linear. A single privileged credential in a commonly used Remote Monitoring and Management (RMM) platform can, if exploited, provide authenticated access to dozens of client environments within minutes.

Industry data on supply chain exposure is stark. According to analysis of regulated supply chain vulnerability patterns, critical suppliers account for approximately 38% of identified vulnerabilities in regulated supply chains, while 62% of major incidents in regulated sectors have roots in unassessed third-party failures. For MSPs operating as critical suppliers to multiple essential entities, this is not an abstract statistical risk — it is the mechanism that regulators have written directly into Annex I.

The cascade operates in two directions. Upstream: your own sub-suppliers (RMM vendors, monitoring platforms, cloud providers) represent concentration risks. A vulnerability in your RMM tool is effectively a vulnerability in every client environment you manage. Downstream: a breach of your administrative systems propagates to all clients simultaneously, potentially triggering Article 23 incident notification obligations for each affected client, each with its own 72-hour NCA reporting clock.

Article 22 of the NIS2 Directive empowers the Cooperation Group, working with the Commission and ENISA, to conduct coordinated security risk assessments of critical ICT supply chains — and Article 21(3) requires entities to take the results of those assessments into account when managing supply chain risk. MSPs are the primary subject of this provision. The EU-level supply chain risk assessment process was designed specifically for the scenario where a small number of providers serve a large proportion of critical entities across multiple sectors.

For management teams, the Annex I classification has a governance implication beyond the compliance checklist. NIS2 Article 20 holds the management bodies of essential and important entities personally accountable for the approval and oversight of cybersecurity risk management measures. A board that delegates compliance entirely to the IT team without documented oversight — and then discovers that an RMM tool compromise has cascaded to 40 clients — faces both regulatory exposure and potential personal liability. The MSP-as-critical-supplier risk is a board-level risk, not an IT operations footnote.

The 5-Clause Contract Your NIS2 Clients Will Require

Your clients who qualify as essential or important entities under NIS2 are not asking for better security out of preference. Article 21(2)(d) legally requires them to manage supply chain security — including the security aspects of relationships with their direct service providers. That obligation flows directly into the contracts they hold with you. Here are the five clauses now appearing in NIS2-compliant supplier contracts, what they require from your operations, and what evidence you should be preparing.

Clause 1: Security baseline alignment. Your client will require you to implement cybersecurity measures at least equivalent to a defined baseline. Acceptable references include: direct enumeration of the Article 21(2) categories covered; certification to ISO/IEC 27001:2022 with a current Annex A statement of applicability; or reference to a nationally recognised framework (BSI IT-Grundschutz for German clients, ANSSI PSSI for French clients). The clause should also include a change-management commitment: written notification before making any material changes that would weaken the agreed security standard.

Clause 2: Incident notification chain. You must notify the client within 24 hours of detecting a significant incident affecting services provided to them. Notification must include: suspected cause, cross-border impact assessment, affected services and data categories, and initial containment actions taken. This 24-hour client notification enables the client to meet its own 72-hour NCA reporting obligation under Article 23. The clause typically requires updates every 24 hours during an active incident and a final incident report within one month, mirroring the entity’s own NCA reporting schedule.

Clause 3: Subprocessor transparency. You must disclose critical subcontractors that touch client systems or data upon request, provide their security baseline documentation, obtain written consent before adding, replacing, or removing critical subcontractors, and notify the client within 30 days of any ownership change in your own organisation that could affect your security posture or the client’s risk profile. Regulators expect evidence that this clause has been exercised: documented subcontractor lists, consent records, and notification logs.

Clause 4: Audit rights and certifications. Your client retains the right to audit your cybersecurity practices annually, either directly or through an accredited third party, and additionally following any significant incident. Standard certifications serve as audit substitutes where scope is adequate: ISO/IEC 27001:2022 with a current certificate, SOC 2 Type II report, TISAX assessment at the relevant assurance level, or CSA STAR Level 2 attestation. A current certification does not eliminate the ad hoc audit right following an incident.

Clause 5: Termination assistance and data management. Upon contract termination, you must provide 30 to 90 days of continuity support to facilitate an orderly transition. Client data must be returned in machine-readable formats on defined timelines. Certified secure deletion must occur within 30 days of confirmation that the client has received and verified the data. Any backups legally required by your own regulatory obligations are carved out, but access and retention limits must be clearly defined.

From an MSP business perspective, these five clauses represent the minimum that enterprise procurement teams at NIS2-regulated clients will present. The clients who ask for the most comprehensive versions will be your largest accounts — the same essential entities whose contracts are most valuable to retain. Preparing for these clauses before they arrive in a contract negotiation is substantially easier than responding to them under deadline pressure.

Sub-Threshold MSPs: Out of Direct Scope, Still in the Chain

If your MSP employs fewer than 50 people and generates under €10 million in annual revenue, NIS2 does not directly regulate you as an essential or important entity. You are not required to register with your national competent authority, and the supervisory penalties under Article 21 do not apply to you directly.

This does not mean NIS2 is irrelevant to your business. It means the regulatory pressure arrives through a different channel: your clients.

Your NIS2-regulated clients must implement Article 21(2)(d) supply chain security measures — and that obligation requires them to assess your cybersecurity practices, evaluate your secure development procedures, and ensure appropriate security clauses are embedded in your contract. From the regulated client’s perspective, your size is irrelevant; what matters is the access you have to their systems and the security practices you maintain. A sub-threshold MSP with privileged access to a hospital’s network is a critical supplier regardless of headcount.

In practice, sub-threshold MSPs serving regulated clients will face security questionnaires, requests for evidence of Article 21 controls, demands for contractual clauses, and audit rights exercises — all flowing from their clients’ own compliance obligations rather than from direct NCA supervision. The practical compliance burden of serving NIS2-regulated clients is largely the same whether you are classified as an important entity or not.

The strategic choice for sub-threshold MSPs is whether to adopt the Article 21 framework proactively — which allows you to respond quickly to client due diligence requests and retain regulated clients who would otherwise seek more compliant alternatives — or to treat compliance as a case-by-case contractual negotiation. The former is operationally more efficient for any MSP with more than two or three regulated clients. For scope questions specific to your organisation type, see our NIS2 scope determination guide.

Incident Notification: The Dual-Track Timeline for MSPs

Classified MSPs — those registered as essential or important entities — operate two parallel incident notification timelines that must be managed simultaneously when a significant incident occurs.

Track 1: MSP’s own NCA reporting obligation under Article 23.

• Within 24 hours: Early warning to the national competent authority. Content: detection date and time, initial assessment of significance, suspected threat category.
• Within 72 hours: Full incident notification. Content: updated impact assessment, affected entities, likely cause, cross-border impact assessment, initial remediation measures.
• Within 1 month: Final report. Content: root cause analysis, full impact description, remediation measures taken and timeline for outstanding actions.

Track 2: Client notification obligation under contract.

• Within 24 hours of detection: Notify each affected client. Content: suspected cause, description of affected services and data, cross-border impact potential, initial containment actions. This early notification gives clients enough lead time to comply with their own 72-hour NCA reporting obligation.
• Every 24 hours during an active incident: Status update to each affected client.
• Within 1 month: Final incident report to each affected client, mirroring the NCA reporting structure.

The practical challenge is that a significant incident at an MSP level often affects multiple clients simultaneously. An incident response plan that is scoped to a single-entity notification model — standard for non-MSP NIS2 entities — does not scale to simultaneous multi-client notification. MSPs need incident response procedures that include: a client impact assessment step (which clients are affected and to what degree?), a notification queue process (prioritising clients with the shortest remaining reporting windows), and template notifications that can be customised per client within the 24-hour window. For a more detailed guide on incident reporting procedures, see our Article 23 incident notification guide.

The CIR 2024/2690 significance threshold (€500,000 financial loss or 5% of annual global turnover) sets the minimum bar for NCA notification. Incidents affecting multiple clients may cross this threshold even if no single client’s impact would reach it; the aggregate financial loss across all affected managed environments is the relevant figure.

Frequently Asked Questions

Does NIS2 apply to our MSP if we are headquartered outside the EU but serve EU clients?

The jurisdictional question for MSPs is service location, not establishment location. If you provide ICT service management to organisations within the EU that are themselves essential or important entities, those clients must include you in their Article 21(2)(d) supply chain assessments regardless of where your company is incorporated. Direct entity classification (essential/important) depends on whether you have an establishment within the EU; the contractual cascade obligations apply either way.

We serve both business and consumer clients. Which part of our operation is regulated?

The B2B qualifier limits Annex I scope to services provided to other organisations, not to consumers. The practical approach is to treat each service line separately: your enterprise managed helpdesk and NOC fall within scope; your consumer IT support division does not. Where the same technical staff and systems serve both customer types, the compliance obligations apply to the B2B service delivery, and you should document the functional separation between service lines as part of your scope assessment.

When does active enforcement begin?

The transposition deadline for member states was 17 October 2024. Germany transposed via the NIS2UmsuCG in December 2025; the Netherlands, Belgium, and several other member states had active supervisory frameworks in place by mid-2025. CIR 2024/2690 has been directly applicable across all 27 member states since 18 October 2024, with no transposition requirement. You cannot rely on your member state’s pending transposition as a reason to delay compliance with the CIR. For NIS2-scoped clients in already-transposed jurisdictions, audit requests are already live. See our MSP and MSSP compliance overview for jurisdiction-specific status.

How does a sub-threshold MSP handle audit requests from NIS2-regulated clients?

Sub-threshold MSPs are not entitled to refuse client audit requests by citing their non-classified status; the audit right in the contract flows from the client’s obligation to verify supplier security under Article 21(2)(d), not from any direct regulatory authority the client holds over you. The most efficient response is to obtain a current ISO/IEC 27001:2022 certificate, SOC 2 Type II report, or equivalent attestation, which serves as the audit substitute accepted under most NIS2 supplier contracts, eliminating the need for repeated client-specific audit exercises.

Sources

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.

• NIS 2 Directive Article 21: Cybersecurity Risk-Management Measures — nis-2-directive.com
• NIS 2 Directive Article 6: Definitions (managed service provider) — nis-2-directive.com
• NIS 2 Directive Article 22: Union Level Coordinated Security Risk Assessments of Critical Supply Chains — nis-2-directive.com
• Navigating NIS 2: A Guide to Applicability for Managed Service Providers — Kemp IT Law
• NIS2 Supply Chain Security: 5 Clauses to Require from Your Suppliers — nis2insights.com
• CIR 2024/2690 — NIS2 Technical Measures — nisd2.eu
• NIS2: Understanding the Obligations of Critical Suppliers — Aprovall
• NIS-2 for IT Service Providers and MSPs: Annex I as ICT Service Management — Cybervize
• NIS2 in Practice: What Managed Service Providers Need to Know Now — Lywand
• NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure — Advisera