NIS2 Supply Chain Attack: Your Vendor Was Breached — Do You Have 24 Hours to Report?

In May 2025 the external service provider of Berliner Verkehrsbetriebe was targeted, affecting the data of 180,000 BVG customers. ENISA records the same pattern twice more in the same reporting year: Plus Service, which managed the Telemaco platform for multiple Italian transport companies, and a provider whose compromise reached customers of the Spanish energy company Repsol [1]. In each case the compromise happened at the provider. The regulated entity still had to decide what it owed.

Almost every NIS2 supply chain guide stops at prevention. This one starts at 09:00 on the morning a vendor emails to say they have been compromised: whether the 24-hour clock is now running against you, and what you owe if it is not.

A Supplier Breach Fires Up to Three Separate Obligations

In plain terms: your supplier’s incident is not automatically your incident, but it is always your problem. NIS2 attaches obligations to the systems you rely on, not to the company that happens to own them.

Article 21(1) of Directive (EU) 2022/2555 requires measures managing risks to systems which those entities use for their operations or for the provision of their services [2]. Ownership is not the test; use is. Germany’s BSI puts it in one sentence: even where IT is completely outsourced, you as an important or particularly important entity remain responsible yourself [3]. Hence NIS2 supply chain security sits among the risk-management measures, not in procurement.

When the vendor calls, up to three obligations activate on three different triggers. Treating them as one is the common failure — teams either file nothing because the incident was not "theirs", or file everything and still miss the duty that had nothing to do with reporting.

Obligation	Legal basis	Fires when	Clock
Report to your CSIRT or competent authority	Article 23(1) and (4)	Only if the incident is significant for your services	24h / 72h / one month
Tell your own service recipients	Article 23(1), second sentence, and 23(2)	Where appropriate, if your service provision is likely to be adversely affected	Without undue delay
Re-assess the supplier and document it	Article 21(2)(d); CIR 2024/2690 Annex 5.1.6 and 5.1.7	Always — the supplier incident itself is the trigger	No deadline, but it is auditable

Recital 85 explains the design: attackers compromise an entity’s systems by exploiting vulnerabilities in third-party products and services. Recital 86 singles out managed security service providers — themselves targets, and, through close integration in clients’ operations, a particular risk worth weighing before outsourcing security operations to an MSSP [2]. Recitals bind nobody, but they show how a supervisor reads Article 21(2)(d).

Step 1: Assess Your Impact, Not Your Vendor’s

The vendor’s severity rating is theirs. It has no standing in your file, and adopting it is the fastest way to get the next three steps wrong.

Article 23(3) is written from your side of the relationship: an incident is significant where it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or has affected or is capable of affecting other persons by causing considerable material or non-material damage. Recital 101 confirms the call is yours, "based on an initial assessment carried out by the entity concerned", weighing the affected systems and their importance in providing the entity’s services [2].

Belgium’s Centre for Cybersecurity (CCB), both national CSIRT and receiving authority, puts the scoping rule more bluntly. Version 1.2 of its NIS2 Notification Guide states that mandatory notifications "only concern the networks and information systems on which the entity concerned depends to provide the service(s) listed in the annexes of the law", and that an incident affecting only an isolated system unrelated to those services does not have to be notified [4]. That is one national authority’s reading, phrased differently elsewhere — but it follows from Article 23(1), which speaks of impact "on the provision of their services".

The first question is therefore not how bad the breach was, but which of your services the compromised component sits behind.

What the vendor tells you	What you check on your side	Typical answer
Their corporate email or CRM; no product systems touched	Whether your regulated-service data or credentials sat in that system	Usually outside reporting scope — still triggers the Step 5 duty
A remote-access or RMM tool they use on your estate	Session logs, privileged account use, lateral movement from their jump host	Frequently in scope; treat as suspected unauthorised access until disproved
A software build or update channel you consume	Which versions you deployed, where, and whether they sit behind a listed service	In scope if the affected build supports a service in Annex I or II
Their hosting or data-centre availability failed	Whether the outage degrades a service you provide, and for how long	Assess against the operational-disruption limb, not confidentiality

Step 2: When the 24-Hour Clock Actually Starts

Article 23(4)(a) requires an early warning within 24 hours of becoming aware of the significant incident [2]. The word doing the work is "aware", and it does not mean the moment the vendor’s email arrived.

The CCB addresses exactly this, expressly covering the case where someone else brings the incident to you. Where a potential incident has been brought to an entity’s attention by a third party — a customer, an authority, a media organisation or another source — it should assess that event in a timely manner to determine whether it constitutes an incident and, if so, its nature and severity. The entity is then "to be regarded as having become ‘aware’ of the significant incident when, after such initial assessment, that entity has a reasonable degree of certainty that a significant incident has occurred" [4]. Recital 102 balances it from the other side: reporting should not divert the entity’s resources away from incident handling [2].

