Ceph for EU sovereign cloud and data residency

Why Ceph fits an EU sovereign cloud and where it does not help on its own

Ceph is open-source software licensed under LGPL, and it runs in infrastructure your organization controls, but sovereignty and residency come from where the data sits, who can reach it and who holds the keys, not from the software itself. The project's source is licensed under LGPL-2.1 or LGPL-3, and the project does not sell a paid edition, so there is no vendor cloud in the path and no licence fee tied to a provider's data centers. That removes one dependency, but it does not decide whether a transfer occurs. A cluster hosted in a third-country data center, administered over a remote session from outside the EEA, or backed up to a foreign provider still produces the transfers and access exposure that the EDPB describes in its guidelines on Article 3 and Chapter V of the GDPR. Those decisions belong to the controller and must be documented before the cluster is built.

What changes for your team is that you operate the platform yourself. Ceph is deployed and upgraded with cephadm, which manages the cluster as containers, so the people who run it need skills in cluster lifecycle, monitor and OSD health, network design and key management. Nobody else patches the cluster, rotates its credentials or decides when it moves to a new release such as Tentacle or Squid, so those tasks need named owners, a maintenance window and a tested rollback. Because there is no paid edition from the project, support comes from your own staff, from a commercial partner you contract, or from community channels, and the contract you sign should say which. Your organization also keeps responsibility for physical access, jurisdictional review of any operator or subcontractor with administrative access, and evidence that the controls work.

Confirm three things before you commit to a design: which jurisdiction hosts every site, replica and backup, which legal entities and staff can administer or view the cluster, and where the encryption keys are generated and stored. Ask whether any third-country authority could compel a provider of your support or hosting to disclose data, because the EDPB's guidance treats that exposure as something controllers must assess before engaging a processor. Running Ceph on your own hardware removes the vendor cloud from the picture, but it does not remove these questions, and the sections that follow address placement, keys and replication in turn.

Which EU requirements shape a Ceph residency design

This table maps each EU requirement that affects where Ceph data lives, who can reach it and how you can leave a provider to the design decision it drives. Read each row as a question to answer in your architecture review, with the build consequence in the right-hand column. The main takeaway is that residency is decided by site placement, remote administration paths, key custody and exit planning together, not by the data center location alone.

Requirement	Source	What it means for the build
Transfers to third countries	GDPR Article 44 and Chapter V, which cover onward transfers and carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c)	Map every location where Ceph data, backups and replicas sit, and every party that can reach them. Each path outside the EEA needs a documented legal basis and a transfer assessment before go-live.
Remote access and storage outside the EEA	EDPB Guidelines 05/2021 (version 2.0), which treat remote access from a third country, even display-only support sessions, and cloud storage outside the EEA as transfers	Restrict administrative access to the Ceph dashboard, cephadm hosts and RGW management from approved locations. Support engineers in third countries need a documented access path, or they must not receive access.
Schrems II and Data Privacy Framework status	Case C-311/18 (16 July 2020) invalidated Privacy Shield while upholding standard contractual clauses. Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending	Do not rely on the Data Privacy Framework alone for a US-linked vendor or support provider. Confirm the appeal status before each review, and keep a fallback transfer mechanism that does not depend on the framework.
Third-country authority access (CLOUD Act)	18 U.S.C. 2713 requires covered providers to preserve or disclose data in their control wherever it is stored. GDPR Article 48 allows third-country orders to be enforced only under an international agreement in force with the EU or a Member State	Ask every operator, support firm and hosting provider whether it is subject to such orders. Where access in the clear is possible, plan client-side encryption with keys held in the EU, and record the exposure in your assessment.
Key custody and encryption	EDPB Recommendations 01/2020 state that where a provider needs data in the clear and the destination's public authority powers exceed what is necessary and proportionate, no effective technical supplementary measure can be envisioned	Keep encryption keys in an EU-controlled key manager, separate from the Ceph operators. Confirm whether the chosen RGW or client encryption design lets the storage provider read plaintext, because that choice determines your residual exposure.
Non-personal data and switching rights	EU Data Act Article 32 (Regulation (EU) 2023/2854) on third-country access to non-personal data. Switching rights apply from 12 September 2025, with a maximum two-month notice period and 30-day transition, and switching charges are banned from 12 January 2027 (Articles 25, 29 and 50)	Design an exit plan from the start: documented export of buckets, block images and metadata, and a tested path to on-premises infrastructure or another provider. Ask providers how they support the notice and transition periods.
Critical sector obligations	NIS2 (Directive (EU) 2022/2555) covers central government entities regardless of size and lists public administration as highly critical, with Member States free to extend it to local administration. It excludes national security, public security, defense and law enforcement	Confirm with counsel whether your entity is in scope and in which Member State. If it is, the residency design must also support incident reporting, supply chain controls and continuity requirements that your regulator sets.

