A cloud platform can store every production record inside one country while relying on an overseas service to approve administrator logins. Its backups can remain in an approved data center while the keys needed to restore them depend on a separate provider. In both cases, the location of the data tells only part of the story.
Sovereign cloud architecture addresses where data resides, who can act on it, and which outside dependencies the organization accepts. Mapping external control makes those dependencies visible. It connects each critical operation, such as reading an object or restoring a backup, to the people and services that can authorize, change, or prevent it.
For an infrastructure team, the useful starting point is a specific workload. Follow how it runs, how it is administered, and how it recovers. Then ask where your team's authority ends.
Start with the service you need to keep running
Consider an illustrative document archive used by a public-sector organization. The application and object storage run in two approved domestic data centers. A local operations team manages the infrastructure, and a software vendor provides support.
On the deployment diagram, the arrangement looks straightforward. However, administrators sign in through a hosted identity service, encryption uses a separate key management system, and support bundles go to a vendor portal. The recovery procedure also downloads application images from an external registry.
None of these dependencies automatically makes the design unacceptable. Each introduces a different question: can someone grant access, can a service outage stop decryption, what leaves the environment during support, and can the application be rebuilt without the registry?
Define the required boundary before judging the answers. For this archive, the organization might require domestic storage and recovery, explicit approval for supplier access, and the ability to restore service during a defined period without external connectivity. These are illustrative design requirements, not universal rules for sovereign clouds.
Separate data location from decision-making authority
A location map shows facilities, regions, replicas, and network connections. A control map adds the actors who can change what happens inside them. It should cover the organization, the hosting operator, software suppliers, managed service providers, and any shared corporate services.
Three paths make the review manageable. The data path handles application reads and writes. The management path handles permissions, configuration, updates, and administrative access. The recovery path supplies everything required to rebuild the service after a failure.
Those paths can have different dependencies. An identity outage might prevent a new administrator login while existing application requests continue. A missing software image might have no effect until a server needs rebuilding. Recording only whether the platform is “up” would miss both limitations.
For each dependency, distinguish what an outside party can do from what your organization allows it to do. A contract might prohibit unsupervised support access; the technical question is whether that access is also blocked until an authorized operator enables it. Both answers matter, but they describe different controls.
Build the external control map
Start with the archive's normal read operation, then trace an administrative change and a full restore. For each step, record the controlling actor, the actual permission or dependency, and the consequence if that actor becomes unavailable. Include the legal entity and operating location where relevant, so legal and procurement teams can review the same architecture.
The following map illustrates the questions to resolve. It does not describe a particular provider's implementation.
| Dependency | External control to identify | Consequence to test |
|---|---|---|
| Administrator identity | Who can issue credentials, reset authentication, or change group membership? | Can authorized staff administer the archive if the identity service is unavailable? |
| Encryption keys | Who can approve decryption, disable keys, or change key policy? | Can a newly started application read encrypted objects? |
| Storage administration | Who can change permissions, placement, or replication settings? | Can an outside administrator redirect data or expand access? |
| Vendor support | Who can open a session or receive diagnostic exports? | Can troubleshooting proceed with approved, limited access? |
| Software distribution | Who publishes updates, and who approves installation? | Can the team rebuild from an approved local copy? |
| Recovery services | Who controls backup catalogs, credentials, and restore infrastructure? | Can the archive be restored without the failed service? |
Keep separate entries when authority is split. The organization might own a key but rely on a provider to operate the service that uses it. A local team might approve storage changes while a managed service account has sufficient privilege to make them.
For every entry, attach a concrete item to check: an effective role assignment, a network rule, a key policy, an update setting, or a tested recovery procedure. Where the behavior is unknown, mark it unknown. An unverified dependency needs investigation before it can support a sovereignty claim.
Trace administrator access all the way through
In the archive example, begin with the account used to change storage permissions. Follow its authentication back through the identity provider, multifactor authentication, group membership, and account recovery process. A locally assigned storage role may still depend on an external administrator who can reset the account used to obtain it.
Also inspect service accounts and automation. A deployment tool may hold broader privileges than the human administrator whose access is carefully restricted. If that tool runs outside the intended boundary, its credentials create another route into the environment.
Where continued administration is required during an identity outage, evaluate a separately protected emergency access method. It needs limited privileges, secure custody, monitoring, and a tested activation process. Otherwise, solving the availability problem can create an uncontrolled access path.
The architecture decision should be explicit. Normal access may depend on the hosted identity service, while emergency administration remains available through a locally controlled mechanism. Document which operations that mechanism permits and who can authorize its use.
Treat encryption as a chain of permissions
“Customer-managed keys” needs further explanation before it says much about control. Determine who generates the key material, where it resides, which service performs cryptographic operations, and who can authorize those operations. Then identify who can change or disable each part of that arrangement.
For the archive, key ownership alone does not establish that recovery is independent. The restore process may still require a provider's key service, associated metadata, or a specific integration. Keeping a copy of key material is not proof that another platform can decrypt the stored data.
External key control can also introduce an availability dependency. If an operation needs a key service that cannot be reached, that operation may fail even though the storage is healthy. Conversely, an application using cached keys might continue temporarily, so an immediate read test can overstate independence.
Test with a newly started application and data that requires a fresh key operation. Record whether reads, writes, and restores behave differently. Preserve the distinction between preventing future decryption and removing plaintext that an application has already obtained.
Follow support and software beyond the storage boundary
Support changes the normal flow of information. An operator may export logs, object names, configuration files, or diagnostic bundles to help resolve a fault. Those exports can reveal sensitive details even when they contain no document contents.
Inspect a representative bundle before defining the support process. Identify what it contains, where it goes, who receives it, and how unnecessary information can be removed. For remote sessions, establish how access is approved, limited, recorded, and revoked.
Software updates create another form of outside influence because installed code can change system behavior. A signed package helps establish its origin and integrity; the operating process still needs to establish who approves it, when it runs, and how the team recovers from a failed update.
For the archive, locally retained installation packages and application images could support recovery during an external outage. That approach also requires a process to keep those copies approved and current. Record any licensing, activation, certificate, or repository dependencies that remain, then verify their actual behavior.
Make recovery cross the same boundary as production
The archive's second data center is useful only if the team can bring the service back there. Storage replicas do not supply every requirement for recovery. The application may also need its configuration, credentials, key access, catalog, network settings, and compatible software.
Trace a restore from an empty recovery environment. Ask where each item comes from and whether it depends on the component assumed to have failed. A recovery password stored only in the unavailable production identity system is a circular dependency.
Then inspect data placement during recovery. A procedure that restores into whichever cloud region has capacity could contradict the archive's approved locations. Recovery destinations and replication changes need the same placement constraints as routine operation.
This is where storage architecture and operational sovereignty meet. Multiple sites reduce some physical failure risks, but shared identity, key, or management services can still create a common dependency. The control map should make that shared dependency visible before a recovery event exposes it.
Test the dependencies that could stop the service
Use a controlled test environment representative of production, with a recovery plan for the test itself. Remove one dependency at a time so the team can attribute the result. Choose test duration around actual credential, cache, certificate, and renewal behavior rather than an arbitrary short outage.
For the illustrative archive, a useful sequence is:
- Make the external identity service unavailable and test both normal and approved emergency administration.
- Interrupt the key-service connection and test fresh application starts, encrypted reads, writes, and restores.
- Block external software repositories and rebuild the application from approved local materials.
- Restore a representative dataset at the second site using the documented recovery dependencies.
Record partial failures as carefully as complete outages. “Existing users could read documents, but operators could not add an account” is a useful finding. So is “the restore completed only after access to the external registry returned.”
Turn each result into a decision. Remove an unacceptable dependency, provide a controlled fallback, or formally accept the limitation for that workload. Assign an owner and retest after changes to identity, encryption, hosting, or recovery design.
Place object storage within the wider architecture
Object storage gives the team a place to enforce data access and placement decisions, but the surrounding services determine how much practical control the operator retains. A storage deployment cannot, by itself, establish the sovereignty of the application, identity system, support process, and recovery environment.
Scality RING supports operator-controlled deployments, including on-premises and sovereign cloud environments, with hardware flexibility and multi-site storage capabilities. For the archive example, that provides a basis for selecting the storage locations and operating model. The integration review must still establish who controls administrative identities, encryption, updates, and recovery.
An S3 interface also provides a useful starting point for testing an alternative storage destination. Moving the archive still requires checking the features the application actually uses, including permissions, metadata, object versions, retention settings, and encryption. A successful copy of a few objects is only the beginning of that test.
When evaluating sovereign cloud platforms, bring the control map into the architecture discussion. Ask the supplier to explain each dependency and demonstrate the behaviors that matter to your workload. Keep product capabilities and the configuration of your own deployment distinct.
Make the final decision about specific powers
The archive review should finish with a clear description of who can act and what the service depends on. For example: local operators control storage configuration; supplier access requires approval; new administrator logins depend on a hosted identity service; and recovery has been tested using locally available software and approved key services.
That description is more useful to an IT director than a broad sovereignty label. It identifies the remaining dependencies, their consequences, and the people accountable for accepting them. Legal and procurement teams can then assess the contractual and jurisdictional questions against the actual operating arrangement.
The strongest next step is to examine one essential operation: restoring a critical service. Trace every permission, key, software component, and external call it needs. Any outside party that can prevent that recovery belongs on the sovereign cloud architecture map.