Security Incident at a Service Provider: Who Reports to the BSI?

Written by the NIS2Compass editorial team | Last updated: August 2026

If a security incident happens at your cloud provider or MSP, the provider does not report to the BSI on your behalf. Every affected NIS2 entity reports for itself, based on its own significance assessment and its own 24-hour deadline from the time it becomes aware. The free NIS2Compass Pre-Check helps determine in under five minutes whether your organisation is within scope.

Who must report when the incident happens at a service provider?

The affected entity reports. Section 32 (1) BSIG addresses reporting duties to entities of particular importance and important entities. The fact that the root cause sits with a service provider does not remove the customer's duty to assess its own exposure. A cloud provider's or MSP's report about its own incident does not replace yours.

A supply-chain incident can therefore produce several reporting procedures in parallel: one for the provider and one for each affected NIS2 customer. Every entity assesses the effects on its own services and runs its own deadline. The BSI's NIS-2 figures show 692 early initial reports and 1,659 NIS-2 reports in total as of 30 June 2026.

This article covers three common situations:

1. Your cloud provider is compromised and your services or data may be affected.
2. You are an MSP or IT service provider and need to manage both your own incident and customer communications.
3. You are a supplier outside NIS2 scope but have agreed to a contractual 24-hour notification deadline.

For the underlying stages and deadlines, see NIS2Compass's guide to NIS2 reporting duties. The focus here is the additional service-provider perspective.

Your cloud provider is compromised: must you report to the BSI yourself?

Yes, if the incident causes a significant security incident for you as an important entity or an entity of particular importance, for example because your services fail or your data is affected. Your cloud provider reports its own incident. Your 24-hour deadline for the early initial report starts from your own awareness of the incident.

A cloud provider is listed as a cloud-computing service provider in Annex 1 BSIG. Even so, the customer independently assesses whether the incident is significant for that customer. Under Section 2 no. 11 BSIG, the question is whether the incident causes or may cause serious operational disruption or financial loss to the entity concerned, or substantial harm to others. The reference point is your services and your loss, not the provider's.

The numerical thresholds in Implementing Regulation (EU) 2024/2690 apply to the specified digital-infrastructure providers when they assess their own incidents. For customers outside those categories, the general BSIG definition is decisive. The article on significant security incidents explains that assessment in more detail.

The statute does not define the moment of awareness in more detail. Your reporting process should therefore specify when the responsible team can classify a provider incident as potentially significant for your own services. This will often be a qualified provider notification or your own detection of disruption. If you first learn about an incident through the media, actively assess whether you are affected.

Cloud outages are not a marginal risk. According to Bitkom, 46% of companies would eventually have to stop operations during a cloud outage, while 28% of cloud users experienced a serious outage within the previous 12 months. If personal data is involved, assess a separate notification under Article 33 GDPR as well. It is independent of the BSI report.

You are an MSP or IT service provider: what reporting duties apply to you?

Managed Service Providers can be in scope for NIS2 themselves. Annex 1 BSIG lists both “Managed Services Provider” and “Managed Security Services Provider” in the Digital Infrastructure sector. The decisive factors are the service actually provided and the size thresholds, not whether the business calls itself a system house or IT service provider.

Under Section 2 no. 26 BSIG, an MSP provides services connected with installing, managing, operating or maintaining ICT products, networks, infrastructure, applications or other network and information systems. That commonly includes remote support, central administration and managed security services. Listed entities generally qualify as important entities from 50 employees or where annual turnover and annual balance-sheet total each exceed EUR 10 million. Entities of particular importance generally start at 250 employees or turnover above EUR 50 million and a balance-sheet total above EUR 43 million; see Section 28 BSIG.

An attack on your remote-access environment, central management systems or RMM tools is your own incident. Section 32 BSIG requires an early initial report within 24 hours for significant incidents, a report within 72 hours, interim reports when requested, and a final report no later than one month after the report. Sample texts for NIS2 reports help prepare the required information.

As an MSP, you wear two hats. You assess and report your own incident, while also supplying the information customers need to assess theirs. Every affected customer performs its own significance assessment; your report does not complete a customer's report. The NIS2Compass Pre-Check gives a structured first assessment of whether your organisation falls in scope.

How should a service provider inform customers so that their deadlines remain realistic?

Your customer's deadline is based on that customer's own awareness. A quick, reliable incident notice gives the customer a basis for assessment. Information that arrives late, remains generic, or goes only to a sales contact increases the risk of a late report by the customer.

The BSIG does not create a general duty to notify every customer about every incident. Section 35 (1) BSIG allows the BSI to order the notification of recipients of an impaired service. For specified sectors, Section 35 (2) also creates a notification duty for significant cyber threats. Independently of that, many customers agree specific notification channels contractually, because Section 30 (2) no. 4 BSIG expressly names supply-chain security as a risk-management measure. Sample wording and a checklist for exactly these clauses are available in the free Incident Reporting Clauses for Service-Provider Contracts template (Word).

