NIS2 for Managed Service Providers: When an Outage or Breach Becomes a Reportable Significant Incident

If you are a managed service provider (MSP) or managed security service provider (MSSP) in scope of NIS2, an incident is "significant", and must be reported within 24 hours of awareness, when it meets any one of the criteria in Commission Implementing Regulation (EU) 2024/2690. For MSPs the headline tests are: complete unavailability for more than 30 minutes; limited availability for more than one hour affecting more than 5% of EU users or 1 million, whichever is smaller; data compromised by a suspectedly malicious action; and direct financial loss above EUR 500,000 or 5% of turnover, whichever is lower. Below, five scenarios show how the tests play out.

Does the regime reach a UK MSP?

Directive (EU) 2022/2555 is EU law, and nothing in this article concerns UK domestic rules, which are outside the sources of the NIS2 knowledge base. It can nonetheless apply to a UK-headquartered MSP in two ways: through an EU subsidiary or establishment providing managed services, or by offering managed services into the EU from the UK.

• Sector. Managed service providers and managed security service providers are listed in Annex I under "ICT service management (business-to-business)". The directive's definition covers installation, management, operation or maintenance of ICT products, networks, infrastructure or applications, "either on customers' premises or remotely".
• Size. MSPs are subject to the standard size cap: medium-sized enterprises and above under Recommendation 2003/361/EC, with group figures aggregated for linked and partner enterprises. They are not among the categories covered regardless of size, though a Member State may identify a smaller entity under Article 2(2).
• Jurisdiction. MSPs fall under the Member State of their main establishment in the Union (Article 26(1)(b)). Without any EU establishment, a UK MSP offering services in the EU must designate a representative established in a Member State where it offers services, and falls under that Member State's jurisdiction (Article 26(3)).
• Registration. The Article 27 registry categories, which include MSPs and MSSPs, had to submit their details, including IP ranges and EU establishments or representative, by 17 January 2025, and must report changes within three months.

The tests in one table

Users are counted under Article 3(3): customers with a contract granting access to the service, plus the natural and legal persons associated with business customers who use it. In other words, the staff of your client organisations count, not just your client list. If you cannot calculate the figure, recital 32 says to use your estimate of the possible maximum number of affected users.

Five scenarios

1. The 40-minute RMM outage

Your remote monitoring and management platform is fully down for 40 minutes after a failed certificate rotation. Complete unavailability exceeded 30 minutes, so Article 10(a) is met: significant, whatever the number of users. Recital 34 says to measure duration from the disruption of proper service to recovery or, if the start is unknown, from detection or the earliest log record, whichever is earlier.

2. The slow helpdesk portal

Your ticketing portal, used by 30,000 people at EU clients, runs considerably slower than its average response time for 90 minutes, affecting about 1,200 users. Recital 38 treats a service that is "considerably slower than average response time" as limited availability. The threshold is 5% of 30,000, so 1,500 users (smaller than 1 million). With 1,200 affected, Article 10(b) is not met. Check the other criteria, then log it for the recurring-incident review.

3. A misconfigured backup bucket

A configuration error exposes backup data for one client with 300 users, out of 30,000 EU users in total, with no sign of malicious access. Article 10(c) requires a suspectedly malicious action, so it does not apply; Article 10(d) requires more than 1,500 users here, so it does not apply either. Unless the financial-loss or another general criterion is met, this is not significant under NIS2, but personal data rules may still apply, and the GDPR is outside the base's scope.

4. Stolen administrator credentials

An attacker logs into your privileged access tooling with stolen credentials and sits quietly. Recital 39 of the Implementing Regulation gives exactly this case: a threat actor that "pre-positions itself" with a view to future disruption makes the incident significant. Article 3(1)(e) is met: significant, even without an outage.

5. Three small ransomware hits in five months

Three contained infections at client sites, each traced to the same unpatched remote-access appliance, cost you EUR 90,000, EUR 120,000 and EUR 150,000. Your turnover is EUR 12 million, so 5% is EUR 600,000 and the lower figure, EUR 500,000, is the threshold. Individually none exceeds it; together they total EUR 360,000 (90,000 + 120,000 + 150,000), still below. Article 4 is not met yet, but a fourth incident costing more than EUR 140,000 within the six-month window would take the total above EUR 500,000 (360,000 + 140,000 = 500,000).

What counts as loss, and what is excluded

Recital 36 lists what goes into direct financial loss and what stays out:

• Included: replacement or relocation of software, hardware or infrastructure; staff costs including overtime and extra recruitment; fees for non-compliance with contractual obligations; redress and compensation to customers; forgone revenue; internal and external communication; legal, forensic and remediation advice.
• Excluded: administrative fines; day-to-day running costs such as general maintenance and staff training; upgrades and improvements after the incident; insurance premiums.
• Unknown amounts: estimate them from available data.

Operational requirements behind the thresholds

The same Implementing Regulation sets technical requirements that make the tests workable. Its Annex requires relevant entities to monitor and log activity, including privileged access and authentication events (point 3.2), to provide a simple mechanism for employees, suppliers and customers to report suspicious events (point 3.3), to assess events against predefined criteria and check for recurring incidents quarterly (point 3.4), and to carry out post-incident reviews (point 3.6). ENISA's June 2025 technical guidance adds practical tips, such as using SIEM or EDR/XDR tools to correlate data and playbooks for common incident types.

Once an incident is significant, the Article 23 sequence applies: early warning within 24 hours of awareness, incident notification within 72 hours, final report one month after the notification, and, where appropriate, notice to affected service recipients. Your customers will also be watching: recital 86 of NIS2 notes that MSSPs have themselves been targeted and calls for "increased diligence" when selecting them.

Read the full criteria in Implementing Regulation (EU) 2024/2690 and check guidance from the competent authority of your main EU establishment. These scenarios illustrate the text; they are not legal advice on a specific incident.