The Data Residency Clause: What It Means and How to Draft It (2026)

What a data residency clause means A data residency clause is the part of a contract that controls where a service provider may store and process data, and whether that data can be moved across borders. In plain terms, it answers a question customers increasingly care about: where does our data physically live, who can touch it, and can it leave the country. The clause sits at the meeting point of commercial concern and law. Commercially, a customer may want data kept in a particular country for latency, trust or customer expectations. Legally, many data-protection regimes restrict transferring personal data out of a region unless certain safeguards are in place. A good data residency clause pins down the commercial promise and lines it up with the legal requirements. It helps to keep three related ideas apart: - Data residency is where data is stored at rest (the physical or regional location of the storage).

• Data localisation is a legal requirement, imposed by some countries, that certain data must be kept within national borders.
• Cross-border transfer is the act of moving data to another country, which data-protection law often regulates even where there is no strict localisation rule. A contract can promise residency in a region, forbid transfers outside it, and set the safeguards for any permitted transfer, all in the same clause. ## Why the clause matters Getting this wrong is expensive in two directions. Promise strict in-country storage you cannot actually deliver, and you are in breach. Stay silent and let data flow anywhere, and you may breach data-protection law, lose enterprise customers who require residency, or fail a security review. For regulated sectors (financial services, health, government) residency and localisation requirements can be hard rules, not preferences. The clause is how a buyer gets a contractual commitment it can audit, and how a provider sets honest limits on what it can guarantee. ## The parts of a data residency clause - Covered data. Which data the clause applies to (for example customer data, personal data, or defined sensitive categories).
• Primary location. The country or region where data will be stored and processed at rest.
• Transfer restriction. Whether data may leave that location, and under what conditions.
• Permitted transfers and safeguards. If transfers are allowed, the legal mechanism used (for example standard contractual clauses or an adequacy finding) and the security measures that travel with the data.
• Sub-processors. Whether and where sub-processors may store or access data, and notice or approval for new ones.
• Support and access. Whether staff outside the region can access the data for support, and under what controls.
• Change and audit. Notice before locations change, and the customer's right to verify. ## A sample data residency clause > The Provider shall store and process all Customer Data at rest only within [country or region] (the Permitted Region). The Provider shall not transfer, store or process Customer Data outside the Permitted Region without the Customer's prior written consent, except where strictly necessary to provide support and then only under appropriate technical and organisational safeguards. Where any transfer of personal data outside the Permitted Region is permitted, the Provider shall ensure a valid transfer mechanism is in place (including standard contractual clauses where required) and shall maintain security measures no less protective than those in the Permitted Region. The Provider shall maintain an up-to-date list of sub-processors and the locations in which they store or access Customer Data, shall give the Customer at least [number] days' notice before adding or changing a sub-processor or storage location, and shall allow the Customer to verify compliance with this clause on reasonable notice. Treat this as a drafting starting point, not a finished clause. The right wording depends on the data involved, the countries in play and the applicable law, and this page is general information, not legal advice. ## How to draft it well Define the covered data precisely. A clause that applies to all data is often unworkable. Separate personal data, sensitive or regulated data, and ordinary operational data, and apply residency where it is actually needed. Name the region, and be realistic. Pick a region the provider can genuinely deliver. A promise of strict single-country storage that the provider's architecture cannot meet is a breach waiting to happen. Separate storage from access. Storage in-region and access-from-anywhere are different. Decide whether support staff outside the region can view data, and if so under what controls, rather than leaving it unspoken. Tie transfers to a lawful mechanism. If transfers are allowed, require a valid legal mechanism (such as standard contractual clauses or reliance on an adequacy decision) so the clause is compliant, not just comforting. Control sub-processors. Most residency breaches happen one layer down, through a sub-processor in another country. Require a current list, notice of changes, and that sub-processors meet the same standard. Add notice and audit rights. Locations change as providers grow. Require advance notice before any change and a right to verify, so residency is something you can check rather than trust. ## Points worth negotiating The customer usually wants a firm region, no transfers without consent, a tight sub-processor regime, and audit rights. The provider usually wants flexibility to use global infrastructure and support teams, a lighter notice-based process for sub-processors rather than consent, and limits on audit frequency. A workable middle ground is in-region storage at rest with controlled, safeguarded access from elsewhere, a maintained sub-processor list with notice and a right to object, and reasonable audit rights. Where a hard localisation law applies, that requirement is not really negotiable and the clause simply has to meet it. ## Jurisdiction notes Under the EU and UK General Data Protection Regulation, transfers of personal data outside the EEA or UK are restricted and generally need a transfer tool such as an adequacy decision or standard contractual clauses, which pushes many providers to offer regional storage. In India, the Digital Personal Data Protection Act 2023 allows cross-border transfer of personal data except to countries the government may restrict, while certain sector regulators (for example in payments and banking) impose their own localisation rules. Several other countries have their own localisation requirements for specific categories of data. Because the rules differ by country and by sector, the residency clause should be drafted against the specific data and jurisdictions involved rather than a single global assumption. ## Common mistakes Applying residency to all data when only some of it needs it, making the clause unworkable. Promising strict in-country storage the provider cannot actually deliver. Confusing storage with access, so data sits in-region but is viewed from anywhere with no controls. Allowing transfers without naming a lawful mechanism. Ignoring sub-processors, where most leaks of data across borders happen. No notice before locations change, so the customer finds out after the fact. Copying a residency clause written for one jurisdiction into a deal governed by another. ## One workspace to draft, review and track your clauses Most teams do not lose on the theory of data residency. They lose because the clause is buried in a data-processing addendum, the list of which contracts promised in-country storage lives in someone's memory, and a quiet change of sub-processor goes unnoticed until an audit. The alternative is to keep drafting, review, tracking and governance in one place rather than across five disconnected tools. The idea is simple. You draft from your own clause catalogue and house positions, the system reads any contract and flags positions (including a residency or transfer commitment) as favourable, neutral or unfavourable to your company, obligations such as a residency promise become trackable, and because the contract is held as a structured clause tree rather than flat text you can find every data residency clause across a set of agreements and align them in plain English. Adira is one such workspace, built on Anthropic's Claude and tuned to how your company contracts, with encryption in transit and at rest and (for Enterprise) data-residency and retention controls. India is deepest today, with other jurisdictions and a company command centre on the roadmap.