How site placement and remote administration create transfers

Storing personal data in a cloud outside the EEA is a transfer under GDPR Chapter V, and so is remote administration that lets someone in a third country view that data. EDPB Guidelines 05/2021 treat even a support engineer displaying data on a screen as a transfer. For a self-operated Ceph cluster, that means every location holding data counts: OSD hosts, monitors, RGW endpoints, backup targets, and the paths administrators use to reach them. Map each component to a physical site and a jurisdiction, and record where the cephadm management host, the Dashboard, SSH sessions and vendor or contractor VPN endpoints sit. Confirm with your contractors which country their engineers connect from, because a support session from outside the EEA can create a transfer even when the data never leaves your data center.

The guidelines also address a subtler case. Using an EU processor that is subject to third-country law with extraterritorial effect is not in itself a transfer, but complying with a request from that third-country authority would be. Before you engage any operator, support partner or hosting provider for a Ceph estate, assess that exposure in writing: which laws apply to the provider's parent company, whether it could be compelled to hand over keys, configuration or data, and what contractual and organizational limits it can offer. Note that the 18 U.S.C. 2713 preservation and disclosure duty applies regardless of where data is located, so location alone does not settle the question.

Where a provider must access data in the clear and foreign public authority powers go beyond what is necessary and proportionate, EDPB Recommendations 01/2020 state that the EDPB cannot envision an effective technical supplementary measure. In practice, encryption with keys held only by you (for example, client-side or RGW server-side keys managed in your own vault) fails if the operator also controls the running cluster and its administration. Treat this as a design decision made before deployment: decide who holds keys, who can reach the monitors and OSD hosts, and whether a foreign-law exposure is acceptable for the data in scope. Confirm the answer with your legal counsel and data protection officer, since DeployOpen does not issue legal conclusions on transfer assessments.

Ceph settings that enforce residency: placement, encryption and access

Residency on Ceph is enforced by settings, not by intent. The cards below cover where data lands, how it moves between daemons and sites, how operators and users authenticate, and who can reach the cluster's administrative paths. Each control is a configuration decision you can test, and each one needs confirmation against the release you deploy.

CRUSH rules pin pools to EU sites

CRUSH failure domains determine where Ceph places each replica. Define datacenter or room buckets for your named EU sites, then write CRUSH rules that select only those buckets for each pool, so a replica cannot land in a site you have not approved. Confirm the rule with ceph osd crush rule dump and test placement after adding hardware, because a default rule that spans every host can silently place data outside the intended sites. Ask your team to verify the rule for each pool, including the metadata and RGW index pools.

RGW multisite limited to approved jurisdictions

Ceph Object Gateway multisite replicates buckets between zones. Only add zones in jurisdictions your residency rules allow, and treat every zone as a transfer endpoint: under the EDPB's reading, storage in a cloud outside the EEA is a transfer. Review zone and zonegroup definitions and replication policies on each change. Check that no zone is added for disaster recovery in a third country without a documented legal basis, and confirm the multisite configuration against the current Object Gateway documentation for your release.

msgr2 secure mode for daemon traffic

The messenger v2 protocol listens on port 3300. Its secure mode encrypts all post-authentication traffic between daemons and clients with AES-GCM and adds integrity checks, which keeps data in transit unreadable on links you do not fully control, such as inter-site or leased fiber. Set the secure mode options in the cluster configuration and confirm with a packet capture that payloads are not visible. Verify that clients on older kernels or libraries negotiate the mode, because a fallback to an unencrypted connection would defeat the control.

