Your Cloud Provider Got EUCS Certified: What That Actually Means for Your SaaS Compliance Obligations

Post #3 in the sota.io EU Cloud Sovereignty Series

Your cloud provider just sent you a notification: they have achieved EUCS Substantial Level certification under the EU Cloud Scheme. Your procurement team is relieved. Your compliance officer wants to file it and move on. Your DPO is composing a slide that says "cloud infrastructure: certified."

Stop there.

EUCS certification at the provider layer is meaningful — it tells you something real about the infrastructure you are running on. But it does not transfer to your SaaS product. Your application's compliance posture is still entirely your responsibility, and EUCS certification by your provider changes only a specific slice of your compliance picture.

This post explains exactly which slice.

What EUCS Certification Actually Certifies

The EU Cloud Certification Scheme (EUCS), developed by ENISA under the EU Cybersecurity Act (Regulation (EU) 2019/881), is a framework that cloud service providers certify against — not a blanket stamp of approval for everything running on top of them.

When a cloud provider earns EUCS certification, the certification covers:

The provider's own infrastructure and operational controls. Physical data center security, hypervisor integrity, network segmentation, identity management for provider staff, incident response procedures, supply chain controls, and legal jurisdiction boundaries.

The services explicitly listed in the certification scope. A provider might certify their managed Kubernetes offering but not their object storage, or their German region but not their Irish region. Certification scope is defined per service and per region.

The assurance level claimed. Basic covers self-assessed controls. Substantial requires independent third-party audit. High requires all Substantial controls plus legal sovereignty requirements — specifically that no non-EU legal authority can compel access without following EU law and MLAT procedures.

What is not covered: your application, your data model, your user-facing APIs, your authentication flow, your audit logging, your data retention policies, or any processing you perform on top of the certified infrastructure.

The certification boundary ends at the layer the provider manages.

The Shared Responsibility Model Under EUCS

Every cloud certification scheme — EUCS included — operates on a shared responsibility model. The provider is responsible for what they control. The tenant is responsible for everything above the provider's layer.

This split is not arbitrary — it reflects where control actually lies. Your provider cannot certify the security of code they do not write or operate.

Controls You Inherit From Your Provider's Certification

When your provider holds EUCS Substantial Level certification, you can rely on — and reference in your own documentation — the following controls without needing to independently verify them:

Physical security. The data centers hosting your workloads have passed a third-party audit for physical access controls, environmental monitoring, and facility management. You do not need to conduct a data center visit or request facility audit reports for every new customer questionnaire.

Hypervisor-level isolation. Your tenant workloads are isolated from other tenants at the virtualization layer. Side-channel attack mitigations, memory isolation, and hypervisor patching processes meet the Substantial Level requirements.

Provider employee access controls. Staff with physical or logical access to infrastructure are subject to background checks, role-based access, and access logging that has been independently audited. This addresses a significant supply chain risk without tenant effort.

Infrastructure incident response. If a security incident affects the provider's infrastructure layer, the provider has documented detection, containment, and notification procedures. At Substantial Level, these procedures have been independently validated.

Legal jurisdiction integrity (High Level only). If your provider holds High Level certification, you can assert in your own compliance documentation that the infrastructure layer is structurally protected from non-EU legal compulsion. This is relevant for NIS2-registered entities, DORA-regulated financial services, and EU public sector procurement requirements.

The practical benefit: when customers, auditors, or regulators ask you to demonstrate the security of your cloud infrastructure, you can point to your provider's EUCS certificate rather than producing your own audit of their data center. That is a real time saving — it covers a significant portion of vendor security assessment questionnaires.

Controls You Cannot Inherit and Must Implement Yourself

The longer list. These are the controls that remain entirely your responsibility regardless of your provider's certification status.

Application Security

Your application code is not in scope for your provider's certification. Vulnerabilities in your API endpoints, SQL injection risks, authentication weaknesses, and dependency supply chain issues are not addressed by EUCS. Standard application security practices — SAST, DAST, dependency scanning, penetration testing — remain your obligation.

