Which ICT Managed Services Fall Under NIS2 Annex I? Scope Checklist, 8 CIR Contract Clauses, and Article 21 Controls for MSPs

Most MSPs approach NIS2 the wrong way: they ask whether the directive applies to their company rather than which of their service lines trigger the obligation. The NIS2 Directive (EU) 2022/2555 places the “ICT service management (B2B)” category in Annex I — high-criticality, alongside energy and healthcare — but that classification is determined by activity, not company name. An MSP can have some service lines in scope and others outside it.

This guide provides four working checklists: a scope determination checklist to assess which managed services fall within Annex I; a contract clause checklist drawn from Commission Implementing Regulation (EU) 2024/2690, Annex, point 5.1.4; a multi-client incident response procedure covering the multi-CSIRT notification challenge unique to MSPs serving clients across multiple EU member states; and an Article 21(2) security measure checklist applied to the specific realities of multi-tenant operation. Compliance officers who need quick reference: use the checklists directly. IT managers who need implementation context: read the notes under each item.

Which of Your Services Fall Under NIS2? Scope Determination Checklist

The “B2B” qualifier in Annex I does real work. Article 6(39) of the NIS2 Directive defines a managed service provider as an entity providing 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 “via assistance or active administration” clause is the distinguishing test: passive product supply is not a managed service; ongoing operational involvement is.

The B2B qualifier excludes consumer-facing IT services — home PC repair, retail tech support. It also excludes internal IT departments operating solely within a single corporate entity, though intra-group MSPs providing services to affiliate companies occupy contested territory under several national transpositions and benefit from jurisdiction-specific legal advice. Apply the checklist below per service line, not per company.

Checkpoint	In-scope indicator	Out-of-scope indicator
Service nature	Ongoing installation, management, operation, or maintenance of the client’s ICT systems	One-off project delivery; pure hardware or software supply with no operational responsibility
Client type	Another business, public body, or organisation	Private consumer (the B2B qualifier explicitly excludes consumer-facing services)
Delivery mode	Active administration or remote assistance — RMM, SOC, managed backup, managed cloud, endpoint management	Advice-only engagement with no operational access to client systems
Organisation size	≥50 employees OR >€10M annual revenue — meets minimum threshold for important entity status; ≥250 employees OR >€50M revenue — essential entity	<50 employees AND ≤€10M revenue — likely outside direct NIS2 scope as a registered obligee
Geographic connection	Established in the EU, or providing services to NIS2-registered entities headquartered in the EU	Operations entirely outside the EU with no EU client base

Services that typically qualify: remote monitoring and management (RMM) of client networks, managed security operations (SOC/SIEM), managed backup and disaster recovery, managed cloud infrastructure administration, endpoint detection and response services, managed firewall and network services.

Services that typically do not qualify: break-fix support without ongoing operational responsibility, pure software resale without managed services, consultancy engagements without system access, one-off migration projects with no post-delivery management obligation.

Sub-threshold MSPs — those with fewer than 50 employees and under €10M annual revenue — are not direct NIS2 obligees under Annex I. However, their NIS2-regulated clients are required to manage supply chain security under Article 21(2)(d), and that obligation flows into vendor contracts. The eight CIR contract clauses in the next section are the most common NIS2-derived requirements a sub-threshold MSP encounters via client agreements. See the NIS2 entity scope and registration guide for the full registration process once in-scope status is confirmed.

8 CIR 2024/2690 Annex 5 Contract Clauses for MSP Client Agreements

Commission Implementing Regulation (EU) 2024/2690, Annex, point 5.1.4 specifies eight categories of cybersecurity-related contractual provisions that entities should include in supplier agreements. For MSPs, these clauses cut in two directions simultaneously: upward, as requirements your NIS2-regulated clients are inserting into your MSA at renewal; and downward, as obligations you must flow to your own technology vendors — your RMM platform provider, PSA vendor, and security tooling suppliers.

The CIR frames these as items entities are “encouraged to include” via service level agreements, applying a proportionality principle. Omitting a clause is permissible if you document why it is “not appropriate” for the specific relationship. That comply-or-explain documentation burden is real: leaving gaps without written justification is an audit exposure that is straightforward for a competent authority to identify.