Dashboard SSO with your identity provider

The Ceph Dashboard supports single sign-on through SAML 2.0, and through OAuth2 when cephadm deploys the Management Gateway and OAuth2 Proxy services. Connect it to your own identity provider so that administrator accounts, MFA policy and deprovisioning follow your HR and access processes, not local dashboard users. Test that disabling a user at the identity provider blocks dashboard access, and confirm the SSO method supported by your release before you design the flow.

RGW authentication and OPA access rules

The Object Gateway can authenticate users through Keystone or LDAP, and integrates with Open Policy Agent for access decisions. Use your directory as the source of truth for who may read or write each bucket, and use OPA policies to express residency conditions such as allowed source networks or data classes. Confirm the authentication backend and OPA integration against the documentation for your release, then test denied requests from outside the approved network to prove the policy is enforced.

Admin paths without standing foreign access

Residency fails quietly when an outside vendor or operator keeps SSH keys, cephadm access or a support account on the hosts. Limit cephadm host access to named EU administrators through your own key management, remove vendor standing accounts, and record every administrative session. Ask for a written list of who can reach each host, orchestrator, and dashboard path, and review it at each change. Any remote support access must be time-limited and must not expose data in the clear to a third country, which is a transfer under the EDPB guidelines.

Encryption with your own keys: what Ceph covers and what you must design

The organization should hold key custody inside the EU, and the design must say in writing where encryption keys are generated, where they are stored, how and when they are rotated, and who can revoke them. Encryption features in Ceph do not answer those questions on their own. Whether a release can use keys held in an external key manager, how keys are supplied to OSDs and gateways at boot, and how a revoked key makes data unreadable are all points to confirm against the documentation for the release you choose, either Tentacle (20.2.x) or Squid (19.2.x). Squid's estimated end of life is October 31, 2026, so a new design that picks Squid needs a dated upgrade path before it goes live.

Encryption at rest protects drives that leave the building, but it does not remove the key-custody question. If the key holder is a vendor, a managed key service or a parent company outside the EU, the keys sit within reach of a third-country authority, and the exposure described in EDPB Recommendations 01/2020 still applies. Decide who operates the key service, which legal entity controls it, and whether the same people can reach both the keys and the storage. Ask the key-management vendor where its operators sit and which law governs its access requests before you rely on its key material.

Test revocation and recovery before production. Run a drill that disables a key, confirms the affected pool or bucket can no longer be read, and then restores access from an escrowed copy held in the EU. Record the result as evidence for your transfer assessment and your auditor. Keep rotation and revocation procedures in your runbook, with named approvers who sit inside your own jurisdiction.

How a sovereign Ceph rollout runs from data mapping to exit testing

This sequence turns a residency requirement into a Ceph cluster whose data locations, administrative access, key custody and exit path can each be shown to an auditor. Each phase closes with a written record that the next phase depends on.