For EU-regulated services, this matters specifically because NIS2 Article 21 requires essential and important entities to implement "appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems." The definition of "network and information systems" in NIS2 includes the software layer, not just infrastructure.

Data Processing and Classification

EUCS does not certify what data you collect, how you classify it, how long you retain it, or what processing you perform on it. GDPR obligations, data minimisation requirements, lawful basis documentation, data subject rights workflows, and cross-border transfer mechanisms are entirely your responsibility.

A nuance that matters: EUCS High Level certification means your provider cannot be compelled by a non-EU authority to produce your data. This helps with GDPR Chapter V (international transfers) arguments, because you can make a credible case that the infrastructure layer has no legally enforceable non-EU access pathway. But you must still document the legal basis for your own processing, implement data subject rights procedures, and conduct DPIAs for high-risk processing.

Access Control for Your Application

Your provider's EUCS certification covers access controls for provider staff and infrastructure management. It says nothing about how your SaaS application authenticates users, manages sessions, enforces role-based access, or protects API keys.

Implementing MFA, enforcing least-privilege access for your users and your own team, managing API key rotation, and protecting against credential compromise are your controls to implement and document.

Audit Logging for Compliance

EUCS covers audit logging for provider operations — who accessed infrastructure, what changes were made to platform resources, what incidents occurred at the infrastructure level. This does not cover application-level audit logs required by regulations that apply to your service.

For DORA-regulated financial services, detailed ICT audit trails are mandatory. For NIS2-registered entities, incident detection requires your own monitoring stack. For GDPR, access logs for personal data processing may need to be retained for defined periods. None of these are provided by your cloud provider's EUCS certification.

Your Own EUCS Certification (If Required)

If your SaaS product is itself a cloud service — you provide software running on infrastructure, which your customers use as cloud-delivered functionality — you may need your own EUCS certification rather than relying on your provider's.

EUCS covers cloud services across IaaS, PaaS, and SaaS categories. A SaaS product is in scope for EUCS certification if it meets the scheme's definition of a cloud service: IT services delivered over a network with dynamic resource allocation.

Public sector contracts in EU member states are increasingly requiring EUCS certification from service providers directly, not just from infrastructure providers. If your target market includes EU government, healthcare, or critical infrastructure, you should evaluate whether EUCS certification for your own product is a procurement requirement, not just whether your provider has a certificate.

How DORA Interacts with Your Provider's EUCS Certification

The Digital Operational Resilience Act (DORA), which has applied to EU financial entities since January 2025, has specific requirements for managing ICT third-party providers. Article 28 requires financial entities to ensure that ICT third-party service providers meet "appropriate information security standards" and that contracts contain specific provisions.

EUCS certification by your cloud provider helps satisfy the DORA Article 28 requirement to assess and manage ICT third-party risk. You can reference your provider's EUCS certificate as evidence of assessed information security standards in your ICT third-party risk register.

However, DORA Article 28 compliance is not satisfied by your provider's certificate alone. You must also:

• Maintain a documented ICT third-party risk register that includes your cloud provider
• Conduct periodic reviews of the arrangement's alignment with your digital operational resilience strategy
• Ensure your contract with the provider includes the mandatory provisions specified in DORA (access rights, audit rights, exit strategies, service level specifications, data location, sub-outsourcing controls)
• Implement and test exit and substitutability plans

The EUCS certificate is an input to your risk register, not a substitute for it.

How NIS2 Interacts with Your Provider's EUCS Certification

NIS2 Directive Article 21 requires essential and important entities to implement security measures covering, among other things, supply chain security, the security of their network and information systems, and incident handling.

If you are NIS2-registered (directly or via sectoral regulation), your cloud provider's EUCS certification directly supports your Article 21 supply chain security obligations. You can document the provider's certification as evidence of assessed supply chain risk for your infrastructure dependency.

