EU Cloud Compliance: 12-Point Checklist for Cloud Services
EU cloud compliance spans four layers: law, standards, contracts, evidence. With a 12-point checklist, worked example, and common pitfalls.

Cloud compliance in the EU means being able to show, for every cloud service in use, which rules apply, which standards the provider demonstrates, what has been contractually agreed, and which document proves it. Anyone searching for "cloud compliance eu" is therefore dealing with four layers: EU law such as the GDPR and the Data Act, standards such as ISO/IEC 27001 or BSI C5, contracts with the provider, and the evidence for customers, auditors, and procurement teams. A data center in Frankfurt does not fully cover any of these layers on its own.
This article is operational guidance, not legal advice. Whether a given regulation applies to your organization, and what it specifically requires, should be clarified with qualified legal counsel or the responsible authority.
Four layers that get confused constantly in practice
The most common confusion: a certificate is presented as proof that a law is being followed. An ISO 27001 certificate says something about a management system within a defined scope. It says nothing about whether your specific data processing is legally permissible.
| Layer | Examples | Binding effect | Typical evidence | Who confirms it |
|---|---|---|---|---|
| Law | GDPR, Data Act, national NIS2 transposition | binding, where applicable in the individual case | Record of processing activities, data processing agreement | Legal counsel, supervisory authority |
| Standard | ISO/IEC 27001, BSI C5 | voluntary, often contractually required | Certificate including scope, audit report | Certification body, auditor |
| Code of conduct | EU Cloud Code of Conduct | voluntary self-commitment | Entry in the public register | Monitoring body |
| Contract | DPA, SLA, list of subprocessors | binding between the parties | Signed version with date | Procurement, legal department |
| Operations | Region setting, access rights, logs | internal practice | Configuration export, dated screenshot | Your own team |
The fifth row is the one most often forgotten. A provider may offer EU regions; whether your account actually uses them is shown only by your own configuration.
What the EU Commission classifies under cloud policy
The European Commission's cloud page describes the goal of giving businesses and public administrations access to secure, sustainable, and interoperable cloud services, and it also lists the proposed Cloud and AI Development Act (CADA) there. "Proposed" is the key word: a draft does not yet create review items for your team. Plan measures only once the adopted text is available, and check the status directly on the Commission's page rather than in secondary sources.
Data Act: a date that shows up in contracts
According to a study by the German Economic Institute covering the cloud rules in the Data Act, the regulation entered into force on 11 January 2024 and applies EU-wide from 12 September 2025. This does not amount to legal advice for day-to-day work, but it does raise a review question: which clauses on provider switching, data export, and termination appear in your current cloud contracts, and when were they last updated? Assessing whether those clauses are sufficient is a matter for legal counsel.
Standards and codes of conduct
BSI C5 is the criteria catalog of the Federal Office for Information Security for cloud services; it describes requirements against which an auditor can assess a provider. The EU Cloud Code of Conduct is a set of rules that providers can join; its operators describe it as a tool providers can use to demonstrate compliance to customers and supervisory authorities, and they maintain a public register. For you as a customer, this means: look up the register entry yourself, don't just trust the logo on the provider's page.
Where "EU hosting" falls short as evidence
The region shown in the customer portal is only the storage location of the primary data. Personal or confidential data leaves the region by other routes, and these are exactly the routes experienced buyers ask about. A more detailed tiered list for questionnaire tools can be found in EU Data Residency Questionnaire Tool: 11-Point Checklist.
Subprocessors
A provider with an EU data center may use additional service providers for email delivery, error reporting, payment processing, or AI features. Each of these has its own locations. Check the list of subprocessors line by line for registered office, processing location, and purpose. If a processing location is missing for an entry, that is an open question for the provider, not a minor detail.
Support and administrator access
Stored in Frankfurt, administered from a third country: this combination occurs when support teams operate around the clock across multiple time zones. Ask specifically from where personnel can access customer data, under what conditions, and whether that access is logged.
Backups, logs, and telemetry
Backup copies are not necessarily located in the same region as production data. Logs often contain email addresses, IP addresses, or file names. Telemetry occasionally runs through global services. Three questions are enough to get started: Where are backups stored? Where are logs processed? What data does the telemetry contain?
12-point review checklist for a single cloud service
This checklist is designed for one service, not your entire stack. Work through it per provider and note the specific document with its date for each point. A point without a document counts as open.
Layer 1: Role and law
- Role clarified: Is the provider a processor, an independent controller, or both for different data? Record the result in writing.
- Data categories captured: Which personal and confidential data flow into the service? Is there an entry in the record of processing activities?
- Third-country transfer reviewed: Is there processing outside the EU, including via subprocessors? If so: what basis does the provider cite, and has your legal counsel assessed it?
Layer 2: Standards
- Certificate with scope: Does the scope cover the service you actually use, or only the data center or a different product line?
- Validity: Is the certificate's expiry date or the report's audit period noted?
- Register entry: For self-commitments such as the EU Cloud CoC, has the register entry itself been checked, not just the logo?
Layer 3: Contract
- DPA signed: Is the current version filed with a date?
- Change notifications: How and with what notice period does the provider inform you of new subprocessors? Who on your team receives this notification?
- Exit: What does the contract specify regarding data export, format, and deletion after termination?
Layer 4: Operations
- Region actively selected: Configuration export or dated screenshot of your account's region setting.
- Access: Who on your side has administrator rights, and when was the list last reviewed?
- Ownership: A named person is responsible for this service and has a date for the next review in the calendar.
A simple assessment: nine or more documented points mean you can answer customer questions about this service from existing documents. Below that, answers tend to come from memory under pressure, and that's where contradictions between two questionnaires begin.
Worked example: how many pieces of evidence a cloud stack generates
A fictitious SaaS company uses six cloud services: hosting, database, email delivery, error monitoring, ticketing system, and file storage. Each service generates at least four documents: certificate, audit report or register entry, DPA, and subprocessor list.
| Metric | Value in the example |
|---|---|
| Cloud services | 6 |
| Documents per service | 4 |
| Total documents | 24 |
| Review interval | annual |
| Reviews per month at an even distribution | 2 |
| Total checklist items | 72 (6 × 12) |
Two reviews a month are manageable. The math becomes a problem when all 24 documents need reviewing in the same week because a large customer sends a questionnaire. So schedule your reviews according to certificate expiry dates, not according to when customer requests arrive.
The typical mistake in such teams: the documents exist, but nobody knows which version is current. Anyone who cites an outdated subprocessor list in a questionnaire is delivering a wrong answer backed by a real piece of evidence.
What's worth doing in November and December
For many teams, year-end budget planning, contract renewals, and preparation for audits in the new year all coincide. If that applies to you, three tasks are well placed in these weeks:
- Collect expiry dates: Gather all certificates and audit reports from your cloud providers into a list with expiry dates. Follow up with the provider now on anything expiring in the first quarter.
- Read contracts before renewal: If an automatic renewal is coming up, this is the last point at which you can review export and subprocessor clauses without time pressure.
- Monitor regulatory drafts, don't anticipate them: For the proposed CADA, the rule is: follow the status on the Commission's page, but don't build internal processes around a text that hasn't been adopted yet.
This article deliberately does not name specific deadlines for your organization. They depend on industry, size, and contracts, and belong in a discussion with your legal counsel.
Where security questionnaires come into play
Customers rarely check your cloud compliance with an audit; usually it's with a questionnaire. The points from the checklist reappear there: where is the data located, who are the subprocessors, which certificates exist, how does the exit process work. Anyone who has filled out the checklist once per service can answer these questions from documents instead of from memory.
Automation helps at one clearly defined point: drafting. A tool can pre-draft answers from your uploaded policies, DPAs, and certificates, and attach a citation to each answer. The decision on whether the answer is correct and whether the cited document is still current remains with a human. Compliance Concierge is built this way: hosted in Frankfurt, drafts with cited evidence from your own documents, and nothing is exported without human review. It does not replace a legal assessment of your cloud usage.
For how to tie statements cleanly to current evidence, see Evidence-Based Compliance Answers: A Practical Framework. Criteria for choosing a tool can be found in Compliance Questionnaire Software: A 14-Point Buying Framework.
Frequently asked questions
What is cloud compliance?
Cloud compliance refers to the ability to demonstrate, for the cloud services in use, that legal requirements, agreed standards, and contracts are being met. It covers not just the provider but also your own configuration and your own responsibilities. Without dated evidence, it remains a claim.
What does EU compliance mean in a cloud context?
This usually refers to compliance with EU law such as the GDPR and the Data Act when using cloud services, supplemented by standards and codes of conduct that customers contractually require. Which regulations apply to your organization is a case-by-case question for legal counsel. Operationally, it starts with a complete list of your cloud services.
Does the GDPR only apply in Europe?
This is governed by the territorial scope in Art. 3 GDPR, which can also cover cases outside the EU. Whether it applies to your organization or one of your providers should be assessed by your legal counsel. In practice, this means: a provider based outside the EU is not a reason to skip the GDPR questions in the checklist.
Can answering security questionnaires about the cloud be automated?
Drafting can be automated; sign-off should not be. Tools can pre-draft answers from your documents and support them with citations. Checking whether the document and the answer are current belongs in human hands before export.
From guidance to finished work
Answer the next questionnaire with evidence.
Upload the questionnaire and the policies behind it. Compliance Concierge drafts cautious, cited answers while every final decision stays with a human reviewer.