Denys Zaruin

Posted on Nov 2 Originally published at moveinfra.eu

NIS2 and your cloud provider: what it means for supply-chain risk

#cloud #nis2 #cloudcompliance #supplychainrisk

Originally published on moveinfra.eu.

Under the EU's NIS2 Directive (Directive (EU) 2022/2555), European companies in regulated sectors are legally responsible for the cybersecurity and resilience of their direct ICT suppliers, including cloud computing providers. You cannot outsource NIS2 compliance to your cloud host by collecting an ISO 27001 certificate. Article 21 requires essential and important entities to assess the specific risks of each cloud provider, take into account the overall quality and resilience of their services, and consider coordinated EU risk assessments of critical supply chains. Even if your own company is too small or outside the sectors covered by NIS2, your enterprise and mid-market customers in the EU are likely in scope. They are required by law to push supply-chain security requirements down to their software and hosting vendors, making your choice of cloud provider a commercial issue as well as a compliance one.

Key takeaways

Supply-chain security is mandatory under Article 21(2)(d): Entities in scope must address cybersecurity risks in the relationships between themselves and their direct suppliers or service providers, explicitly including data storage and processing services.
Cloud providers are regulated directly and indirectly: Cloud computing service providers are classified under Annex I ("Digital Infrastructure") and face harmonize technical rules under Commission Implementing Regulation (EU) 2024/2690. At the same time, every NIS2-regulated customer must independently evaluate their cloud provider's risk profile.
Non-technical and jurisdictional risks matter: Under Article 21(3) and Article 22, supplier assessments must consider not just technical security controls, but also the overall resilience of suppliers and the findings of EU-level coordinated security risk assessments—which often examine legal jurisdiction and third-country dependencies.
Small SaaS companies feel NIS2 through customer procurement: If you sell B2B software to European energy, healthcare, transport, manufacturing, or public-sector clients, their NIS2 supply-chain questionnaires will ask where your infrastructure runs, who controls it, and how you handle incidents.
Business continuity requires avoiding hard lock-in: Article 21(2)(c) mandates business continuity, backup management, and disaster recovery. Combined with the EU Data Act (Regulation (EU) 2023/2854), regulators and auditors increasingly expect cloud architectures to be portable.

Who is in scope—and why out-of-scope companies still care

NIS2 replaced the original 2016 NIS Directive to set a much wider baseline for cybersecurity across the European Union. Member States had until October 17, 2024, to transpose the directive into national law, and while several national parliaments experienced delays into 2025 and 2026, enforcement mechanisms are active across the bloc.

The directive divides covered organizations into two main categories based on their sector and size (generally applying to medium-sized enterprises with 50 or more employees, or annual turnover and balance sheet over €10 million, with some size-independent exceptions):

Essential entities (Annex I): Energy, transport, banking, financial market infrastructures, health, drinking water, waste water, space, public administration, ICT service management (B2B), and digital infrastructure (which includes DNS providers, TLD registries, data center providers, content delivery networks, and cloud computing service providers).
Important entities (Annex II): Postal and courier services, waste management, chemicals, food production and distribution, manufacturing (medical devices, electronics, machinery, motor vehicles), digital providers (online marketplaces, search engines, social networks), and research organizations.

The B2B cascade effect

Many European tech companies with 10 to 50 employees look at the size thresholds and conclude that NIS2 does not apply to them. Legally, they may not be registered as an essential or important entity with their national Computer Security Incident Response Team (CSIRT).

Practically, however, NIS2 is designed as a supply-chain cascade. When a 200-person logistics company, a regional hospital network, or a German industrial manufacturer implements its NIS2 compliance program, it must audit its direct ICT suppliers. If your SaaS product processes their operational data, you are part of their supply chain. Their procurement and security teams will require you to document your security measures, incident reporting timelines, and sub-processors—starting with your cloud infrastructure provider.

What NIS2 actually says about cloud providers and supply chains

To understand how NIS2 affects your cloud architecture, you only need to look at three parts of the law: Article 21 (risk management), Article 22 (coordinated supply-chain assessments), and Commission Implementing Regulation (EU) 2024/2690.

1. Article 21(2)(d): Supply-chain security

Article 21(2) lists the ten baseline cybersecurity risk-management measures that every essential and important entity must implement. Point (d) specifies:

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

Article 21(3) clarifies how you must evaluate those suppliers. When deciding which measures are appropriate, entities must take into account:

The vulnerabilities specific to each direct supplier and service provider.
The overall quality of products and cybersecurity practices of their suppliers, including their secure development procedures.
The results of coordinated security risk assessments of critical supply chains carried out under Article 22(1).

Notice that the text focuses on relationships and vulnerabilities specific to each supplier. Having a cloud provider that publishes a generic compliance badge does not fulfill your obligation. You have to define the security responsibilities in your contract, understand where the provider's responsibility ends and yours begins, and evaluate whether that specific provider introduces concentration or operational risk into your business.