A reliable initial notice should include at least:

• Timing: when the incident was detected, when it could be assessed, and when the customer is being notified.
• Exposure: which services, systems, access paths, or data may be affected for that specific customer.
• Impact: current disruption and what is still unknown.
• Immediate action: containment measures already underway and actions recommended to the customer.
• Contact and updates: a reachable contact outside normal business hours and a time for the next update.

This is not a complete forensic report. It is enough to let the customer decide whether an early initial report is needed. Do not wait for the investigation to finish. The NIS2 Guide helps establish responsibilities, communications channels and reporting stages before an incident occurs. Bitkom reports that 68% of cloud users have contractual arrangements with providers for outages; the remaining 32% should review this in supplier management.

What applies to suppliers outside NIS2 scope with a contractual 24-hour deadline?

A supplier outside NIS2 scope does not become a reporting entity merely because a contract contains a 24-hour notification deadline. The clause creates a duty to the customer, not a statutory duty to the BSI. Its purpose is to give the customer time for its own legal assessment and, where appropriate, an early initial report.

In practice, the clause still requires sound capabilities. You need a notification path that detects incidents promptly, assesses them internally and sends information to the agreed security or emergency contact. Keep timestamps for detection, assessment and customer notification. The incident logbook also helps organisations outside NIS2 scope document these actions in a traceable way.

Contractual penalties or damages may result from a missed deadline, but depend on the individual contract. Have clauses reviewed legally. A voluntary notification to the BSI's general reporting point is still possible under Section 5 (2) BSIG, including anonymously. It is distinct from the mandatory reporting route under Section 32 BSIG.

Supply-chain risk is practical, not theoretical. According to Bitkom, 9% of companies know of attacks on their suppliers and another 19% suspect one. Of those companies, 41% experienced effects themselves. Bitkom President Dr Ralf Wintergerst warns that attackers seek the weakest link, which can be a less well-protected supplier even where the customer itself has strong safeguards.

What does the real incident look like: ransomware at an MSP?

An incident at a service provider can trigger several separate reporting procedures. This example shows two independent deadlines. Ransomware hits a system house with 55 employees; its responsible team assesses the case at 08:30 on Saturday. An affected customer receives a qualified notice at 10:00.

The starting point is an MSP with a compromised remote-access connection. Its on-call team isolates affected systems on Friday evening. At 08:30 on Saturday, the information security officer can classify the incident as potentially significant. The MSP's deadline for its early initial report starts then. At 10:00, the MSP informs potentially affected customers about timing, systems, initial impact and a contact person.

A manufacturing company with 180 employees assesses its own exposure from 10:00. If the assessment identifies a significant security incident, its own 24-hour deadline runs independently of the MSP's. Another customer outside NIS2 scope does not report to the BSI, but may still have a contractual duty to inform its own customer.

The MSP and affected customers then continue their reporting stages separately. Sample report texts and the article on what happens after reporting to the BSI support the next steps. Bitkom found that 34% of companies had suffered ransomware attacks causing damage in 2025, so this scenario is not an abstract edge case.

Frequently Asked Questions

Does my cloud provider report a security incident to the BSI for me?

No. The cloud provider reports its own incident. If your services or data are affected and you are an important entity or an entity of particular importance, assess the significance for your organisation and report under Section 32 BSIG where necessary. Your deadline depends on your own awareness.

When does my 24-hour deadline start if the incident happened at a service provider?

Section 32 BSIG ties the deadline to your awareness. In practice, document when the responsible team can classify the incident as potentially significant for your own services. This may follow a qualified provider notice or your own detection of disruption.

Are MSPs and IT system houses themselves in scope for NIS2?

That depends on their activity and size. Annex 1 BSIG names Managed Service Providers and Managed Security Service Providers in the Digital Infrastructure sector. The general thresholds and exclusions follow from Section 28 BSIG. The NIS2Compass Pre-Check provides a structured first assessment.

Must a supplier outside NIS2 scope report to the BSI because of a contract clause?

No. A contractual 24-hour deadline creates a notification duty to the customer, not the statutory reporting duty under Section 32 BSIG. The customer needs the information to assess its own situation. Voluntary reports to the general reporting point remain a separate option.

What information should a provider incident report contain?

You need at least timing, affected services and systems per customer, an initial impact assessment, containment steps underway, a reachable contact and a time for the next update. Complete forensics are not required at that point, but a reliable initial notice is.

Sources

• Sections 2, 5, 28, 30, 32 and 35 BSIG
• Annex 1 BSIG
• BSI: NIS-2 in figures, 30 June 2026
• Bitkom: Cloud outage would paralyse almost every second company, 3 July 2026
• Bitkom: Attackers target suppliers, 7 November 2025
• Bitkom: Russia and China target the German economy, 18 September 2025