• Clause 1 — General cybersecurity requirements: specify that the supplier’s security practices must align with ICT acquisition standards referenced in CIR Annex point 6.1. For your technology vendors, this means requiring evidence of documented security policies at onboarding.
• Clause 2 — Personnel qualifications: require the supplier’s personnel to hold relevant awareness, skills, training, and — where appropriate — certifications for the services provided. For MSPs contracting with sub-processors, this sets the technician qualification floor.
• Clause 3 — Background verification: background-check obligations for supplier employees with access to your network or client data. Particularly important where a sub-contractor holds privileged access to managed client infrastructure.
• Clause 4 — Incident notification: duty on the supplier to notify you “without undue delay” of security events presenting a risk to your systems. In MSP client contracts, this clause should specify a notification window shorter than 24 hours — preserving the client’s own NIS2 reporting timeline before their early-warning clock runs.
• Clause 5 — Audit rights: your right to audit the supplier’s security practices directly, or to receive and rely on third-party audit evidence (ISO 27001 certification, SOC 2 Type II). Agreed frequency and scope should be stated explicitly.
• Clause 6 — Vulnerability handling: obligations on the supplier to address, patch, and disclose vulnerabilities in their products or services with agreed remediation timelines. For MSPs: this clause in RMM or endpoint-agent vendor contracts directly limits blast-radius exposure when a vendor vulnerability is exploited across the client base.
• Clause 7 — Subcontracting controls: require the supplier to flow equivalent cybersecurity requirements to any downstream sub-processors or sub-contractors. This prevents security gaps opening in multi-tier supply chains without your visibility.
• Clause 8 — Post-contract data obligations: data retrieval and disposal requirements on contract termination, with evidence of secure destruction where applicable.

For further context on supply chain security obligations, see the NIS2 supply chain security guide. For the client-side perspective — how your NIS2-regulated clients classify your RMM tool as their highest-risk supply chain vendor — see the ICT managed services supply chain security article.

Multi-Client Incident Response: Procedure Checklist for MSPs

An MSP serving clients across multiple EU member states faces a reporting challenge that a single-entity NIS2 obligee does not: one infrastructure incident — ransomware deployed via your RMM platform, a supply-chain compromise in your monitoring agent — can simultaneously trigger reporting obligations to multiple national Computer Security Incident Response Teams (CSIRTs), each with its own notification portal and, in some cases, supplementary national forms.

CIR 2024/2690 Article 10 defines when an MSP incident is significant enough to report: the managed service is completely unavailable for more than 30 minutes; the managed service has limited availability affecting more than 5% of its Union users or more than 1 million Union users for more than one hour; or a data compromise affecting confidentiality, integrity, or authenticity where there is reason to believe the cause is malicious. The 24-hour early-warning clock under Article 23 of the NIS2 Directive runs from the moment you become aware that an incident meets — or may meet — one of these thresholds.

For a multi-tenant incident, that awareness moment often arrives before you know the full client-impact scope. The checklists below separate what must be done before any incident and what must be done once one is underway.

Pre-Incident Preparation Checklist — complete before any incident occurs:

• 1. Build a client jurisdiction matrix — for each client that is a registered NIS2 entity: record their member state, the name of their national competent authority, the CSIRT notification portal URL, and any supplementary forms required beyond the CIR minimum. Update this matrix whenever a client registers or changes jurisdiction.
• 2. Pre-draft notification templates per jurisdiction — prepare early-warning notification drafts for each national CSIRT, pre-filled with your organisation’s registration details and the static fields common to all notifications. Leave the incident-specific fields blank to complete within the first hour of detection.
• 3. Define a concurrent notification protocol — establish in advance that when a single incident affects clients in multiple jurisdictions, notifications go out simultaneously, not sequentially. Sequential notification risks the second and third CSIRTs receiving a late early warning that puts your client’s own reporting window at risk.
• 4. Create a significance-threshold decision log — a structured form your on-call team completes within 30 minutes of an incident being flagged. The form asks: Is the service completely unavailable? For how long? What percentage of Union users is affected? Is there evidence of malicious action? Completing this form documents your awareness timestamp and prevents assessment paralysis under time pressure.
• 5. Establish a cross-client confidentiality protocol — define what information about one affected client can be included in notifications that describe a multi-tenant incident. When the root cause involves a vendor-wide vulnerability, the notification must be accurate about shared infrastructure without exposing another client’s identity or data.

During-Incident Procedure Checklist:

• 6. T+0 (detection) — complete the significance-threshold decision log. If thresholds are met or reasonably suspected, activate the notification workflow immediately. Do not wait for full scope confirmation before filing an early warning.
• 7. T+0 to T+24 hours — submit early warnings to all relevant national CSIRTs. Log the exact submission timestamp for each jurisdiction. Inform affected clients that you have filed early warnings and that their own Article 23 reporting obligations may also be triggered.
• 8. T+24 to T+72 hours — submit full incident reports with updated severity assessment, affected infrastructure detail, and preliminary root cause. Update clients whose scope has changed since the early warning was submitted.
• 9. T+1 month — submit the final incident report with the complete incident timeline, confirmed root cause, containment and remediation actions taken, and lessons learned.

See the Article 23 incident notification guide for national CSIRT portal references and the full reporting timeline. For the MSSP-specific incident response framework, see the MSSP incident response guide.

Article 21(2) Security Measures: Implementation Checklist for MSP Environments

Article 21(2) of the NIS2 Directive requires essential and important entities to implement ten categories of cybersecurity risk-management measures as a minimum. For MSPs, each measure applies at two levels: your own organisation’s infrastructure and operations, and — where your contractual scope includes operational responsibility — the client’s managed environment. The checklist below applies each measure to the specific risks of multi-tenant operation.