Map personal and non-personal data flows
The organization's data owners, privacy lead and architects list every dataset that will sit on Ceph, the systems that create or read it, and every point where it leaves the intended boundary. The list covers replicas, backups, logs, support tickets and remote administration sessions, because the EDPB guidelines treat remote viewing from a third country as a transfer, not only storage. The step is done when each data flow has an owner, a legal basis or classification, and a marked transfer point or a confirmed absence of one.
Decide site and jurisdiction per pool
For each RADOS pool, RGW bucket class and backup target, the team records the physical site, the operating legal entity and the jurisdiction whose law applies to the operator and to any hosting provider. Placement rules in the CRUSH map should keep replicas inside the chosen sites, and the design should state which failure domains can cross a border. The output is a placement table that the storage engineers and the compliance lead both sign, with any cross-border replication either removed or documented as an accepted transfer.
Design and record the admin and support access path
Map who can reach the cluster management plane, the Dashboard, SSH access to cephadm hosts and vendor or integrator support sessions, and from which networks and countries each path can be used. Remote support from outside the EEA counts as a transfer, so the design either keeps administration inside the jurisdiction or documents the exception. The step closes with an access register listing each named account, its location and approval route, reviewed against the placement table from the previous step.
Deploy with cephadm or Rook and confirm maintenance status
The installer deploys the cluster with cephadm on bare metal or VMs, or with Rook when the platform is Kubernetes, and only on a release the Ceph releases page lists as actively maintained. The team records the exact release, its estimated end-of-life date and the patch cadence it will follow. Done means a bootstrapped cluster with hosts, monitors and services reporting healthy, plus a version record that the security owner can compare against the project's published support dates.
Validate msgr2 secure mode, RGW boundaries and key custody
In a test cluster before production data arrives, the engineers confirm that messenger v2 secure mode encrypts post-authentication traffic on the expected ports, that RGW multisite replication only reaches the approved zones, and that encryption keys for data at rest are generated, stored and rotated under the organization's control. They also test that a key holder outside the organization cannot read the data. The step ends with recorded test results for each claim, including any gap found and its fix, so no residency statement rests on configuration alone.
Document the exit path under Data Act switching rights
The team writes a runbook that shows how data would move from the cluster to another provider or to on-premises infrastructure. It covers export formats for RGW buckets and RBD images, the network and capacity needed for a bulk transfer, the notice and transition steps the Data Act sets for switching, and the point at which the organization can stop paying for the old environment. The runbook is tested with a sample dataset, and the result is a dated exit procedure owned by a named person, which is what an auditor or regulator will ask to see.
Hand over evidence for auditors
The team assembles the artifacts an assessor will request: the data flow inventory, the placement and access registers, the release and patch record, the secure-mode and multisite test results, key custody procedures and the exit runbook. DeployOpen prepares this evidence and the controls it supports, but the organization's auditors or certification bodies decide whether the requirements are met. The handover is complete when the organization's compliance owner confirms they can trace each residency claim to a test result and an owner.

Residency options for Ceph: single EU site, multi-site EU or hybrid

A single-site design keeps the cluster, its monitors, OSD hosts and gateways in one EU facility, with an off-site copy held in another EU location. Residency is the simplest to prove because every component and every replica sits inside one jurisdiction you already control. The cost is a larger shared failure domain: a facility outage, a power or network event at that site, or a failed cluster-wide change can stop access until recovery completes. Recovery depends on the off-site backup, so its restore time and its completeness matter more than in a multi-site design.

Residency boundary: all production data, monitors and key material sit in one EU facility, and the backup target is in a second EU location you name in the contract.
Failure domains: CRUSH rules separate replicas across racks and hosts, but they cannot protect against loss of the whole room, so the site itself is the blast radius.
Backup transport: the off-site copy travels over links you own or contract, and the transfer path must stay inside the EU.
Operations access: remote administration from outside the EU counts as a transfer under EDPB guidance, so support access paths need to be restricted to EU locations.
Recovery testing: restore drills from the off-site copy show whether your recovery objectives are achievable in practice.

Before committing, confirm with your legal team which EU locations satisfy your contracts, and ask the implementation partner to show the restore procedure, the access paths and the evidence of each drill.

Questions EU buyers ask before outsourcing a sovereign Ceph build

Does open-source Ceph by itself make our data sovereign?

No. Ceph is software, and its LGPL licensing gives you the right to run and inspect it, but sovereignty comes from where the hardware sits, who operates it, who holds the encryption keys and which jurisdictions can compel access. A Ceph cluster in a data center you control, operated by staff you employ, with keys you hold, meets those conditions. The same cluster run by a provider with remote administrators abroad does not. Under GDPR Article 44, every transfer to a third country needs a Chapter V basis, and EDPB Guidelines 05/2021 treat remote access from outside the EEA as a transfer, even when the data is only displayed on a screen. Map your administrative access paths as carefully as your storage locations.

What drives the cost of a sovereign Ceph build?

Cost follows five components: the number of sites and their placement, hardware for each site, key custody, testing, and audit evidence. Sites multiply hardware, network and power, and every extra jurisdiction adds legal review. Hardware depends on capacity, failure domains and media choices described in the Ceph hardware recommendations, which advise a dedicated drive per OSD and bonded links across two switches. Key custody may require an HSM or a separate key service. Testing covers failover between sites and restore drills. Most of the build is one-time work: design, deployment, hardening and documentation. Recurring costs include hardware refresh, staff or retainer time, patching, and periodic testing. Ask any provider to split the quote into one-time and recurring lines, and to name who buys the hardware.

