NIS2 for MSPs: what your clients will ask you to prove

What will NIS2 clients ask their MSP to prove?

Clients in scope of NIS2 must manage the security of their direct suppliers under Article 21(2)(d) of Directive (EU) 2022/2555, and for most of them the MSP is the supplier that matters most. Expect requests for a per-client asset inventory and dependency map, patch and vulnerability status, MFA and access control for your own staff, tested restores, incident notification terms that fit the client's 24-hour clock, your subcontractors, and logs and change records.

Many MSPs are also regulated in their own right: Annex I of the directive lists managed service providers and managed security service providers, and Commission Implementing Regulation (EU) 2024/2690 spells out what they must do.

Are MSPs and MSSPs in scope of NIS2?

Yes, if they meet the size rules. Sector 9 of Annex I, "ICT service management (business-to-business)", names two types of entity: managed service providers and managed security service providers. Annex I is the list of sectors of high criticality, so a large MSP is an essential entity.

Article 6, point (39) 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 other network and information systems, through assistance or active administration, on the customer's premises or remotely. Point (40) defines a managed security service provider as an MSP that carries out or assists with cybersecurity risk management; recital 86 gives incident response, penetration testing, security audits and consultancy as examples.

The definition is wide. Remote monitoring and management, managed cloud, managed networks and co-managed IT can all fit when sold to businesses. The useful check is whether you install, manage, operate or maintain a client's systems.

Which MSPs are caught by the NIS2 size cap?

Article 2(1) applies NIS2 to entities of an Annex I or II type that are at least medium-sized under Commission Recommendation 2003/361/EC. A business stops being small once it has 50 or more staff, or once both its annual turnover and its balance sheet total exceed €10 million. Micro and small MSPs are generally outside the directive.

Above the medium-sized ceilings (250 or more staff, or turnover above €50 million and balance sheet total above €43 million) an MSP is an essential entity; a medium-sized MSP is an important entity (Article 3). Both carry the same Article 21 and Article 23 duties, but important entities are supervised ex post, when there is evidence or an indication of non-compliance (Article 33).

Four details matter for MSPs:

• Groups count. Under the Recommendation, linked enterprises' figures are added in full and partner enterprises' in proportion to the holding, so an MSP inside a larger group can be in scope even when its own figures are small. Recital 16 lets Member States weigh how independent its systems and services are.
• Size is not the sole route in. Under Article 2(2), a Member State can bring in a smaller entity, for example the sole provider in that country of a service essential for critical societal or economic activities.
• One regulator. MSPs and MSSPs fall under the Member State of their main establishment in the EU, where cybersecurity risk-management decisions are predominantly taken (Article 26), and must register their details, including the Member States they serve and their IP ranges (Article 27). ENISA keeps an EU-wide registry.
• Fines. National law must allow fines of up to at least €10 million or 2% of worldwide annual turnover for essential entities, and up to at least €7 million or 1.4% for important entities, whichever is higher (Article 34).

What does Implementing Regulation (EU) 2024/2690 require of an MSP?

For most sectors, national law fills in the detail of Article 21. For MSPs, MSSPs and other digital providers, the Commission set that detail once for the whole EU, as Article 21(5) required. Implementing Regulation (EU) 2024/2690 was adopted on 17 October 2024, entered into force on 7 November 2024 and applies directly in every Member State, with no national transposition.

Its Annex turns each of the ten Article 21(2) measures into specific requirements, drawing on ISO/IEC 27001 and ISO/IEC 27002, from logging and backups to patching, access control with MFA and asset inventory. Where a requirement applies "where appropriate" and you decide it does not fit, Article 2(2) requires you to document your reasoning.

ENISA's NIS2 Technical Implementation Guidance (version 1.0, June 2025) follows the Annex point by point, with guidance and examples of evidence for each requirement. It is not legally binding, but it is a sensible checklist when a client or its auditor asks what good looks like.

When is an incident at an MSP significant under NIS2?

The regulation also defines when an incident at an MSP or MSSP is significant, which starts the Article 23 reporting clock: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report no later than one month after the notification.

The bar is low. Scheduled maintenance does not count (Article 3(2)), but incidents that recur at least twice in six months with the same apparent root cause count as one significant incident if together they meet the financial-loss threshold (Article 4). Under Articles 3 and 10, an incident is significant if, among other criteria:

• a managed service or managed security service is completely unavailable for more than 30 minutes;
• availability is limited for more than 5% of the service's users in the EU, or more than 1 million of them, whichever is smaller, for more than one hour;
• the integrity, confidentiality or authenticity of data related to the service is compromised as a result of a suspectedly malicious action;
• a successful, suspectedly malicious and unauthorised access to network and information systems occurs that is capable of causing severe operational disruption;
• it causes, or could cause, direct financial loss above €500,000 or 5% of annual turnover, whichever is lower.

Why will your clients push NIS2 questions down to you?

Because the directive makes them responsible for you. Article 21(2)(d) requires supply chain security, including each entity's relationship with its direct suppliers and service providers, and Article 21(3) requires entities to take into account each supplier's specific vulnerabilities and cybersecurity practices.

Recital 85 encourages entities to write cybersecurity measures into contracts with direct suppliers. Recital 86 notes that MSSPs have themselves been targets of cyberattacks and, being closely integrated into their clients' operations, pose a particular risk. Article 20 makes the client's management body approve and oversee these measures, and it can be held liable for failures.

ENISA's guidance is plain that the entity remains fully accountable for the services its suppliers provide, so the client has to show its regulator or auditor that it checked you. Point 5.1.4 of the regulation's Annex lists what supplier contracts should cover where appropriate, including incident notification without undue delay, a right to audit or to receive audit reports, vulnerability handling, subcontracting rules and exit obligations. Expect client questionnaires to follow that list; our guide to NIS2 supply chain security covers the client side.

What evidence will clients and auditors ask an MSP for?

Prepare for these requests, each listed with the reason it is asked. Point references are to the Annex of Implementing Regulation 2024/2690. A 2022 joint advisory on protecting MSPs and their customers, from CISA, the UK NCSC and partner agencies, recommends much the same basics.

• Asset inventory per client: the devices, cloud accounts, applications, identities and licences you manage for them. Point 12.4 requires a complete, accurate, up-to-date inventory with changes recorded in a traceable way, and a client cannot meet its own asset management duty for systems only you can see.
• Dependency map of the services you run: which client services rely on which of your platforms, tools and people, and what fails if one of them fails. Point 12.4.2 asks for the list of services and the systems supporting them, and ENISA suggests recording each asset's relation to other assets. Clients need this for business continuity under Article 21(2)(c).
• Patch and vulnerability status per client, with documented reasons where a patch was deferred. Point 6.6 requires security patches within a reasonable time and a written justification when one is not applied.
• Access control and MFA for your staff: who at your company can reach each client, with what privileges, and how they authenticate. Points 11.3 and 11.7 require strong authentication such as MFA for privileged and administration accounts, and regular reviews of those rights. Your admin accounts are a direct route into your clients' systems.
• Backups and tested restores. Point 4.2.6 requires regular recovery testing with documented results, so a backup job report is not enough on its own.
• Incident notification commitments: how fast, through which channel and with what information you will tell the client about an incident affecting them. The client's 24-hour early warning runs from when it becomes aware, so if you detect the incident, your delay comes out of its window. Point 5.1.4(d) makes prompt supplier notification a contract term.
• Subcontractors: the cloud platforms, RMM and PSA vendors, offshore teams and security partners behind the client's service. Point 5.1.4(g) covers subcontracting, and point 5.2 expects a directory of direct suppliers.
• Logs and change records: who did what on client systems, especially privileged actions, and each change with its approval. Point 3.2 lists privileged access and changes to critical configuration among the events to log, and point 6.4 requires changes to be documented, tested and assessed before they are made.
• Audit rights and reports. Point 5.1.4(e) names the right to audit or to receive audit reports, so expect requests for ISO/IEC 27001 certificates, SOC 2 reports or access for the client's auditor.

How can an MSP answer these questions without a spreadsheet per client?

The usual answer is a questionnaire per client, filled in from memory and a shared drive, and out of date within weeks. It does not scale past a handful of regulated clients, and the inventory and dependency answers go stale fastest. Four changes make it manageable, and they are what Alexus AI for MSPs is built around:

• A live map per client, built from the tools that already hold the facts (cloud accounts, monitoring, ITSM and ticketing, RMM) and kept current automatically, so "what do you run for us and what depends on it?" is a query, not a project.
• Evidence per client from operational data: patch status, MFA coverage, restore tests, incidents and changes recorded as the work happens and filtered per client, not assembled for an audit.
• Hard tenant isolation, enforced in the database and not only in application code, with separate credentials per client. Evidence for one client must never expose another, and isolation also answers the client's question about your own blast radius.
• Standard contract clauses offered to every regulated client: a notification time well inside 24 hours, named channels and contacts, the content of your first notice, a subcontractor list with change notice, audit rights, and exit and data return terms, each mapped to point 5.1.4.