Art. 21(2) Measure	MSP Implementation Checkpoint
(a) Risk analysis and information security policies	Separate risk assessments for your own infrastructure AND each client’s managed environment. Your risk policy must explicitly address the multi-tenant architecture and the shared-infrastructure risk model.
(b) Incident handling	Incident procedures must distinguish: incidents limited to the MSP’s own systems; incidents propagating into one client environment; incidents propagating across multiple client environments simultaneously. Each scenario has different notification obligations.
(c) Business continuity, backup, disaster recovery	Your tested RTO and RPO must be equal to or better than the SLA commitments made to clients. Misalignment between tested recovery capability and contracted SLAs is both an audit finding and a potential contractual breach.
(d) Supply chain security	Your technology vendors — RMM platform, PSA tool, SIEM, endpoint agent — are your supply chain. Each must be classified by criticality, assessed by risk level, and covered by the CIR Annex 5.1.4 contract clauses described above.
(e) Vulnerability handling and disclosure	Patch cadence for all MSP tooling must be documented and met. Vulnerabilities in your RMM agents carry exceptional severity: a single unpatched agent vulnerability propagates across every connected client environment within your patch window.
(f) Effectiveness assessment	Annual internal audit of security measure effectiveness. For MSSPs: audit scope must include the security monitoring service quality delivered to clients, not only internal controls.
(g) Cyber hygiene and training	Technician training must cover multi-client data handling, cross-tenant access risks, and social engineering techniques targeting IT support staff — who are among the most frequently impersonated roles in vishing and phishing attacks against MSP environments.
(h) Cryptography and encryption	Encryption baseline covers all remote access channels, client data held in backup storage, and inter-tenant data isolation within shared infrastructure. Shared encryption keys across client environments are a single point of failure.
(i) HR security, access control, asset management	Privileged technician credentials must be managed separately per client environment. Shared administrator accounts spanning multiple client tenants are the highest-risk single configuration item in an MSP security posture and are inconsistent with the access control requirements of this measure.
(j) MFA and secure communications	MFA must be enforced on all remote-access pathways into client environments, not only the MSP’s own admin console. Client environments where MFA cannot currently be enforced should be documented as accepted risks with explicit management sign-off and a remediation timeline.

Article 20 of the NIS2 Directive requires management bodies to approve the organisation’s cybersecurity risk-management measures and to be capable of overseeing their implementation. For MSP directors who accept security exceptions — particularly MFA waivers in client environments or documented risk acceptances for unpatched legacy systems — that acceptance should be recorded with explicit risk acceptance language, signed by the management body, and reviewed at minimum annually. Several member states’ national transpositions of Article 20 extend this governance requirement into personal accountability for senior management in cases of persistent non-compliance.

Frequently Asked Questions

Do small MSPs with fewer than 50 employees need to comply with NIS2?

Not as direct NIS2 obligees. The Annex I ICT service management category requires at least medium-enterprise size — 50 employees or €10M annual revenue — for an MSP to be a registered NIS2 entity. However, sub-threshold MSPs serving NIS2-regulated clients will encounter NIS2-derived obligations through client contracts under Article 21(2)(d). The eight CIR Annex 5.1.4 contract clauses described above are the most common requirements a small MSP faces via client MSAs, regardless of whether the MSP itself is a direct NIS2 obligee.

Does the B2B qualifier mean intra-group IT departments are automatically out of scope?

Not automatically. Article 6(39) does not explicitly exclude intra-group providers, and whether an internal IT function providing services across a corporate group constitutes a managed service provider is a question of national transposition law and fact-specific analysis. Several member state implementations treat intra-group providers differently. Do not assume exemption without jurisdiction-specific legal advice.

We serve clients in Germany, France, and the Netherlands. Must we report to all three CSIRTs?

Yes, if a significant incident under CIR Article 10 affects NIS2-registered clients in each member state, you must submit early warnings to each national CSIRT within the 24-hour window. This is separate from each client’s own Article 23 reporting obligation to their competent authority. Pre-establishing notification pathways and templates per jurisdiction before an incident occurs is the only practical way to meet the timeline.

Do these 8 contract clauses make an MSA NIS2-compliant?

No. The CIR Annex 5.1.4 clauses address only the supply chain security dimension — Article 21(2)(d). Full NIS2 compliance for an in-scope MSP requires all ten Article 21(2) security measures, Article 23 incident reporting capability, Article 20 management body governance, and registration with the relevant national competent authority. The contract clauses are one component of a broader compliance programme, not a standalone solution.

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.

Sources

• European Union. Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2 Directive), Articles 3, 6(39), 6(40), 20, 21(2), 23. EUR-Lex. nis-2-directive.com / nis2resources.eu
• European Commission. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, Article 10 and Annex, point 5.1.4. EUR-Lex. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng
• Kemp IT Law. “Navigating NIS 2: a guide to applicability for managed service providers.” kempitlaw.com
• Kemp IT Law. “More flowdown clauses? NIS2 this time.” kempitlaw.com