But NIS2 Article 21 also requires incident detection and reporting capabilities at your service level — not just at the infrastructure level. If your application experiences a security incident that affects availability or data integrity, you need your own detection mechanisms and your own incident response procedures. Your provider will handle incidents affecting their infrastructure; they will not detect or respond to incidents affecting your application.

What the EUCS Certificate Covers in a Customer Security Questionnaire

When enterprise customers send you a vendor security questionnaire (VSQ) asking about your cloud infrastructure security, your provider's EUCS certificate answers a specific category of questions:

Questions it answers well:

• Physical data center security (access controls, environmental monitoring)
• Infrastructure-level encryption (storage and network encryption by the provider)
• Provider employee background checks and access controls
• Third-party infrastructure audit status and frequency
• Data center location and jurisdiction (critical for High Level certification assertions)
• Provider incident response and notification procedures

Questions it does not answer:

• Your application security testing schedule and methodology
• Your data classification and handling procedures
• Your user access management and authentication requirements
• Your own audit log retention policies
• Your incident response capability for application-level events
• Your penetration testing program

For the second category, you need your own documentation. The practical implication: maintain a clear separation in your compliance documentation between "provider-layer controls (reference: EUCS certificate [number])" and "application-layer controls (reference: your internal policies and procedures)." This separation makes VSQ responses faster and more defensible in audit.

Building Your Compliance Posture on a EUCS-Certified Platform

The correct way to think about your cloud provider's EUCS certification is as a foundation, not as coverage.

You get a certified foundation for the infrastructure layer. The physical security, hypervisor integrity, legal jurisdiction, and operational controls of that infrastructure have been independently validated. You can cite that foundation in your own compliance documentation without reproducing the provider's audit work.

On that foundation, you build your application-layer compliance posture: application security controls, data governance procedures, access management, audit logging, incident response, and — where required — your own product-level certifications.

The two layers are complementary. A EUCS High Level certified provider running in Germany gives you a structurally stronger foundation than an uncertified provider or a US-owned hyperscaler that cannot satisfy the jurisdiction requirements. But the strength of the foundation does not reduce the height of the structure you need to build on top.

Practical Checklist: Tenant Obligations After Your Provider Gets EUCS Certified

Immediately:

• Update your third-party risk register to include the EUCS certificate number, certification scope, assurance level, and expiry date
• Identify which specific services and regions in your provider's infrastructure are covered by the certification scope (not all services may be certified)
• Note what is not covered and verify you have equivalent controls at the application layer

Review and document:

• Your own application security testing cadence and methodology
• Your data classification policy and how it maps to the data stored on the certified infrastructure
• Your user authentication and access control implementation
• Your incident detection and response procedures for application-level events
• Your audit log retention policy for application events

For DORA-regulated entities:

• Verify your contract with the provider includes the mandatory DORA Article 28 provisions
• Update your digital operational resilience testing plan to reflect the provider's certified controls
• Ensure your exit and substitutability plan is current

For NIS2-registered entities:

• Reference the EUCS certificate in your supply chain security section of your NIS2 security documentation
• Verify your incident detection capability covers application-level events independently of provider notification

For public sector or regulated industry procurement:

• Determine whether your target customers require EUCS certification for your product directly, not just for your infrastructure provider
• If yes, initiate the EUCS certification process for your own SaaS product — your provider's certificate does not cover your application

What Comes Next in This Series

Post 4 covers the regulatory intersection: how EUCS certification requirements interact with DORA, NIS2, and EU public procurement rules in specific regulated industries — financial services, healthcare, and critical infrastructure operators — and what this means for software vendors targeting those markets.

Post 5 is the full developer checklist: every EUCS-relevant action a SaaS team needs to take from infrastructure selection through certification readiness, with a 2026-2027 timeline.

The previous posts covered what EUCS assurance levels mean for provider qualification and what the technical control requirements look like at the High Level. Those posts established what to look for in your infrastructure provider. This post is about what you do with a certified provider underneath you.

The work does not end at the infrastructure boundary.