2. Article 21(2)(c): Business continuity and crisis management

Point (c) of Article 21(2) requires entities to maintain:

"business continuity, such as backup management and disaster recovery, and crisis management."

When your entire production environment lives on a single cloud provider using proprietary managed services, a provider-level outage, account suspension, or contractual dispute becomes an existential business continuity failure. Under NIS2, management bodies (who bear personal liability under Article 20 for approving and overseeing cybersecurity measures) must ensure that backups are usable and that recovery plans work even if a primary supplier fails.

3. Article 22: Non-technical and jurisdictional risk

Article 22 empowers the NIS Cooperation Group, together with the European Commission and ENISA (the EU Agency for Cybersecurity), to carry out coordinated security risk assessments of specific critical ICT services, systems, or products. Importantly, Recital 90 and Article 22 state that these assessments shall take into account ** both technical and, where relevant, non-technical risk factors**, such as undue influence by a third country on suppliers.

This is the same mechanism the EU previously used to assess 5G network suppliers. In the context of cloud infrastructure, "non-technical risk factors" refer primarily to extra-territorial laws. If a cloud provider is headquartered outside the EU, it may be subject to foreign laws—such as the US CLOUD Act or FISA Section 702—that compel the parent company to provide access to data or systems regardless of where the physical servers are located.

Even when a US hyperscaler offers an EU-based sovereign product, such as the AWS European Sovereign Cloud, the infrastructure and operations remain inside the EU, but the parent entity belongs to Amazon, a US corporation. For many NIS2-regulated organizations—especially in public administration, health, energy, and defense-adjacent manufacturing—assessing supply-chain risk under Article 21(3) means weighing this jurisdictional exposure.

4. Implementing Regulation (EU) 2024/2690

Because cloud computing service providers, DNS providers, and managed service providers operate across borders, the European Commission adopted Implementing Regulation (EU) 2024/2690 on October 17, 2024. Unlike the directive itself, this is a regulation that applies directly across all EU Member States.

It sets out detailed technical and methodological requirements for cloud providers themselves, alongside specific thresholds for what counts as a "significant incident" (such as complete service unavailability for more than a set duration, or compromises of confidentiality and integrity affecting customer data). When evaluating a cloud provider for NIS2 compliance, you should verify how the provider complies with Implementing Regulation 2024/2690 and whether their incident notification SLAs allow you to meet your own NIS2 reporting deadlines (an early warning within 24 hours of becoming aware of a significant incident, and a detailed notification within 72 hours under Article 23).

How NIS2 interacts with DORA and the EU Data Act

European cloud regulation no longer operates in silos. If you are reviewing your cloud provider for NIS2, two other EU laws directly affect your architectural choices:

DORA (Regulation (EU) 2022/2554): If you are in the financial sector (or provide critical ICT services to financial entities), DORA applies from January 17, 2025, and acts as lex specialis (sector-specific law that overrides the general rules of NIS2). DORA goes a step further than NIS2 by explicitly requiring documented, tested exit strategies for ICT services supporting critical or important functions, to avoid vendor lock-in and concentration risk.
The EU Data Act (Regulation (EU) 2023/2854): While NIS2 tells you to ensure business continuity and manage supplier risk, the EU Data Act makes switching cloud providers legally and financially feasible. Under Article 29 of the Data Act, cloud providers may charge switching fees—including data egress charges when moving to another provider—at no more than their direct cost until January 12, 2027. From January 12, 2027, all switching and egress charges for changing cloud providers are banned entirely.

Together, these three laws point in the same direction: European companies are expected to know exactly what cloud services they use, avoid irreversible technical lock-in, and maintain the ability to move workloads or restore backups independently of a single vendor.

Practical checklist: Assessing your cloud setup for NIS2

Whether you are directly regulated under NIS2 or preparing for enterprise customer audits, use the table below to evaluate your current cloud provider and infrastructure design against NIS2 requirements.

