Data sovereignty requirements in a request for proposal (RFP) should define where data may reside, who may access it, which legal entities are involved and how the organization retains control during recovery or a provider change. Each requirement needs a specific vendor response and evidence that the proposed deployment can meet it. A statement that data is “hosted locally” answers only part of that assessment.
Consider an organization that selects storage in an approved country. Its backup copy stays there, but support uploads diagnostic files abroad, a separate company administers encryption keys, and disaster recovery depends on a service outside the approved region. The primary storage location has not changed, yet the operating model contains dependencies the buyer may never have approved.
A useful sovereignty RFP makes those dependencies visible before the contract is signed. It also separates mandatory conditions from preferences, so a strong technical score cannot conceal a requirement the supplier does not meet.
Data residency describes where data is stored. Data sovereignty concerns the laws and authority affecting that data, alongside the practical controls an organization needs over access, processing and movement. Data localization refers to requirements to keep specified data or processing within a defined territory.
These distinctions matter because there is no universal specification for a sovereign storage deployment. A public agency, a multinational manufacturer and a healthcare provider may have different obligations, even when they buy the same platform. Requirements can come from legislation, customer contracts, procurement rules or internal policy.
Start the RFP with a short scope statement identifying the datasets, permitted locations, approved operating entities and applicable obligations. Assign each restriction to its source and owner. This prevents an internal preference from being presented as a statutory requirement, while keeping contractual obligations from disappearing into a general compliance questionnaire.
For example, GDPR does not impose a blanket requirement that all personal data remain in the EU. It provides conditions for international transfers, including adequacy decisions and appropriate safeguards. Remote access by a separate organization in a third country can also constitute a transfer, even when the storage remains in Europe.
Legal and privacy teams should establish the applicable boundaries. Infrastructure teams can then translate those boundaries into configurations, operating procedures and acceptance tests.
“Customer data will remain in the selected region” leaves too much room for interpretation. An RFP should identify the information covered by the restriction, including production objects, replicas, backups, snapshots, metadata, audit logs and support exports. Different categories may need different rules, but each needs an explicit answer.
For object storage, pay particular attention to names, tags and user metadata. A bucket can contain encrypted objects while its keys or logs still reveal customer names, project identifiers or sensitive business activity. Ask vendors to describe what these supporting systems collect and where they send it.
Suggested RFP wording:
Identify all locations in which in-scope data and associated metadata are stored or processed during normal operation, maintenance, support and recovery. Describe how the proposed deployment restricts placement to the approved locations and identify every exception.
Require a data-flow diagram for the offered configuration. It should show storage sites, replication paths, monitoring destinations and any external services receiving information. A diagram of the vendor’s general product architecture is insufficient if it omits the managed services included in the bid.
The important follow-up is what happens when a site fails or capacity runs short. Ask whether any automated process can place data outside the approved locations and how such a configuration would be prevented or detected.
A locally hosted platform may still be administered by people or organizations operating elsewhere. The RFP should distinguish access to object contents from access to the systems that control those objects. An administrator who cannot read a file may still be able to change replication, reset permissions or delete a recovery copy.
Require vendors to identify the legal entities providing support, their access locations and the privileges available to each role. Include infrastructure operators and subcontractors wherever they can affect the deployment. Document both routine maintenance and emergency access.
Suggested RFP wording:
Describe all supplier and subcontractor access to the proposed environment. State which actions require customer approval, how privileges are limited in duration and scope, and how access can be revoked and audited.
Ask for a demonstration of a support session from approval through termination. The buyer should be able to see who connected, what permissions were granted and which actions were recorded. Any emergency process that bypasses normal approval needs its own controls and evidence.
“Customer-managed encryption keys” can describe materially different arrangements. A customer might control key rotation while a provider-operated service remains able to request decryption. Another design may keep key administration separate but still allow a privileged operator to access plaintext through the application.
The RFP should establish who generates, stores, backs up, restores and authorizes use of each relevant key. It should also identify who can change the permissions governing that use. These questions are more useful than asking only whether encryption is enabled.
Suggested RFP wording:
Provide the key-management architecture, including key custody, authorization to decrypt, administrative roles, backup and recovery. Explain whether any supplier or subcontractor can obtain plaintext or authorize decryption without customer approval.
Key ownership alone does not settle sovereignty. The assessment must consider where decryption occurs and which systems or people can access the result. An external key-management service may itself introduce a location or operational dependency.
Test failure behavior as well. Ask what happens to new writes, existing reads and recovery when the key service becomes unavailable. The response should explain any caching behavior and the recovery procedure, rather than promise that revoking a key instantly removes every possible access path.
Vendor nationality, corporate headquarters and data-center location each answer a different question. None independently establishes the legal exposure of the complete service. Procurement needs to know which entities contract with the buyer, operate the infrastructure and can access the information.
Request the relevant subcontractor chain and an explanation of applicable jurisdictions. Where international transfers occur, require the supplier to identify the transfer mechanism and supporting assessment relevant to the service. Have the buyer’s legal team review that response against the actual data and operating model.
Suggested RFP wording:
Identify the contracting entity and all entities with access to in-scope data. Describe procedures for reviewing government disclosure demands, challenging demands where appropriate, limiting disclosure and notifying the customer where legally permitted.
Avoid requirements that ask vendors to guarantee immunity from every foreign law. Instead, require disclosure of exposure, technical access limitations and contractual responsibilities. The buyer needs an assessable position, including residual risks, rather than an absolute promise that cannot be substantiated.
Sovereignty requirements must remain achievable when the primary environment is unavailable. A backup in an approved location is only one part of that design. Recovery may also depend on identity services, encryption keys, catalogs, management systems and people authorized to operate them.
Ask vendors to map those dependencies against the same location and access rules used for production. Define the recovery time objective and acceptable data loss for each workload. A recovery design that respects location restrictions but misses the business recovery target still fails the procurement requirement.
Suggested RFP wording:
Demonstrate recovery within the approved locations using the proposed identity, key-management and administrative arrangements. Identify all external dependencies and state the effect of their unavailability on recovery time and recoverable data.
For example, a buyer might require recovery between two approved domestic sites while vendor connectivity is unavailable. That scenario tests whether local operators have the credentials, keys, documentation and tools they need. The RFP should require the supplier to identify unsupported steps before the test.
For Scality RING evaluations, the proposed site topology and replication configuration belong in this evidence package. RING’s deployment flexibility and multi-site capabilities are relevant to geographic control, but the buyer still needs to validate the selected locations, operator responsibilities and recovery dependencies.
The ability to move data is part of retaining control over it. An exit clause should explain what the organization can retrieve, how long extraction will take and what assistance the supplier must provide. It should also address continued access during the transition.
For object storage, API compatibility alone does not establish a complete migration path. Applications may depend on object versions, metadata, retention settings, legal holds or event integrations. Some attributes may require mapping or a separate preservation process at the destination.
Suggested RFP wording:
Describe the export process for objects, required versions, metadata and retention-related information. Identify attributes that cannot be preserved directly, expected throughput, charges, dependencies and the validation process used to confirm a complete transfer.
Ask suppliers to estimate export duration using the buyer’s object count, size distribution and available bandwidth. A large number of small objects can create a different migration constraint from the same capacity stored in large files. Require assumptions behind the estimate and validate them with a representative sample.
The EU Data Act has applied since September 2025 and includes requirements concerning switching between data-processing services. Where applicable, those obligations should inform the contract, but the RFP should still specify the technical work needed for a usable exit.
Define deletion separately from export. Require a schedule covering active data, retained backups and other copies, with documented exceptions for applicable retention obligations or legal holds. The buyer should know what evidence of deletion will be available.
Certifications and audit reports can support vendor assessment, but their scope matters. A certificate covering one service, operating entity or region may not cover the deployment being purchased. Require bidders to identify that scope and explain any exclusions.
Use a response table that connects each requirement to a control and an acceptance check:
| Requirement | Evidence to request | Acceptance check |
|---|---|---|
| Approved data locations | Deployment diagram and placement policies | Verify destinations and attempt a prohibited placement change |
| Controlled support access | Role definitions and approval workflow | Approve, observe and revoke a support session |
| Defined key authority | Key architecture and permissions | Test authorized use and key-service failure behavior |
| Recovery within boundaries | Recovery dependency map and runbook | Recover a representative workload at an approved site |
| Usable data export | Export specification and limitations | Validate objects and required attributes at the destination |
Agree on the tests before selecting the supplier. Otherwise, a procurement team may accept a feature description and discover during implementation that the necessary control requires a different service tier or additional product.
The evidence package should also define what the customer must operate. A control that depends on customer-managed identity, network restrictions or key infrastructure needs an assigned owner and implementation cost.
Mark genuine non-negotiable conditions as pass or fail. A bidder that cannot meet an approved-location requirement should not offset that failure with better performance or a lower price. Exceptions need an explicit decision from the owner of the requirement.
For the remaining criteria, use a simple evidence scale: unsupported assertion, documented capability, demonstrated capability and contractual commitment backed by an agreed acceptance test. Require vendors to disclose whether each answer depends on configuration, an additional license, a third party or future development. Roadmap statements should not receive the same treatment as an available control.
Carry accepted requirements into the contract and implementation plan. Include notification and review provisions for changes to hosting locations, subcontractors, remote access and service dependencies. Sovereignty can change after deployment even when the storage hardware stays in the same building.
Organizations building or buying national and regional services can see how these control dimensions apply on the sovereign cloud platforms use case page.
The most useful RFP leaves the buyer with a clear operating picture: where every relevant copy can exist, who can influence it, how recovery works and how the organization can leave. Those answers should be specific enough to test before production and revisit throughout the service lifecycle.