Data residency answers where data sits. The US CLOUD Act raises a different question: who can be compelled to hand it over. Since 2018, a provider subject to US jurisdiction can be required to disclose data in its possession, custody or control even when that data is stored outside the United States. For storage teams, that shifts the analysis away from the location of the disks and toward the organizations that operate, support and hold keys for the system on top of them.
This post looks at what the law covers, which parts of a storage architecture it can reach, and the design choices that change the answer. It is not legal advice, and any assessment of a specific deployment belongs with counsel. The architectural questions, though, are ones IT and storage teams are best placed to answer.
What the CLOUD Act does
The Clarifying Lawful Overseas Use of Data Act was passed in March 2018. It amended the US Stored Communications Act so that providers of electronic communication services and remote computing services must comply with valid US legal process for data within their possession, custody or control, regardless of whether that data is located inside or outside the United States.
The law followed a dispute over whether a US warrant could reach email stored in a data center in Ireland. Rather than resolving that question in court, Congress clarified that location alone does not put data beyond reach. The act also created two related mechanisms:
- A challenge process. A provider can move to quash or modify a request if the customer is not a US person, does not reside in the US, and disclosure would create a material risk of violating the laws of a qualifying foreign government.
- Executive agreements. The US can conclude bilateral agreements with other countries that allow each side's authorities to request data directly from providers in the other's jurisdiction, under agreed safeguards. The UK and Australia have such agreements in place.
In the EU, the tension is most often discussed alongside Article 48 of the GDPR, which provides that a foreign court or authority's demand to transfer personal data is only recognized when based on an international agreement such as a mutual legal assistance treaty. A provider can therefore face conflicting obligations, a situation explored further in the overview of who controls your data.
Why location alone is not the answer
A common assumption is that placing data in an EU region of a US-headquartered provider settles the question. Under the CLOUD Act it does not, because the test is control, not geography. If the provider, or its parent company, can access the data, the data may be within reach regardless of which country hosts the hardware.
The same logic applies inside a customer-operated environment. If a US-subject vendor has standing remote access to the storage system for support, telemetry or management, that access path is part of the analysis. The storage is on premises, but control over it is partly shared.
Where jurisdiction can reach a storage architecture
A useful exercise is to list every party that can read data, read metadata, or change the system, and note which jurisdictions each is subject to. The table below shows the usual touchpoints.
| Touchpoint | Question to ask | Why it matters for CLOUD Act exposure |
|---|---|---|
| Storage operator | Who runs the system day to day? | A service provider operating the platform has possession or control of the data |
| Encryption keys | Who can access or recover the keys? | Encrypted data is only readable by whoever controls the key service |
| Vendor support access | Can the vendor connect remotely, and is it standing or on request? | Standing access may amount to control over data or systems |
| Telemetry and logs | What leaves the environment, and where does it go? | Object names, bucket names and access logs can be sensitive on their own |
| Replicas and backups | Where do copies go, and who runs those sites? | A second copy at a US-controlled service reintroduces exposure the primary avoided |
| Management plane | Is the control console hosted by a third party? | Control over configuration can include control over access policies |
Several of these are easy to overlook. Remote support access and telemetry that crosses data boundaries both create paths that sit outside the main data flow but still give a third party visibility or control.
Encryption and key custody
Encryption is often presented as the answer to extraterritorial access, and it does change the picture, but only if the party that could be compelled cannot also decrypt. If a provider stores the data and also manages the keys, a disclosure order can reach both. If the keys are held in a key service the customer controls, inside its own jurisdiction, a compelled provider can disclose only ciphertext.
That makes key custody one of the most important design decisions in any sovereignty assessment. The practical questions are who operates the key management service, whether the storage provider has any path to key material, and how key recovery works. The details are covered in the post on who controls the encryption keys.
Design choices that change the exposure
No architecture removes legal risk entirely, but several choices narrow the set of parties that can be compelled:
- Operator independence. Running storage in-house, or with a provider not subject to US jurisdiction, removes the most direct path.
- Customer-held keys. Keeping key management under the customer's control limits what any other party can disclose.
- On-request support. Replacing standing vendor access with access granted per incident, logged and time-limited, reduces control by third parties to defined windows.
- Local telemetry. Keeping logs and metrics inside the environment, or filtering what is exported, prevents metadata from leaving.
- Contained replication. Placing replicas and backups at sites under the same operational control as the primary keeps the second copy inside the same boundary.
Each of these should be documented with evidence, because a procurement review or regulator will usually ask for more than a statement of intent.
Where Scality RING fits
Scality is a European-founded company, and Scality RING is software-defined object and file storage that runs on the organization's own servers or in a sovereign provider's facilities. Because the hardware, the network boundary and the operational model sit inside infrastructure the customer chooses, the parties able to reach data are determined by the customer's own administrative arrangements rather than inherited from a hyperscale service operator.
Geographic placement of data across sites is configured by the operator, so replicas can be kept inside the same jurisdiction as the primary. RING emits operational metrics and logs that the operator keeps locally, which allows telemetry to stay inside the environment. Those properties do not make an assessment automatic, but they let the storage layer be designed to match the boundary the organization intends.
Questions to answer before the next sovereignty review
- Which organizations can read stored data, and which jurisdictions are they subject to?
- Who operates the key management service, and can the storage provider reach key material?
- Does any vendor have standing remote access, and how is that access logged?
- What telemetry leaves the environment, and does it include object or bucket names?
- Where do replicas and backups live, and who operates those sites?
- What evidence exists for each answer, and who owns keeping it current?
The CLOUD Act made location a weaker defense on its own. Clear answers to these questions are what turn a statement about data residency into a defensible position on control.