Unit 1.4: Sovereignty and Compliance as Design Inputs
Introduction
For a regulated enterprise, compliance is not a checklist applied after the architecture is drawn; it is the first filter that narrows which architectures are even permissible. The two ideas that do that filtering are sovereignty and the specific recognitions a service holds, and both are routinely stated too loosely. Sovereignty gets conflated with where the data sits, and attestations get described as if they covered the whole platform. Both errors are dangerous in an audit. This unit fixes the precise meanings and then shows how they operate as a placement filter for FinCorp, the German financial-services firm whose every workload decision must survive a GDPR and BSI review.
1. Sovereignty Is Operator Jurisdiction, Not Just Region
European Union legal sovereignty is the principle that data is subject only to the laws and legal protections of EU member states. In a cloud context that requires the infrastructure provider, the data centers, and the governing contracts to all be based in the EU, so that foreign entities cannot compel access. The decisive word is provider, not region.
The contrast that makes this concrete is the US Clarifying Lawful Overseas Use of Data (CLOUD) Act, the federal law that lets US law enforcement compel US-based technology companies, by warrant or subpoena, to produce requested data regardless of whether that data is stored in the US or abroad. The consequence is precise and often missed: a US-operated provider running an EU region is still a US company, and so its EU-hosted data remains reachable under the CLOUD Act. Choosing a Frankfurt region from a US operator does not buy sovereignty; it buys residency while leaving the jurisdictional exposure intact. IONOS is EU-operated, which is what lets it offer sovereignty rather than only residency.
For FinCorp, this is the threshold decision. Residency alone (data physically in Germany) would satisfy a naive reading of GDPR locality, but the firm's risk posture requires that no foreign jurisdiction can compel disclosure. That requirement can only be met by an EU-operated provider, which is why the operator-jurisdiction distinction, not the region pin, is the real sovereignty control and is settled before any service is chosen.
2. The Two BSI Recognitions, Scoped Precisely
IONOS holds two distinct BSI recognitions, and the single most important habit in this unit is to never collapse them into "IONOS is BSI-certified." They differ in credential type, in date, and, critically, in which services each one covers. Always tie a claim to the service, the data-center location, the credential, its type (attestation versus certification), and its date.
- BSI C5 is an attestation (a Type 1 Testat, audited to ISAE 3000), granted 7 November 2023, for German data centers. Its scope covers exactly Compute Engine, Cloud Cubes, and S3 Object Storage. It is not a certification and not Type 2, and it does not cover Backup or Managed Kubernetes.
- IT-Grundschutz is an ISO 27001 certificate based on IT-Grundschutz, granted 14 September 2022 by the BSI, for German data centers. Its scope covers exactly Compute Engine, S3 Object Storage, Backup, and Managed Kubernetes.
The scopes deliberately differ per service. Cloud Cubes is in the C5 scope but not the IT-Grundschutz scope; Backup and Managed Kubernetes are in the IT-Grundschutz scope but not the C5 scope. Only Compute Engine and S3 Object Storage sit in both. There is no evidence of a C5 Type 2 or a TISAX recognition, so neither may be claimed. IONOS is the first German cloud provider to hold both the C5 attestation and the IT-Grundschutz certification, which is a true combined claim and a strong one, but it is a claim about two specifically scoped credentials, not about the platform as a whole.
A second layer of precision separates data-center-level from service-level credentials. Data-center certifications (ISO 27001, PCI-DSS, Uptime Tier classifications) are held by the operators of each physical site and vary by location. Berlin (IONOS-operated) and Karlsruhe (operated by TelemaxX, not IONOS) hold IT-Grundschutz at the data-center level; Frankfurt sites operated by third parties do not hold IT-Grundschutz at the data-center level even where they hold ISO 27001 directly. The takeaway is that a product-level "certified" list is marketing, not a contractual scope: the binding facts are which service, in which location, holds which credential.
The following table is the scope you may state; do not widen it.
| Recognition | Type | Date granted | Services in scope |
|---|---|---|---|
| BSI C5 | Attestation (Type 1 Testat, ISAE 3000) | 7 November 2023 | Compute Engine, Cloud Cubes, S3 Object Storage |
| IT-Grundschutz | ISO 27001 certificate based on IT-Grundschutz | 14 September 2022 | Compute Engine, S3 Object Storage, Backup, Managed Kubernetes |
Residency is the third design input and the one applied earliest. It is a placement decision made before any workload lands: you choose the region (and therefore the data center) first, and that choice constrains everything downstream, because images and reserved IPs are region-locked and because an attestation scope only helps if the workload actually lands on an in-scope service in an in-scope location. Compliance therefore narrows choices as a filter over every later decision rather than being verified at the end. For FinCorp, the regulated workload must land on services that are both EU-operated and inside the relevant attestation scope, in a German location, which is why placement is settled in Module 1 and treated as nearly irreversible.
Decision Summary
Apply compliance as an ordered filter before selecting services, not as a final audit.
| Filter | The question to answer | The precise control |
|---|---|---|
| Sovereignty | Can any foreign jurisdiction compel disclosure? | Require an EU-operated provider; an EU region of a US operator still carries CLOUD Act exposure. |
| Residency | Where will the data physically sit? | Pin region and data center first; images and reserved IPs are region-locked. |
| Attestation scope | Is this exact service, in this location, in scope? | Match the workload to a service named in the C5 or IT-Grundschutz scope; never assume platform-wide coverage. |
| Credential level | Is the credential a service-level or a data-center-level one? | Verify per service and per site; product "certified" lists are marketing, not contractual. |
State every compliance claim as service plus location plus credential plus type plus date. Never say "the platform is C5-certified."
Summary
Sovereignty is a property of operator jurisdiction, not of region, so only an EU-operated provider such as IONOS escapes the CLOUD Act exposure that a US operator's EU region still carries. Compliance attaches to specific services with scopes that differ per service, so it must be stated precisely and applied as a pre-placement filter rather than verified at the end.
Key Points:
- Legal sovereignty depends on operator jurisdiction, not region; an EU region of a US-operated provider still carries US CLOUD Act exposure, whereas IONOS is EU-operated.
- C5 is a Type 1 attestation (7 November 2023) for Compute Engine, Cloud Cubes, and S3 Object Storage; IT-Grundschutz is an ISO 27001 certificate (14 September 2022) for Compute Engine, S3 Object Storage, Backup, and Managed Kubernetes; the scopes differ per service.
- IONOS is the first German provider to hold both, which is a true claim about two scoped credentials, not a platform-wide certification.
- Data-center-level credentials vary by site (Berlin, IONOS-operated, and Karlsruhe, operated by TelemaxX, hold IT-Grundschutz at the DC level; some Frankfurt sites do not); residency is a pre-placement filter applied over every later decision.