So the vendor’s notification opens an assessment; reasonable certainty closes it and starts the 24 hours. The trap is the mirror image — "timely" is not "whenever we get to it", and an assessment with no start time, no criteria and no written conclusion is indistinguishable after the fact from a late notification. Commission Implementing Regulation (EU) 2024/2690 describes a defensible one: assessment "based on predefined criteria laid down in advance, and on a triage", with events reassessed and reclassified when new information becomes available [5]. In practice: log the vendor’s message with its time and channel, triage against criteria written in advance, record the conclusion and the evidence behind it, and run the 24 hours from that point — reclassifying if new facts arrive.

That Regulation binds only eleven categories of entity directly — DNS service providers, TLD name registries, cloud, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. For everyone else its technical requirements are still the clearest published benchmark of what a supervisor considers adequate.

Step 3: Does It Meet Your Significance Threshold?

Both limbs of Article 23(3) include capability, not only realised harm — "is capable of causing" carries the same weight as "has caused" [2]. A vendor breach where you cannot yet rule out attacker access to your systems is therefore assessed on what it is capable of doing, not on the damage confirmed so far. The significant-incident test applies unchanged; only the origin of the compromise differs.

If you are one of the eleven categories bound by CIR 2024/2690, there is a widely missed shortcut. Article 3(1) lists seven alternative criteria, any one of which suffices. Criterion (e) is met where "a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption" [5] — which a compromised supplier holding live privileged access into your estate can satisfy on its own facts, with no financial modelling at all. Criterion (a), the one everyone quotes, sets direct loss above EUR 500,000 or 5 % of annual turnover, whichever is lower: a sufficient trigger, never a necessary one.

The decision, in order:

1. Does the compromised supplier component support a service listed in Annex I or II? If no, no mandatory report — go to Step 5.
2. Has it caused, or is it capable of causing, severe operational disruption or financial loss to you?
3. Has it affected, or is it capable of affecting, others with considerable material or non-material damage?
4. If you are CIR-bound: does any Article 3(1) criterion apply — particularly (e), unauthorised access capable of severe disruption?
5. Is this the second similar supplier incident in six months? Article 4 aggregates individually sub-threshold incidents into one significant incident where they occurred at least twice in six months, share the same apparent root cause, and collectively meet the financial criterion [5] — precisely the repeat-supplier fact pattern.

Step 4: File Your Own Report — the Vendor’s Report Is Not Yours

If the answer at Step 3 was yes, the obligation is yours and no one else’s filing discharges it. Your supplier is likely reporting the same underlying event to its own authority, in its own member state, describing impact on its own services — which says nothing about disruption to yours. No provision of the Directive lets one entity’s notification satisfy another’s.

The Article 23(4) cascade runs in three stages: an early warning within 24 hours of awareness, flagging where applicable whether the incident is suspected of being caused by unlawful or malicious acts or could have cross-border impact; an incident notification within 72 hours with an initial assessment of severity and impact plus any available indicators of compromise; and a final report not later than one month after the submission of the incident notification [2]. Read that last clause carefully — the month runs from your 72-hour filing, not from the incident, so filing early shortens your own final-report window. Most guides state this incorrectly.

Two provisions settle the borderline cases supply chain incidents produce in abundance. Article 23(1) closes with "The mere act of notification shall not subject the notifying entity to increased liability", and Article 30 allows voluntary notification of incidents, cyber threats and near misses, adding that it "shall not result in the imposition of any additional obligations upon the notifying entity" [2]. The asymmetry is deliberate: an unnecessary report costs you the filing effort, while a required report never made is an Article 23 infringement — and Article 34(4) obliges member states to expose essential entities to fines with a maximum of at least EUR 10,000,000 or at least 2 % of worldwide annual turnover, whichever is higher.

Three further steps belong in the same workflow and are routinely forgotten:

• Your own recipients. Article 23(1) requires you, where appropriate, to notify recipients of your services of significant incidents likely to adversely affect provision, and Article 23(2) to communicate available remedies where they face a significant cyber threat. In a supply chain incident you are both the downstream victim and somebody else’s upstream supplier.
• Use the CSIRT. Article 23(5) obliges it to respond where possible within 24 hours of the early warning, with initial feedback and, on request, mitigation guidance — plus guidance on reporting to law enforcement where criminal conduct is suspected. Filing early buys help, not just compliance.
• Personal data is a separate filing. As the CCB states plainly, NIS2 notifications do not replace a personal data breach notification; two separate notifications are still required [4].

Step 5: The Duty That Fires Even If You Report Nothing

