Skip to main content
Category: Data Transfers

Data Localisation

Also known as: Data Localization, Data Residency
Simply put

Data localisation is the practice or legal requirement of keeping data within the borders of a particular country or region. In most cases it means that organisations must collect, store, and/or process certain data on servers located inside a specific geographic area, rather than sending it overseas. The exact obligations vary depending on the country and the type of data involved.

Formal definition

Data localisation refers to legal, regulatory, or administrative requirements that mandate, directly or indirectly, that specified categories of data be collected, stored, and/or processed within a defined national or regional jurisdiction. Such measures typically restrict cross-border transfers by requiring in-country storage or processing, and are often framed in terms of data sovereignty over the data of a country's citizens or residents. The scope, triggering data categories, and degree of restriction differ significantly between jurisdictions; the term 'data residency' is frequently used synonymously, though practitioners should verify the precise obligations under the applicable national law, as these requirements evolve and are not defined uniformly across regimes. Note that data localisation obligations are distinct from, and may operate alongside, cross-border transfer mechanisms under data protection frameworks such as the GDPR.

Why it matters

Data localisation shapes where organisations may physically hold and process data, and it can operate independently of the transfer mechanisms found in data protection frameworks such as the GDPR. Where a jurisdiction mandates that data about its citizens or residents be collected, stored, and/or processed in-country, an organisation may need local infrastructure or arrangements even where a valid cross-border transfer tool would otherwise be available. In most cases the two regimes must be assessed together rather than treated as alternatives, because satisfying one does not automatically satisfy the other.

The practical significance lies in cost, architecture, and compliance risk. Localisation obligations can require duplicated storage, regional processing, or restrictions on routing data overseas, which affects cloud strategy, vendor selection, and product design. Because the triggering data categories and degree of restriction differ significantly between jurisdictions, an approach that is compliant in one country may not meet the requirements of another.

These requirements are not defined uniformly across regimes and continue to evolve, so a position taken at one point in time should not be assumed permanent. Organisations should verify the precise obligations under each applicable national law and monitor for change, rather than relying on a general characterisation of localisation as a single global standard.

Who it's relevant to

Data Protection Officers and Compliance Leads
DPOs and compliance teams need to map where regulated data is stored and processed, and to distinguish localisation obligations from cross-border transfer requirements, since the two can apply at the same time. Because obligations differ by jurisdiction and evolve over time, ongoing monitoring of applicable national laws is generally advisable rather than a one-off assessment.
Engineers and Cloud Architects
Those designing data infrastructure must account for requirements that certain data be kept within a defined national or regional area. This can influence choices around regional storage, processing location, and data routing, and may require in-country arrangements even where an overseas facility would otherwise be technically preferable.
Legal Advisers and Contract Teams
Lawyers advising on international operations should verify the precise localisation obligations under each relevant national law, as these are not defined uniformly across regimes. They should also consider how such requirements interact with, and operate alongside, transfer mechanisms under frameworks such as the GDPR, rather than assuming that one satisfies the other.
Procurement and Vendor Management
Teams selecting cloud and processing vendors should confirm whether a provider can meet applicable in-country storage or processing requirements for the relevant data categories. Because the scope and degree of restriction vary between jurisdictions, vendor capabilities should be assessed against the specific laws that apply to the data in question.

Inside Data Localisation

Data Localisation Requirement
A legal or regulatory obligation, typically arising from national law rather than the GDPR text itself, that requires certain categories of data to be stored, processed, or otherwise kept within a specific jurisdiction or geographic territory. The precise scope varies significantly between countries and should be verified against the applicable national instrument.
Scope of Covered Data
The categories of data subject to a localisation rule, which may extend beyond personal data as defined under the GDPR to include other data types such as certain government, financial, or sectoral data. Because localisation regimes are jurisdiction-specific, the covered scope is generally defined by the relevant national law rather than by GDPR concepts.
Relationship to Cross-Border Transfers
Data localisation intersects with, but is distinct from, the GDPR's Chapter V rules on international transfers. Transfer mechanisms such as adequacy decisions, Standard Contractual Clauses, and Binding Corporate Rules address the lawfulness of moving personal data outside the EEA, whereas localisation typically imposes a positive requirement to keep data in-country. These frameworks can apply concurrently and should be assessed separately.
Territorial and Legal Source
The legal basis for a localisation obligation, which is generally found in a member state derogation, national implementing law, or a non-EU country's domestic legislation rather than in the harmonised GDPR text. The UK GDPR and other national regimes may take differing positions, so the source instrument must be identified in each case.
Storage and Processing Locality
The distinction between where data is stored, where it is processed, and where it may be accessed. Some localisation rules address only storage, others cover processing or access, and the practical technical implications differ accordingly. The exact obligations depend on the wording of the applicable rule.

Common questions

Answers to the questions practitioners most commonly ask about Data Localisation.

