NIS2 for Managed Service Providers: What Makes an Incident Significant Enough to Report

For managed service providers (MSPs) and managed security service providers (MSSPs) in scope of NIS2, Commission Implementing Regulation (EU) 2024/2690 turns "significant incident" into concrete tests. An incident is significant if, among other criteria, a managed service is completely unavailable for more than 30 minutes, its availability is limited for more than 5% of its EU users or more than 1 million EU users (whichever is smaller) for over one hour, service data is compromised by a suspectedly malicious action, or the incident causes or could cause direct financial loss above EUR 500,000 or 5% of annual turnover, whichever is lower. Meeting any one criterion triggers the 24-hour early warning.

Are you an MSP under NIS2?

Article 6 of Directive (EU) 2022/2555 defines a managed service provider as 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". A managed security service provider is an MSP that "carries out or provides assistance for activities relating to cybersecurity risk management". Both sit in Annex I under "ICT service management (business-to-business)".

The general size cap applies: MSPs are in scope if they are at least medium-sized under Recommendation 2003/361/EC, unless a Member State identifies a smaller one under Article 2(2). For a US MSP, two more points matter. Jurisdiction follows your main establishment in the EU (Article 26(1)(b)), meaning the Member State where cybersecurity risk-management decisions are predominantly taken. And if you offer services in the EU without an establishment there, you must designate an EU representative (Article 26(3)).

The MSP-specific criteria (Article 10)

Article 10 of the Implementing Regulation says an incident affecting an MSP or MSSP is significant where it meets one or more of the following:

Note the asymmetry between (c) and (d): a data compromise caused by a suspectedly malicious action is significant whatever the number of users affected, while an accidental compromise, a misconfiguration for example, becomes significant only above the user threshold.

Working the 5% / 1 million rule

"Whichever is smaller" means that for almost every MSP the 5% figure governs. If your remote monitoring service has 40,000 users in the EU, 5% is 2,000 users, far below 1 million, so limited availability affecting more than 2,000 EU users for over an hour is significant. The 1 million ceiling only bites for services with more than 20 million EU users (because 5% of 20 million is 1 million).

Count users the way Article 3(3) requires: both customers that have a contract with you granting access to the service, and "natural and legal persons associated with business customers" that use it. For a B2B MSP, that means the end users at your client companies, not just the number of client contracts. Recital 32 adds that if you cannot calculate the number, you use your estimate of the possible maximum number of affected users.

The general criteria that apply to every MSP incident

Article 10 sits inside a broader test. Under Article 3(1), an incident is also significant where any of the following applies, whatever the service type:

• it has caused or is capable of causing direct financial loss for the entity above EUR 500,000 or 5% of total annual turnover in the preceding financial year, whichever is lower;
• it has caused or is capable of causing the exfiltration of trade secrets of the entity;
• it has caused or is capable of causing death or considerable damage to a person's health;
• a successful, suspectedly malicious and unauthorized access to network and information systems occurred that is capable of causing severe operational disruption;
• it meets the recurring incidents test of Article 4.

Worked example. An MSP with EUR 6 million turnover: 5% is EUR 300,000, which is lower than EUR 500,000, so EUR 300,000 is its financial-loss threshold. An MSP with EUR 40 million turnover: 5% is EUR 2 million, so the EUR 500,000 figure applies.

Measuring downtime and losses: what counts and what doesn't

• Scheduled maintenance is excluded. Under Article 3(2), "scheduled interruptions of service and planned consequences of scheduled maintenance operations" are not significant incidents. Recital 33 extends this to interruptions under pre-determined contractual agreements.
• Duration runs from disruption of proper service until recovery. If you cannot tell when it began, measure from detection or from the earliest log record, whichever is earlier (recital 34).
• Complete unavailability runs until service is restored to the pre-incident level (recital 35).
• Limited availability includes a service that is "considerably slower than average response time" or missing some functionalities (recital 38).
• Direct financial loss includes replacement of hardware or software, staff and overtime costs, contractual penalties, customer redress, forgone revenue, communication, legal, forensic and remediation costs. It excludes administrative fines, insurance premiums, routine maintenance and post-incident upgrades (recital 36). Estimate when exact amounts are unknown.

Recurring incidents: the quarterly check

Small incidents can add up. Under Article 4, incidents that individually are not significant count collectively as one significant incident where they have occurred at least twice within 6 months, have the same apparent root cause, and together meet the financial-loss criterion above. Point 3.4.2(b) of the Regulation's Annex requires relevant entities to assess the existence of recurring incidents "on a quarterly basis". ENISA's June 2025 implementation guidance notes that the root cause may be hard to determine early on, so that assessment may be delayed; build a quarterly root-cause review into your problem-management process.

A decision flow for your NOC and SOC

1. Is it planned maintenance or a contractual scheduled interruption? If yes, stop.
2. Was there suspectedly malicious unauthorized access capable of severe disruption, or a malicious data compromise? If yes, significant.
3. Did a managed service go fully down for more than 30 minutes? If yes, significant.
4. Was availability limited for more than one hour for more than 5% of EU users (or 1 million, if smaller)? If yes, significant.
5. Could direct losses exceed EUR 500,000 or 5% of turnover, whichever is lower? Any trade secret exfiltration or harm to health? If yes, significant.
6. If none applies, log it, link it to a root cause and check it in the quarterly recurring-incident review.

Once significant, the Article 23 clock runs: early warning within 24 hours of becoming aware, notification within 72 hours, final report one month after the notification. Recital 31 of the Implementing Regulation treats you as aware when, after a timely initial assessment, you have "a reasonable degree of certainty" that a significant incident occurred. Customers may also need to be told: Article 23(1) requires notifying service recipients, where appropriate, of significant incidents likely to affect the service.

Why your customers will ask about this

Your in-scope customers must manage supply chain risk under Article 21(2)(d), and recital 86 of NIS2 notes that MSSPs "have however also themselves been the target of cyberattacks" and calls for "increased diligence in selecting a managed security service provider". ENISA's 2023 supply chain good-practice report, based on a 2022 study, found that 86% of surveyed organizations had ICT/OT supply chain cybersecurity policies but only 47% allocated budget to it and only 24% had dedicated roles. Expect questionnaires to become more specific. You can test edge cases against the source text in the NIS2 knowledge base, for example "As a managed service provider, what makes an incident significant enough that we must report it?"

The thresholds above come from Implementing Regulation (EU) 2024/2690 on EUR-Lex, published on 18 October 2024. National authorities may issue their own guidance; this article is an explanation of the text, not legal advice.