This is the part competitors omit entirely, and the one most likely to surface as an audit finding. A supplier incident triggers a supply chain obligation regardless of whether it ever met a reporting threshold.

CIR 2024/2690 Annex point 5.1.6 requires entities to "monitor, evaluate and, where necessary, act upon changes in the cybersecurity practices of suppliers and service providers" — at planned intervals and when significant incidents related to the provision of ICT services, or affecting the security of suppliers’ ICT products, occur. Point 5.1.7 spells it out: review incidents related to suppliers’ ICT products and services, assess the need for unscheduled reviews and "document the findings in a comprehensible manner" [5]. The deliverable is a written re-assessment of that supplier, produced because they were breached.

The same Annex names the levers you should already hold. Point 5.1.4 requires contracts to specify, where appropriate, an obligation on suppliers to notify incidents that risk your systems without undue delay, the right to audit or to receive audit reports, vulnerability handling, requirements cascading to subcontractors, and termination obligations such as retrieval and disposal of information — the substance behind the vendor contract clauses NIS2 expects. Point 5.2 requires a maintained registry of direct suppliers with contact points and the ICT products, services and processes each provides. If you cannot answer "which of our services does this vendor touch?" within an hour of the call, that registry is the gap, not your incident response.

Article 2(2) of the Regulation closes the escape route: where the Annex qualifies a requirement with "where appropriate", "where applicable" or "to the extent feasible" and an entity considers it not so, it "shall in a comprehensible manner document its reasoning to that effect" [5]. A hedge is not an exemption. And where the review shows your measures were inadequate, Article 21(4) requires corrective measures without undue delay — measures that under Article 20(1) management bodies approve, oversee, and can be held liable for [2].

Role	Owns in the first 24 hours	Owns afterwards
CISO / IT security manager	Triage against predefined criteria; scope which services the component supports; hunt for lateral movement from supplier access paths	Technical content of the 72-hour notification and final report; revoke or re-scope supplier access
Compliance officer	Time-stamp the awareness decision and its evidence; run the Article 23(3) and, if applicable, CIR Article 3(1) tests; file the early warning	The point 5.1.7 documented re-assessment; separate data-protection filing where personal data is involved
Procurement / legal	Retrieve the contract; confirm the 5.1.4 notification clause and audit rights actually exist	Exercise audit or audit-report rights; renegotiate or exit; update the supplier registry
Management body	Be informed, not consulted for permission — reporting deadlines do not wait for a board meeting	Approve corrective measures under Article 21(4); Article 20(1) liability sits here

Frequently Asked Questions

Our vendor says they already reported the incident. Do we still have to file?
Yes, if it is significant for your services. Their notification covers impact on their services and goes to their authority; nothing in Article 23 lets one entity’s report discharge another’s obligation.

The vendor emailed us on Friday evening. Did our 24 hours start then?
Not on the email alone. The clock runs from awareness — which Belgium’s CCB defines as the point at which, after an initial assessment, you have a reasonable degree of certainty that a significant incident has occurred. Start and document that assessment immediately; one that drifts for days is what creates exposure.

Their breach hit a system with no connection to our regulated service. Anything to do?
Probably no mandatory notification, but the supply chain duty still applies: CIR Annex points 5.1.6 and 5.1.7 are triggered by the supplier incident itself and expect a documented review.

We are a manufacturer, not a cloud or DNS provider. Does CIR 2024/2690 apply to us?
Not directly — Article 1 names eleven categories of entity, running from DNS and cloud providers through to trust service providers. Your binding requirements come from your member state’s transposition of Articles 21 and 23, with the CIR used as a benchmark.

If we are unsure whether it is significant, is it safer to report?
Generally yes — Article 23(1) states that notification itself does not increase liability, and Article 30 allows voluntary notification without additional obligations. That is not a reason to report reflexively; record the reasoning either way.

Closing the File

A supplier breach is an information event, not a verdict. It obliges you to find something out — whether your own services are affected — and the answer determines which of the three obligations you carry. Organisations that get this wrong rarely misread Article 23. They get it wrong because when the call came in, nobody could say which services the vendor touched, nobody owned the assessment, and nobody wrote down the conclusion. All three are fixable before the next call.

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

1. "ENISA Threat Landscape 2025" (TLP:CLEAR, October 2025) — ENISA
2. "Directive (EU) 2022/2555 (NIS2 Directive)" — EUR-Lex, Official Journal L 333/80
3. "NIS-2-FAQ (allgemein)" — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany
4. "NIS2 Notification Guide", version 1.2, October 2024 — Centre for Cybersecurity Belgium (ccb.belgium.be)
5. "Commission Implementing Regulation (EU) 2024/2690" — EUR-Lex