Does the GDPR require personal data to be stored within the EU or EEA?
No. The GDPR does not impose a general data localisation or data residency requirement. It governs the conditions under which personal data may be transferred to third countries (Chapter V), but this is a mechanism for lawful transfer rather than a mandate to keep data physically within the EU or EEA. Data can typically be transferred outside the EEA where an appropriate transfer tool or safeguard applies, subject to assessment. Localisation obligations, where they exist, generally arise from specific national laws, sectoral rules, or member state derogations rather than from the GDPR text itself. Readers should verify any specific obligation against the applicable law.
Is data localisation the same thing as a restriction on international data transfers?
Not exactly, and the two should not be conflated. A data transfer restriction, such as those addressed under Chapter V of the GDPR, regulates the conditions under which personal data may be sent to or accessed from a third country, typically permitting the transfer where a valid mechanism or safeguard is in place. Data localisation, by contrast, generally requires that data be stored or processed within a particular jurisdiction, and may prohibit or condition its movement outside that territory altogether. Localisation requirements typically derive from national or sectoral law rather than the GDPR, and their scope varies by jurisdiction.
How can an organisation determine whether a data localisation requirement applies to its processing?
Determining applicability generally involves mapping the categories of data processed, the jurisdictions in which the organisation and its data subjects operate, and the sectors involved, then checking whether specific national laws, sectoral regulations, or public-sector rules impose storage or residency conditions. Because such requirements typically arise outside the GDPR and vary between member states and non-EU jurisdictions, an assessment against the current applicable local law is advisable. Where uncertainty exists, consulting the relevant text and qualified local advice is recommended.
What steps might an organisation take to comply with a localisation requirement while using cloud or third-party providers?
In practice, organisations often review the storage and processing locations offered by a provider, including any regional hosting options, and confirm these contractually. Where a provider processes personal data on the organisation's behalf, a data processing agreement under Article 28 would generally address processing locations and any sub-processor arrangements. Attention is typically paid to whether support, backup, or administrative access could result in data being accessed from outside the required jurisdiction. The adequacy of any such arrangement is context dependent and subject to assessment against the specific obligation.
How does a localisation obligation interact with the GDPR's international transfer rules?
The two can operate concurrently and independently. Meeting a GDPR transfer mechanism does not necessarily satisfy a separate localisation requirement, and vice versa. An organisation may need to demonstrate both a valid basis for any transfer under Chapter V and compliance with any applicable localisation rule that mandates in-jurisdiction storage. Because transfer tools and supplementary measures evolve, and localisation rules differ by jurisdiction, each should be assessed on its own terms rather than treated as interchangeable.
What documentation or governance measures help demonstrate compliance with localisation requirements?
Organisations typically maintain data mapping or records of processing that identify where data is stored and processed, alongside contractual terms specifying permitted locations and controls on sub-processors and remote access. Internal policies, vendor due diligence records, and periodic reviews can help evidence ongoing alignment, particularly as provider infrastructure or applicable rules change. The appropriate level of documentation is context and risk dependent, and readers should confirm requirements against the specific applicable law and current guidance.

Common misconceptions

The GDPR requires personal data to be stored within the EU.
The GDPR itself does not generally mandate that personal data remain within the EU or EEA. It regulates the conditions under which personal data may be transferred to third countries via mechanisms such as adequacy decisions and appropriate safeguards, but it does not, as a general rule, impose a localisation requirement. Localisation obligations typically derive from national law or member state derogations and should be verified against the relevant instrument.
Complying with a data localisation rule means cross-border transfer obligations no longer apply.
Localisation and transfer rules are distinct and can apply concurrently. Keeping data within a jurisdiction may not, by itself, satisfy the GDPR's Chapter V requirements where any transfer or remote access to a third country occurs, and each obligation typically requires separate assessment.
Data localisation requirements are uniform across the EU.
There is no single harmonised EU localisation regime. Requirements vary between member states and between EU and non-EU jurisdictions, and member state derogations can alter the position. Practitioners should treat each jurisdiction's rules individually rather than assuming a common standard.

Best practices

Identify the specific legal instrument that creates any claimed localisation obligation, distinguishing GDPR provisions from national implementing law, member state derogations, and non-EU domestic legislation, and verify the wording against the current official text.
Map the categories of data in scope for each applicable rule, noting that some localisation regimes reach beyond personal data as defined under the GDPR.
Assess localisation obligations separately from Chapter V cross-border transfer requirements, since both can apply concurrently and satisfying one does not necessarily satisfy the other.
Clarify whether a given rule addresses storage, processing, remote access, or a combination, and align technical and architectural controls to the precise obligation.
Account for jurisdictional divergence, including differences between EU member states and the position under the UK GDPR, rather than assuming a uniform standard.
Document the analysis and revisit it periodically, as transfer tools, adequacy decisions, and national localisation rules can evolve over time.