ISO 27001 for EU IaaS: Evidence, Scope & Provider Selection
ISO/IEC 27001 certification shows that a named organisation operates an audited information security management system (ISMS) within a stated scope. It does not certify every product as secure, guarantee that no breach will occur, prove GDPR compliance, establish a lawful international transfer, or make a cloud region legally isolated. For IaaS selection, the certificate is one evidence item in a wider technical, contractual, and jurisdictional assessment.
Read the certificate before trusting the badge
The current standard is ISO/IEC 27001:2022, with a 2024 climate-action amendment listed by ISO. Ask for the certificate itself and verify the legal entity, certificate number, certification body, accreditation, standard edition, validity, covered sites, and exact scope. A group logo on a website may not cover the contracting entity, chosen datacentre, support organisation, or every service in the catalogue.
Request the relevant statement-of-applicability information, audit boundaries, and exclusions. The standard requires a risk-management system; it does not prescribe one identical set of controls for every provider. Certification also does not reveal whether a particular storage service encrypts data with customer-controlled keys, whether support staff can access a tenant, or how quickly a failed restore is detected. Those are service-specific questions.
Separate management-system assurance from product assurance
Evaluate the actual workload and shared-responsibility boundary. For IaaS, the provider may secure facilities, physical hardware, and defined control-plane services while the customer remains responsible for operating-system patches, workload identity, network policy, application security, secrets, backups, and incident detection. Obtain a responsibility matrix for each managed service; broad “security is shared” wording is not testable.
Ask for architecture and penetration-test summaries where available, vulnerability and patch processes, incident-notification terms, support-access controls, tenant-isolation design, audit-log availability, backup scope, restoration evidence, and service history. Verify controls in a pilot: revoke an administrator, rotate a key, restore data, inspect audit events, and confirm what the provider can see. Certification cannot substitute for these exercises.
Assess GDPR roles and transfers independently
The GDPR imposes duties based on the processing, purposes, parties, and risks. A customer generally needs a data map, lawful basis, processor terms where applicable, subprocessor review, retention and deletion design, security measures, and support for data-subject rights. An ISO 27001 certificate is not a GDPR certification under Articles 42 and 43.
“Data stored in the EU” does not describe the whole processing chain. Map primary storage, replicas, backups, DNS, telemetry, billing, abuse handling, remote support, and subprocessors. Identify which entity can access data and from where. For transfers, document the applicable mechanism and any supplementary measures. The European Commission currently lists the United States as adequate only for commercial organisations participating in the EU–US Data Privacy Framework; participation and processing scope must be checked rather than assumed.
Treat jurisdiction as a legal fact pattern, not a slogan
A provider's incorporation and datacentre location matter, but neither alone answers every access question. Relevant facts include corporate control, establishment, custody or control of the data, subprocessors, contractual structure, encryption-key control, applicable orders, and conflict-of-law procedures. The US CLOUD Act text addresses provider data within US jurisdiction, including data stored abroad, and contains mechanisms for conflicting legal obligations. Applying it to a specific architecture requires qualified legal analysis.
Therefore, do not label a European provider “CLOUD Act-free” or a US-headquartered provider automatically unsuitable. A European company can use non-European subprocessors or belong to a wider group; a global provider may offer relevant contractual, technical, and key-control measures. State the threat model—government access, commercial lock-in, support access, concentration risk, or operational autonomy—and compare evidence against it.
Compare EU IaaS providers with a workload scorecard
| Area | Evidence to obtain | Failure test |
|---|---|---|
| Scope and assurance | Certificate, scope, entity, sites, exclusions, audit reports | Chosen service or location falls outside scope |
| Data path | Regions, replicas, backups, support, subprocessors, deletion timing | Telemetry or recovery copy crosses the intended boundary |
| Key control | Ownership, rotation, revocation, recovery, provider access | Customer loses keys or provider access is broader than expected |
| Operations | SLOs, maintenance, quotas, incident process, restore evidence | Zone loss, control-plane outage, or failed restore |
| Portability | Formats, APIs, egress limits, images, infrastructure definitions | Export and rebuild on a second environment |
| Economics | Compute, storage, snapshots, traffic, support, committed-use terms | Normal growth and incident-driven traffic |
Weight the scorecard by the workload. A static public service and a regulated health system do not need the same controls. Run a representative deployment and recovery exercise before commitment, and retain an exit plan in formats that do not require the provider's control plane. The defensible choice is the provider whose scoped evidence and operating model satisfy the documented risks—not the one with the most certification logos.
Published · Updated