Ask a cloud provider in 2008 where your data would be stored and you received one of two answers. The honest one was "in our global infrastructure." The evasive one was a marketing page about redundancy. Neither was a contractual commitment, and most buyers signed anyway — because the service was cheap, the procurement process treated it as a software purchase rather than an outsourcing arrangement, and nobody in the approval chain had a framework for asking the question properly. That gap between what the contract said and what the business assumed is the origin of most data sovereignty problems organizations are still untangling today.
Why the Contracts Looked Like That
Early cloud terms were not adversarial. They were the natural output of a business model. The economics of cloud depend on fungible capacity: workloads placed wherever there is space, power and cost advantage, moved when circumstances change. A location guarantee is a constraint on that flexibility, and in 2008 providers were not prepared to price one. The standard agreement was therefore a click-through, non-negotiable document with unilateral amendment rights, broad sub-processing permissions, limited liability, and silence on geography. Legal research that examined these agreements systematically found exactly this pattern — contracts drafted almost entirely in the provider's favour, with the location of customer data identified as a key concern for buyers subject to export restrictions on personal or regulated data, and only limited options emerging to restrict storage to a chosen region. The imbalance was not malice. It was standardisation. A provider serving hundreds of thousands of customers cannot negotiate bespoke terms, and the price reflected that. But it meant that a procurement function accustomed to negotiating outsourcing agreements suddenly had no counterparty to negotiate with.
What Buyers Failed to Ask
The questions that mattered were not hard. They were simply not on anyone's checklist:
- In which countries will data be stored, and in which countries will it be processed?
- Where is support delivered from, and can support staff access production data?
- Who are the sub-processors, and do they have their own sub-processors?
- Can the provider move data between regions without telling us?
- Who holds the encryption keys?
- Which jurisdiction's courts and law enforcement can compel disclosure, and will we be notified?
- What happens to our data on termination — in what format, within what period, and is deletion verified? Every one of these is now standard in enterprise cloud diligence. In 2008 they were considered obstructive.
The Sub-Processor Blind Spot
The most durable lesson from this period concerns the second layer. Your provider's own suppliers — hosting, storage, monitoring, support, payment processing, analytics, and now AI services — also handle your data, and the original contract usually permitted that without disclosure. This matters because a location guarantee that covers only the prime provider is not a location guarantee. Modern commentary on cloud agreements is explicit that data provisions need to address ownership, provider access and use of customer data, retention, and the location and security of data, including obligations flowing down to subcontractors and affiliates. The practical version: ask for the sub-processor list, check that each one is bound to the same terms, and require advance notice of additions with a right to object. Providers that cannot produce the list are telling you something useful.
What Changed, and What Did Not
The market fixed part of this. Region selection is now standard and contractually meaningful with major providers. Data processing addenda, transfer mechanisms and published sub-processor registries are routine. Sovereign and in-region offerings exist specifically for regulated buyers. Three problems survived intact. Support and administration access. Storage location is contractually pinned; the location of the engineers who can access the system frequently is not. "Follow the sun" support models mean production access from multiple jurisdictions, and that is an access question no residency clause addresses. Metadata, logs and backups. Primary data stays in region. Telemetry, audit logs, indices and disaster recovery copies often do not. This is the most common finding in a serious cloud architecture review. The small vendor problem. Region guarantees are available from hyperscalers. The forty smaller SaaS products in your estate are running on someone else's infrastructure with click-through terms that look exactly like 2008 — and that is where most of your unmanaged exposure sits, not in the platforms your architecture team reviewed. AI services have reintroduced the problem in its original form. Model endpoints are provisioned where capacity exists, prompt and output logging is often on by default, and the terms describing retention and training use change more frequently than any procurement cycle can track.
Contracting Properly Now
- Specify storage and processing locations separately. Then add support access location, administrative access location, and backup and log locations. Four different answers, four different clauses.
- Require a sub-processor register with notice and objection rights. Including any AI or analytics services introduced into the processing chain.
- Pin key custody. Who holds encryption keys, under which jurisdiction, and what is logged when they are used.
- Demand a government access commitment. Notification where legally permitted, a commitment to challenge overbroad requests, and transparency reporting.
- Write the exit before you sign. Export format, export mechanism, timeframe, cost, retention period after termination, and verified deletion — including from backups.
- Control unilateral change. Advance notice of material changes to terms or processing locations, with a right to terminate without penalty if a change breaks a compliance requirement.
- Apply tiered diligence. Full scrutiny for systems holding regulated or sensitive data; a lighter standard checklist for everything else. Applying enterprise diligence to every tool is how shadow IT gets created.
- Re-check annually. Sub-processors, regions and terms change. A review performed at signature describes a configuration that no longer exists.
| Commitment area | Evidence to examine |
|---|---|
| Location | Storage, processing, support and secondary-copy locations |
| Processing chain | Sub-processor terms, register and change notice |
| Key custody | Who can use keys and what access is logged |
| Lawful access | Permitted notice and request-challenge commitments |
| Exit | Format, timing, cost, retention and deletion evidence |
| Change | Material-change notice, review and available termination rights |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The Point
The 2008 cloud contract was not a bad deal. It was an honest description of a service that traded location certainty for price and elasticity, and buyers who read it understood the trade. The failure was assuming the silence meant something reassuring. Contracts do not become more protective because the business hopes they are — and "we assumed it stayed in Europe" has never been a defence anyone has successfully run in front of a regulator.
Common Questions
Why did early cloud contracts not guarantee data location?
Because the cost model depended on moving workloads freely between facilities. Location guarantees constrained that flexibility, so standard terms omitted them and buyers accepted the price instead.
Does choosing a cloud region guarantee data residency?
It governs primary storage. Backups, logs, telemetry, indices and support access frequently sit outside the chosen region unless separately contracted.
What are sub-processors and why do they matter?
They are your provider's own suppliers who handle your data — hosting, support, monitoring, analytics and increasingly AI services. Location and security commitments are meaningless unless they flow down to every one of them.
What should a cloud exit clause contain?
Export format and mechanism, a defined timeframe, cost, the retention period after termination, and verified deletion including from backups — agreed before signature, not requested at termination.
Cloud Contract Review — Outpace reviews your cloud and SaaS agreements against the questions that actually determine exposure — processing location, support access, sub-processors, key custody and exit — and renegotiates the terms that matter.