NIS2 Requirement	Reference	Questions to ask about your cloud setup	Practical architectural actions
Supply-chain security & supplier quality	Art. 21(2)(d), Art. 21(3)	Does your contract define security responsibilities, audit rights, and sub-processor transparency? Is the provider compliant with Implementing Regulation (EU) 2024/2690?	Document the shared responsibility boundary for every service (VMs, managed DBs, Kubernetes). Collect the provider's current C5, ISO 27001, or national security attestations.
Jurisdictional & non-technical risk	Art. 21(3), Art. 22, Recital 90	Where is the cloud provider legally headquartered? Can a non-EU government compel the parent company to hand over encryption keys or suspend service?	Evaluate whether sensitive workloads require an EU-owned cloud provider (such as UpCloud, Scaleway, Hetzner, OVHcloud, STACKIT, IONOS, or Exoscale) subject exclusively to EU and national laws.
Incident detection & 24h/72h reporting	Art. 23	Will your cloud provider notify you fast enough of an infrastructure-level breach or outage for you to file a 24-hour early warning with your national CSIRT?	Centralize logs (VPC flow logs, API audit logs, database logs) in a system you control. Verify contractual incident notification windows with your provider.
Business continuity & disaster recovery	Art. 21(2)(c)	If your primary cloud account is locked, compromised, or suffers a multi-day regional outage, can you restore operations elsewhere?	Store encrypted off-site backups of databases and object storage in a separate provider or jurisdiction. Test restoring those backups on standard virtual machines or Kubernetes.
Portability & exit readiness	Art. 21(2)(c) & EU Data Act	How much of your stack relies on proprietary services (e.g., DynamoDB, Firestore, proprietary IAM/serverless) that cannot run on another cloud?	Define infrastructure as code (e.g., OpenTofu or Terraform) and favor open standards (PostgreSQL, MySQL, Redis-compatible caches, S3-compatible object storage, standard Kubernetes).
Cryptography & access control	Art. 21(2)(h), (i), (j)	Is data encrypted at rest and in transit? Who holds the keys? Is multi-factor authentication (MFA) enforced on all cloud console and SSH access?	Enforce hardware or strong MFA for all root and admin accounts. Implement least-privilege IAM roles and verify who manages the key management service (KMS).

Reducing cloud supply-chain risk through architecture

For an engineering or operations lead at a 30-to-250-person company, the biggest obstacle to NIS2 business continuity is rarely physical server security—both US hyperscalers and major European cloud providers run physically secure data centers. The real risk is architectural dependency.

When you build deeply on proprietary cloud primitives, your company's operational resilience is tied 100% to one vendor's availability, pricing, legal jurisdiction, and terms of service. You can reduce this risk in three concrete steps:

1. Standardize on portable infrastructure primitives

Use managed services that are based on open-source engines rather than closed, vendor-specific APIs. A managed PostgreSQL or MySQL database, a standard Kubernetes cluster, and S3-compatible object storage give you the operational convenience of managed cloud services without trapping your application logic. If you need to switch providers for regulatory or commercial reasons, logical replication and standard checksummed object clones can move your data without rewriting code.

2. Keep infrastructure defined as code

Under NIS2, being able to rebuild your environment predictably after an incident is part of crisis management. Maintaining your networks, firewalls, load balancers, and compute instances in Terraform or OpenTofu means your architecture is documented, version-controlled, and auditable. It also makes it straightforward to map your resource inventory to a secondary European provider if needed.

3. Match provider jurisdiction to workload sensitivity

You do not always have to adopt an all-or-nothing approach on day one, though consolidating on a single compliant stack simplifies operations for smaller teams. If your company sells into regulated European sectors—such as health tech, energy management, public-sector software, or industrial IoT—running your production environment on an EU-owned cloud provider eliminates the third-country jurisdictional question from every NIS2 and GDPR procurement questionnaire. European providers like UpCloud, Scaleway, OVHcloud, Hetzner, IONOS, STACKIT, and Exoscale are headquartered in Europe and operate exclusively under European jurisdiction.

Frequently asked questions

Does NIS2 require us to host our data in the EU or use an EU-owned cloud provider?

No, NIS2 does not contain a blanket ban on non-EU cloud providers or mandatory data localization for all sectors. However, Article 21(3) and Article 22 require covered entities to assess supplier vulnerabilities and take into account non-technical risks, including third-country legal influence. In practice, many essential entities in public administration, healthcare, and critical infrastructure prefer or require EU-owned cloud infrastructure to simplify their supply-chain risk assessments and avoid extra-territorial laws like the US CLOUD Act.

Our cloud provider is ISO 27001 and SOC 2 certified. Does that make us NIS2 compliant?

No. While your cloud provider's certifications help demonstrate the technical quality of their physical and hypervisor security under Article 21(3), NIS2 compliance applies to your organization's risk management, access controls, backup procedures, incident reporting, and governance. You are still responsible for how you configure the cloud, how you secure your applications, and how you ensure business continuity if that provider fails.

How does NIS2 affect a 30-person SaaS company that is below the size threshold?

If you have fewer than 50 employees and under €10 million in annual turnover, you are generally not directly regulated under NIS2 (unless you are a DNS provider, TLD registry, trust service provider, or sole provider of a critical service in a Member State). However, your mid-market and enterprise customers who are in scope must enforce supply-chain security on their direct ICT suppliers under Article 21(2)(d). Expect your customers to require contractual commitments on 24-hour incident notification, backup resilience, and sub-processor jurisdiction.

What happens if we miss NIS2 compliance requirements?

For directly regulated entities, national authorities have broad supervisory and enforcement powers, including binding instructions and security audits. Under Article 34, administrative fines for essential entities can reach a maximum of at least €10 million or 2% of total worldwide annual turnover (whichever is higher), and for important entities, a maximum of at least €7 million or 1.4% of total worldwide annual turnover. Furthermore, Article 20 establishes direct accountability for management bodies.

Sources

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

DEV Community