How long does a sovereign Ceph build take?

The duration depends on your environment more than on Ceph itself. The main factors are the number of sites, whether hardware is already installed, how many data categories need legal classification, how quickly your legal and security teams can answer questions, and whether identity integration and key custody are settled before deployment. Ceph deployment through cephadm, which the cephadm documentation describes as managing a cluster in containers, is the fast part. Residency mapping, contract review and evidence collection usually take longer. Most engagements are fixed-scope, so the written scope should state each milestone and the client dependencies behind it. Ask for the schedule to show which items wait on your decisions.

Can our own team build a sovereign Ceph cluster without a partner?

Often yes, if the team already runs Linux, networking and storage at production scale. Ceph has a large operational surface: monitors, OSD placement, network design, upgrades, recovery tuning and incident response. The cephadm documentation covers deployment, but design decisions such as failure domains, placement groups and media choices shape the cluster for years. Before deciding, check whether you have staff who have rebuilt a failed OSD, planned a major upgrade and tested a restore from backup. Also check whether you have people who can write residency and key custody policy. A partner is most useful when the team needs a fixed-scope design, a documented build and a handover, rather than ongoing operations.

What do we need to provide for a sovereign Ceph engagement?

The provider needs decisions and records from your side before design can close. Typical inputs are:

A data map listing categories, owners, storage locations and which jurisdictions may access each category.
Legal review of transfer analysis, including whether any processor or vendor has third-country exposure.
Identity decisions for administrator and dashboard access, such as the single sign-on method used by the Ceph Dashboard, which supports SAML 2.0 and OAuth2 under the conditions in its documentation.
Confirmed sites, power, cooling, network paths and physical access rules.
Named staff for approvals, acceptance testing and handover.

If these inputs arrive late, the schedule moves. Ask the provider to list them in the written scope with owners and dates.

Does a foreign vendor's support access break data residency?

It can. Remote access from a third country is a transfer under EDPB Guidelines 05/2021, even if a support engineer only views a screen. Encrypted storage does not remove this exposure when the person administering the cluster can reach plaintext or keys. The guidelines also note that using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be, so controllers should assess that exposure before engaging the processor. The US CLOUD Act provision at 18 U.S.C. 2713 applies to providers regardless of data location. Define support access in the contract: who may connect, from where, under what logging and approval, and with which keys. Confirm each point with your legal counsel.

Does DeployOpen issue audit reports or certifications for our Ceph cluster?

No. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your infrastructure, and it prepares systems, controls and evidence for compliance assessments. Independent auditors and certification bodies issue audit reports, attestations and certifications. For a sovereign build, the deliverables typically include architecture records, configuration baselines, access and key custody procedures, and restore test results that your auditor can review. Ask your auditor which evidence they expect before the design is fixed, because the same cluster can produce very different evidence depending on logging, change control and access records.

Compliance evidence EU and sector regulators will ask for

Regulators and auditors will ask where data sits, who can reach it, and how you recover it. The cards below cover the EU obligations most likely to shape a self-operated Ceph design, and the evidence your team should prepare for each. DeployOpen prepares systems, controls and documentation; independent auditors and certification bodies issue the opinions.

GDPR transfer mapping and Article 44

Article 44 applies to every transfer of personal data to a third country, including onward transfers. For Ceph, map every location where objects, backups, snapshots and replicas land, and every place an administrator can view data remotely, since the EDPB treats remote display for support as a transfer. Keep a current map of sites, cloud regions and support access paths, and record the legal basis for each. Maintain the transfer map as a living document. Ask your counsel which transfer tools apply to any non-EEA support or backup target.

Article 48 foreign disclosure requests

Article 48 allows a third-country court order to be recognized only when it rests on an international agreement, such as a mutual legal assistance treaty. Your Ceph design should show who holds encryption keys, which operators have administrative access, and whether any vendor or support provider is subject to foreign disclosure law. Document your procedure for receiving a foreign request, including legal review and notification steps. Confirm with counsel how a request would be routed before one arrives.

