NIS2, DORA, and the Regulatory Case for Knowing Your Dependencies

Two pieces of EU legislation, NIS2 and DORA, are fundamentally changing how European organisations must think about their technology suppliers. Neither regulation bans US cloud providers. But both make it legally necessary to understand, document, and manage the risks that come with depending on them.

Most organisations are not ready. Here is what the regulations actually require, and what compliance looks like in practice.

NIS2: Supply Chain Risk Is Now Mandatory

The Network and Information Security Directive 2 (NIS2), which EU member states were required to transpose into national law by October 2024, significantly expands the scope of cybersecurity obligations across Europe.

Who is affected

NIS2 applies to organisations in “essential” and “important” sectors. The list is broad:

• Essential sectors: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space
• Important sectors: postal services, waste management, chemicals, food, manufacturing, digital providers, research organisations

If your organisation falls into either category, or if you supply one, NIS2 applies to you.

What NIS2 requires for supply chain risk

Article 21 of NIS2 requires organisations to implement cybersecurity risk management measures that include:

“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”

This is not a suggestion. It is a legal requirement with enforcement mechanisms. Member states must establish supervisory authorities with the power to conduct audits, issue binding instructions, and impose administrative fines.

For organisations that depend heavily on US cloud providers, this means:

1. You must identify your critical ICT suppliers. Not just the obvious ones (Microsoft, Google, AWS) but every service in the chain: identity providers, DNS, CDN, monitoring, CI/CD, payment processing.
2. You must assess the risks they introduce. Including jurisdictional risk (US CLOUD Act exposure), concentration risk (single-vendor dependency), and operational risk (what happens if the service is unavailable).
3. You must implement proportionate measures. This could include diversification, contingency planning, contractual safeguards, or migration to alternative providers.
4. You must report significant incidents. Within 24 hours for an early warning, 72 hours for a full notification. If a US provider’s service disruption causes an incident, you need to know your dependencies well enough to trace the impact.

What most organisations are missing

Most NIS2 compliance efforts focus on network security, incident response, and access management. Supply chain risk is often treated as a checkbox: “we have contracts with our vendors.”

But NIS2’s supply chain provisions require more than contracts. They require operational understanding of what each supplier controls, what happens if they fail or are legally compelled to act against your interests, and what your realistic alternatives are.

A dependency audit is the practical starting point for NIS2 supply chain compliance: it maps the relationships, identifies the concentration risks, and produces the documentation that supervisory authorities will eventually ask for.

DORA: Concentration Risk as a Legal Concept

The Digital Operational Resilience Act (DORA), which applies from January 2025, goes further than NIS2 in one critical area: it explicitly addresses ICT third-party concentration risk.

Who is affected

DORA applies to virtually all regulated financial entities in the EU:

• Credit institutions and payment institutions
• Investment firms and crypto-asset service providers
• Insurance and reinsurance undertakings
• Pension funds
• Credit rating agencies
• Crowdfunding service providers

It also applies to critical ICT third-party service providers, which includes major cloud providers that serve the European financial sector.

What DORA requires

DORA introduces several obligations directly relevant to cloud dependency:

ICT third-party risk management (Chapter V)

Financial entities must maintain a register of all ICT third-party arrangements, including:

• The services provided and the data processed
• The locations where data is stored and processed
• The subcontracting chain
• Whether the provider is considered critical

They must conduct risk assessments before entering into arrangements, and ongoing monitoring throughout the relationship.

Concentration risk management (Article 29)

DORA explicitly requires financial entities to assess and manage the risk of excessive dependency on a single ICT provider or a small number of providers. This includes:

• Identifying where a failure of a single provider would affect multiple critical functions
• Assessing whether adequate alternatives exist
• Developing exit strategies and transition plans

This is remarkable: EU law now explicitly requires organisations to have exit strategies for their cloud providers.

Exit strategies (Article 28)

Financial entities must ensure that contracts with ICT providers include provisions for:

• Adequate transition periods in the event of termination
• Continued data access and portability
• Clear data deletion obligations after transition

They must also develop and maintain exit plans that can be executed without undue disruption.

What compliance actually looks like

For a financial services organisation running on Microsoft 365 and Azure, DORA compliance requires:

1. A complete register of every ICT third-party arrangement: every SaaS tool, every API integration, every data processing relationship.
2. A concentration risk assessment documenting that Microsoft controls your identity (Azure AD), email (Exchange), files (SharePoint/OneDrive), collaboration (Teams), cloud compute (Azure), and security (Defender). Then assessing what happens if any or all of these become unavailable.
3. A documented exit strategy. A specific, executable plan for transitioning away from each critical ICT provider, including timelines, costs, and operational impacts.
4. Ongoing monitoring. Regular reassessment of third-party risk, including changes in the provider’s jurisdiction, corporate structure, or relationship with regulators.

Most financial entities do not have this. The register exists in procurement systems. The concentration risk assessment, if it exists, is a paragraph in a risk document. The exit strategy is usually “we will figure it out when we need to.”

DORA makes this insufficient.

The Practical Intersection

NIS2 and DORA are complementary. Together, they establish a regulatory framework that makes it legally necessary for a wide range of European organisations to:

1. Know what they depend on. A complete map of ICT dependencies, including identity, cloud, SaaS, and integration layers.
2. Understand the risks. Jurisdictional exposure, concentration risk, operational fragility.
3. Have realistic alternatives. A scored assessment of what is actually replaceable and what is not.
4. Maintain exit strategies. Documented, executable plans for transitioning away from critical providers.

This is precisely what a dependency audit delivers. Not as a compliance exercise, but as a practical tool that satisfies regulatory requirements while producing genuinely useful decision artifacts.

The Timeline Pressure

NIS2 transposition deadlines have passed (October 2024), and member states are implementing enforcement mechanisms. DORA applies from January 2025. Supervisory authorities are ramping up.

The organisations that will be best positioned are those that start now: with a clear understanding of what they depend on, which dependencies carry the most risk, and what realistic alternatives exist.

The regulatory question is no longer whether you should understand your cloud dependencies. It is whether you can demonstrate that you do.

Sovereign Shift delivers the dependency maps, risk assessments, and exit strategies that NIS2 and DORA require. One engagement, one deliverable. See how it works →