What should an MSP do in the first 90 days of NIS2 work?

A practical order of work:

• Days 1 to 30: confirm your own status. Check your size including linked and partner enterprises, identify your main establishment, register with the national authority if you are in scope, and list which clients are essential or important entities. Enforce MFA on every privileged and remote-access account now.
• Days 31 to 60: build the per-client picture. Stand up an inventory and dependency map for each regulated client, record patch status, MFA coverage and changes per client, and run a gap check against the regulation's Annex using the ENISA guidance. Write an incident classification runbook from the Article 10 thresholds, with the client notification steps.
• Days 61 to 90: make it repeatable. Update your contract template against point 5.1.4, run and record a restore test for each regulated client, produce a standard evidence pack per client, and, if you are in scope, brief your management body, which Article 20 requires to approve the measures and to follow cybersecurity training.

How Alexus AI helps

Alexus AI is a Dublin-built operational intelligence platform. For MSPs it keeps a live, self-maintaining service and dependency map for every client in one multi-client console, built from read-only connectors to the cloud, monitoring, ITSM and code tools you run, with your RMM and PSA connected through a framework we adapt during onboarding. Each client is isolated in the database with row-level security, plus a scope check on every request, and pricing is per managed client rather than per seat.

The same data produces NIS2 evidence per client: readiness scored against all ten Article 21 measures, an Article 23 clock with drafts of the early warning, notification and final report that a person reviews and submits, and a hash-chained audit trail that can be verified on demand. Alexus is EU-hosted. DORA and SOC 2 specific outputs are planned, not available today. Alexus does not make you or your clients compliant; it provides the operational evidence. See Alexus for MSPs, the NIS2 evidence and pricing.

This guide is general guidance, not legal advice.

Frequently asked questions

Is every MSP covered by NIS2?

No. NIS2 covers managed service providers and managed security service providers that are at least medium-sized under Commission Recommendation 2003/361/EC: broadly 50 or more staff, or annual turnover and balance sheet total both above €10 million, counting linked and partner enterprises. Large MSPs are essential entities and medium-sized ones are important entities. Smaller MSPs are generally out of scope unless a Member State designates them under Article 2(2), but in-scope clients will still ask them for supply chain evidence.

What is Implementing Regulation (EU) 2024/2690?

It is the European Commission act, adopted on 17 October 2024 and in force since 7 November 2024, that sets EU-wide technical and methodological requirements for the ten NIS2 Article 21 measures for MSPs, MSSPs, cloud, data centre and other digital providers. It also defines when their incidents are significant, for example a managed service being completely unavailable for more than 30 minutes. As a regulation it applies directly, without national transposition.

How quickly must an MSP tell a client about an incident?

NIS2 does not set a fixed number of hours for suppliers. The Annex of Implementing Regulation 2024/2690 expects supplier contracts to require notification without undue delay, and the client's own 24-hour early warning runs from when it becomes aware of a significant incident. A sensible clause commits to a set number of hours well inside 24, with named contacts and a defined first notice. An in-scope MSP must also notify affected clients itself under Article 23(1) where appropriate.

Which country regulates an MSP that serves clients across the EU?

Under Article 26 of NIS2, MSPs and MSSPs fall under the Member State where they have their main establishment in the EU. That is where cybersecurity risk-management decisions are predominantly taken; failing that, where cybersecurity operations are carried out; failing that, where the MSP has the most employees in the EU. An MSP not established in the EU but offering services there must designate a representative in one of the Member States it serves.

Can an MSP's tooling make a client NIS2 compliant?

No tool makes an organisation compliant. NIS2 expects policies, processes, management accountability and proof that they work. Tooling can produce the operational evidence: an up-to-date inventory and dependency map, patch and access records, incident timelines and change history, per client. The client's policies, risk assessments and board decisions stay with the client, and the client remains accountable for the security of its suppliers.

Sources

• Directive (EU) 2022/2555 (NIS2), EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690, EUR-Lex
• ENISA, NIS2 Technical Implementation Guidance (June 2025, version 1.0)
• Commission Recommendation 2003/361/EC on the definition of SMEs, EUR-Lex
• European Commission, NIS2 Directive policy page
• CISA, NCSC-UK and partner agencies, Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A)