Data Act switching and Article 32 measures

The Data Act has applied since 12 September 2025 and gives customers the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Article 32 requires providers to prevent third-country government access to non-personal data held in the Union. For a self-operated Ceph cluster, prepare an exit runbook covering export formats for RGW buckets and RBD images, and document how your own cluster meets the switching obligations of the service you offer.

NIS2 scope for public administration

NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration. Articles 2 and 3 exclude entities working in national security, public security, defense or law enforcement. Confirm with your national authority whether your body is in scope and which exclusions apply. If it is, prepare risk management records, incident reporting procedures and evidence of Ceph patch cadence against the supported release branches.

DORA resilience and backup obligations

Regulation (EU) 2022/2554 (DORA) requires financial entities to manage ICT risk, including backup policies, recovery procedures and oversight of ICT third-party providers. For Ceph, the evidence set typically includes documented failure domain design, tested restores from replicated or erasure-coded pools, and records showing segregation between production and backup clusters. Ask your compliance team which RTO and RPO targets they must evidence, since those figures come from your own risk assessment, not from Ceph.

US-linked party controls

Only where the buyer or a contract partner is US-linked does the NIST and FedRAMP scope apply. NIST SP 800-53 Rev. 5 is the federal control catalog, and Release 5.2.0 of 27 August 2025 is current. FedRAMP applies to cloud services that hold federal information on behalf of an agency. A self-operated Ceph cluster inside your own data center is usually outside FedRAMP scope, but a shared storage service offered to agencies may not be. Confirm the boundary with the contracting agency before mapping controls.

What counsel and the data protection officer must decide

Technical design cannot settle the legal questions in a sovereignty project. Whether a foreign processor's exposure to third-country law is acceptable, whether a transfer exists at all, and whether the parties need *Standard Contractual Clauses* under Commission Implementing Decision (EU) 2021/914 are decisions for counsel and the data protection officer. The EDPB guidelines treat remote access from a third country, even display-only support access, as a transfer, so the legal team must decide which access paths count and who holds them. The technical team's job is to supply accurate facts: where each Ceph component runs, who can reach the Dashboard, RGW and cephadm hosts from outside the EEA, and which support tools export data or logs. Those facts should be written down before counsel reviews the processor relationship.

Transfer assumptions also need a review date. The Data Privacy Framework adequacy finding in Commission Implementing Decision (EU) 2023/1795 is under appeal as Case C-703/25 P, so any design that relies on a US vendor or US-based support staff being covered by that finding should be re-checked when the appeal resolves. The organization owns that outcome and the decision to proceed, and should record which transfer tool each supplier depends on and who is responsible for re-running the assessment. Counsel should also confirm the extraterritorial exposure described in the CLOUD Act provision at 18 U.S.C. 2713 for any provider with a US parent, since this affects the assessment regardless of where the cluster sits.

How DeployOpen scopes and delivers sovereign Ceph implementations

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph for EU sovereign cloud and data residency. We start from a written scope that fixes where data sits, who can operate it and how it is protected, then build and verify the cluster in your cloud accounts, data centers or air-gapped network.

How we scope

Map every data class to the jurisdictions where it may be stored, processed and accessed by staff.
Record which personnel, support paths and remote access routes could reach the cluster from outside the EU.
Agree the written scope, deliverables and timeline in writing before any build work starts, with fixed-scope engagements as the default.

How we build

Design CRUSH failure domains and replication so copies stay within the sites you select for residency.
Configure cephadm deployment, encryption in transit and key handling in line with the agreed scope and your own key management choices.
Test failover, placement and access controls against the written requirements, then record the results as evidence.

How we hand over

Document the cluster topology, site placement rules, key custody, access model and backup layout as delivered.
Provide runbooks for drive replacement, upgrades between Ceph releases and access reviews, written for your own operations team.
Prepare control evidence for your compliance assessors, while noting that independent auditors and certification bodies issue any formal opinion.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Review residency and access controls again when Ceph releases, legal requirements or your sites change.
Confirm with your legal and compliance teams which transfer and access conditions apply before you finalize the design.