2025 was the year supply chain risk stopped being theoretical for EU-regulated organisations. Not because the threat was new — SolarWinds, Kaseya, and MOVEit had already demonstrated the pattern — but because three distinct incident types exposed exactly the gaps that NIS2 and DORA were designed to close.
What follows is a retrospective analysis of three composite incidents drawn from publicly reported patterns in 2025. For each, we examine a direct question: if the affected organisations had fully implemented NIS2 Art. 21(2)(d) supply chain security measures and DORA Chapter V ICT third-party risk management obligations, would the outcome have been different?
The answer, in every case, is yes. Not because compliance is a silver bullet, but because the specific controls these regulations mandate address the specific failure modes these incidents exploited.
Incident 1: The Managed Service Provider Compromise
What Happened
A mid-tier managed service provider operating across northern Europe was compromised through a vulnerability in its remote management tooling. The attacker maintained persistent access for approximately six weeks before deploying ransomware simultaneously across the MSP's client base. Over 200 organisations — including several NIS2-designated essential entities in the healthcare and energy sectors — experienced data encryption, operational disruption, or both.
The MSP had SOC 2 Type II certification. Its clients had reviewed the SOC 2 report during onboarding. Most had not conducted independent security assessments of the MSP since procurement. None had contractual provisions requiring the MSP to notify them of security incidents within a specified timeframe shorter than the MSP's own internal escalation procedures.
The result: affected entities learned about the compromise when their own systems went down. By then, containment options were limited.
The NIS2 Lens
NIS2 Art. 21(2)(d) requires entities to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." The implementing guidance elaborated by ENISA makes clear this is not satisfied by collecting vendor certifications.
Had the affected entities implemented Art. 21(2)(d) with operational rigour, three controls would have changed the outcome:
Contractual incident notification clauses. NIS2 does not just require the entity itself to report incidents under Art. 23. It implicitly requires that the entity can learn about supply chain incidents fast enough to meet its own reporting obligations. That demands contractual notification windows with critical suppliers — typically 24 hours or less for incidents potentially affecting the entity's systems or data.
Continuous supplier risk assessment. A SOC 2 report is a point-in-time attestation. Six weeks of undetected attacker access in a supplier's environment is a risk that point-in-time certification cannot catch. Art. 21(2)(d) contemplates ongoing assessment, not periodic checkbox review.
Supply chain incident response integration. The entity's own incident response plan must account for scenarios where the attack vector is a trusted supplier. Most plans tested in 2025 assumed the compromise originated inside the entity's own perimeter.
The DORA Lens
For financial entities among the MSP's clients, DORA Chapter V imposed additional obligations. Article 28 requires a register of all contractual arrangements with ICT third-party service providers. Article 28(2) mandates that this register include assessment of the ICT concentration risk. Article 30 specifies contractual provisions that must be included in agreements with ICT service providers, including incident notification obligations and audit rights.
An entity compliant with DORA Art. 30 would have had contractual notification requirements in place. More importantly, the Art. 28 register exercise — when done properly — would have flagged the MSP as a concentration risk, given that the same MSP served multiple entities in the same sector. That concentration risk identification should have triggered enhanced due diligence and potentially a multi-supplier strategy.
Incident 2: The Open-Source Dependency Poisoning
What Happened
A widely used open-source library in the JavaScript ecosystem — a utility package with millions of weekly downloads, commonly used in financial services front-end applications — was compromised through a social engineering attack on its volunteer maintainer. The attacker gained publishing credentials and pushed a malicious update that exfiltrated environment variables, including API keys and database credentials, from applications that pulled the update.
The poisoned version was live for approximately 72 hours before community detection and removal. During that window, automated CI/CD pipelines at hundreds of organisations pulled the update and deployed it to staging and, in some cases, production environments.
Financial services firms across the EU were affected. Several discovered credential exposure that required emergency rotation of production secrets and precautionary assessment of whether backend systems had been accessed using exfiltrated credentials.
The NIS2 Lens
Art. 21(2)(d) extends supply chain security to "the quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." Open-source dependencies are suppliers. The EU's own thinking on software supply chain security, informed by the Cyber Resilience Act, makes clear that software composition analysis and dependency risk management are part of the supply chain security obligation.
Organisations with mature NIS2-aligned supply chain programmes would have had:
Software bill of materials (SBOM) management. Knowing exactly which open-source dependencies run in production, and at which versions, is the precondition for rapid response. Organisations without SBOM tooling spent the first 24 hours just determining whether they were affected.
Dependency pinning and review gates. Automatically pulling the latest version of a dependency into production without review is a supply chain security failure. NIS2-aligned development practices require assessment before adoption — even for minor version updates from trusted packages.
Credential isolation and rotation capability. If environment variables including production secrets are accessible to front-end dependencies, the blast radius of any dependency compromise includes credential exposure. Least-privilege architecture limits this exposure. Rapid credential rotation capability limits the exploitation window.
The DORA Lens
DORA Art. 25(1) requires financial entities to conduct "digital operational resilience testing, proportionate to [their] size and the nature, scale and complexity of [their] activities and services." Dependency poisoning is a testable scenario. Red team exercises should include supply chain compromise simulations: what happens when a trusted library is silently modified? How quickly does the organisation detect anomalous behaviour? How quickly can it roll back?
Financial entities that had tested this scenario detected the poisoned dependency through anomalous network behaviour within hours. Those that had not tested it relied on community disclosure — 72 hours later.
Incident 3: The Cloud Provider Regional Outage
What Happened
A major European cloud provider experienced a cascading failure in one of its primary EU regions. A configuration error during routine maintenance propagated across availability zones, taking down compute, storage, and networking services for approximately 72 hours. Partial service was restored after 36 hours, but full recovery — including data integrity verification — took three full days.
Essential service operators in energy, transport, and healthcare that had deployed their primary and secondary systems in the same cloud region experienced complete service disruption. Organisations with multi-region or multi-cloud architectures experienced degradation but maintained operational continuity.
The incident was not a cyber attack. It was an operational failure. But the impact on essential service delivery was indistinguishable from a destructive attack — and the regulatory reporting obligations were identical.
The NIS2 Lens
NIS2 Art. 21(2)(c) requires "business continuity, such as backup management and disaster recovery, and crisis management." The regulation does not specify multi-cloud or multi-region architecture, but it requires that the entity's business continuity measures be "appropriate and proportionate" to the risk.
For an essential service operator — a hospital, an energy grid operator, a transport authority — single-cloud, single-region deployment of critical services is not proportionate to the risk. The proportionality assessment under NIS2 requires considering the likelihood and impact of scenarios including provider outage. A 72-hour outage of a major cloud provider is not an exotic tail risk. It is a documented, repeated reality.
Organisations compliant with Art. 21(2)(c) would have:
- Tested their business continuity plans against a cloud provider outage scenario
- Documented recovery time objectives and validated them through actual testing
- Implemented geographic or provider diversification for critical services
- Maintained the ability to operate essential functions during extended provider unavailability
The DORA Lens
DORA is even more explicit. Article 28(8) specifically addresses ICT concentration risk at entity and sector level. The European Supervisory Authorities are empowered to designate critical ICT third-party service providers (CTPPs) under Article 31, precisely because the failure of a single provider can cascade across the financial sector.
Article 11 requires financial entities to implement an "ICT business continuity policy." Article 12 requires "response and recovery plans" that are tested at least annually and after significant changes to ICT systems. An entity compliant with these articles — genuinely compliant, not paper-compliant — would have tested the scenario of its primary cloud provider being unavailable for 72 hours. That test would have revealed single-region concentration risk before a real outage exposed it.
For detailed guidance on structuring your DORA third-party oversight programme, including exit strategy requirements and concentration risk assessment methodologies, see our framework documentation.
NIS2 Art. 21(2)(d): What Supply Chain Security Actually Requires
Across all three incidents, a pattern emerges. The organisations that fared worst were those that treated supply chain security as a procurement-time exercise: collect the vendor's certification, file it, revisit at contract renewal.
NIS2 Art. 21(2)(d) requires something fundamentally different. It requires ongoing management of supply chain risk as a living operational concern. The text specifies that entities must address "the quality of products and cybersecurity practices of their suppliers and service providers." This is present-tense, continuous — not past-tense, point-in-time.
Practically, this means:
- Maintaining a current inventory of all suppliers and service providers with access to the entity's systems, data, or operations
- Classifying suppliers by criticality based on the impact of their compromise or failure on the entity's essential services
- Defining proportionate security requirements for each criticality tier, embedded in contracts
- Conducting ongoing assessment — not just annual review — of critical suppliers' security posture
- Integrating supplier incident scenarios into the entity's own business continuity and incident response testing
- Documenting exit strategies and alternative providers for critical dependencies
DORA Chapter V: ICT Third-Party Risk Management Obligations
DORA Chapter V goes further than NIS2 for financial entities. The key obligations:
- Art. 28: Register of all ICT third-party arrangements. This is not optional documentation — it is a regulatory submission. Entities must report this register to their competent authority.
- Art. 29: Pre-contractual due diligence, including assessment of the provider's information security standards, any concentration risk, and the provider's ICT sub-contracting chain.
- Art. 30: Mandatory contractual provisions covering service level descriptions, data locations, incident notification, audit rights, exit strategies, and participation in the entity's resilience testing.
- Art. 31-44: The oversight framework for critical ICT third-party service providers, including direct ESA oversight and the ability to issue recommendations and, ultimately, impose penalties.
For a complete treatment of NIS2 supply chain security requirements, including practical implementation guidance and common gaps, see our framework analysis. Our supply chain security guide provides step-by-step implementation pathways.
Five Concrete Lessons for 2026 Compliance Programmes
Lesson 1: Certification is not assurance. SOC 2, ISO 27001, and other certifications tell you what the supplier's controls looked like at a point in time. They do not tell you whether those controls are working today. Your supply chain security programme must include continuous or at minimum quarterly assessment of critical suppliers, beyond certification review.
Lesson 2: Software dependencies are suppliers. Every open-source library in your production environment is a supplier relationship you did not negotiate. SBOM management, dependency review gates, and automated vulnerability scanning of your dependency tree are supply chain security controls, not just development best practices.
Lesson 3: Concentration risk is a failure mode, not a risk factor. When your primary cloud provider goes down and your disaster recovery runs on the same provider in the same region, you do not have disaster recovery. You have an expensive illusion of redundancy. Test your business continuity against provider-level failure, not just application-level failure.
Lesson 4: Contractual notification speed determines your regulatory compliance. If your critical supplier takes 96 hours to tell you about a breach, and NIS2 requires you to notify within 24 hours, you will fail your regulatory obligation through no fault of your own operational security. Contractual notification windows for critical suppliers must be shorter than your own regulatory reporting deadlines.
Lesson 5: Test the supply chain scenario, not just the internal scenario. Most business continuity tests simulate internal failures: server goes down, database corrupts, office becomes inaccessible. The 2025 incidents demonstrate that the most impactful disruptions originate outside the entity's perimeter. Your resilience testing must include supplier compromise, dependency poisoning, and provider outage scenarios.
Operationalising these lessons requires vendor risk management capabilities that go beyond questionnaire-based assessment. Continuous monitoring, contractual compliance tracking, and integration with your incident response workflow are the minimum viable programme for 2026.
Key Takeaways
- The three dominant supply chain attack patterns of 2025 — MSP compromise, dependency poisoning, and cloud provider outage — each exploited gaps that NIS2 Art. 21(2)(d) and DORA Chapter V were specifically designed to close.
- Compliance is not prevention, but organisations with operational NIS2/DORA supply chain controls detected incidents faster, contained blast radius more effectively, and recovered to operational status sooner than those with certification-only approaches.
- Software supply chain security (SBOM, dependency pinning, review gates) is not optional under NIS2. Open-source libraries are suppliers.
- ICT concentration risk — single cloud, single region, single MSP — is the highest-impact supply chain failure mode for essential and important entities. DORA Art. 28(8) addresses this explicitly; NIS2 addresses it through the proportionality principle.
- Contractual incident notification speed is the critical link between supplier compromise and regulatory compliance. If your contract does not specify notification windows, your compliance programme has a structural gap.