Skip to main content
Start a conversation

Data and deployment guide

UK data residency and UK GDPR decision guide

Data residency is a workload and supplier decision. It is not a blanket label that can be applied to every system, model endpoint or backup route.

When to use this

Use this during discovery, procurement or architecture work when a team needs to decide what data is involved, where it may be processed and which contracts or controls need review.

  1. 01

    Classify the data and purpose

    Identify the data, people affected, purpose, volume, sensitivity, retention needs and whether special-category, criminal-offence or other higher-risk information may be involved.

  2. 02

    Draw the actual data flow

    Include browser, application, API, model provider, storage, logs, analytics, support tools, backups, administrators and subprocessors. The decisive location may be outside the primary hosting region.

  3. 03

    Check supplier terms and configuration

    Confirm the selected product, account, endpoint, region, retention setting, training policy, support access and contractual commitments. Do not rely on generic marketing statements for a different product tier or service.

  4. 04

    Assign controller and processor decisions

    Clarify who determines purpose and means, which suppliers process data, which agreements are needed and which privacy, security and procurement owners must review the proposed route.

  5. 05

    Plan access, retention and deletion

    Define who can access production and support data, how permissions are reviewed, how long inputs and outputs remain, and what happens to logs, backups and exports when an engagement or account ends.

  6. 06

    Record the residual decision

    Document the selected route, alternatives considered, open risks, approvals and conditions. If a UK-only requirement cannot be met for a workload, say so before a commitment is made.

Applied guidance

Use the tool as a decision record, not a box-ticking exercise.

01

Start with the processing purpose

Data location decisions are clearer when the team begins with the operational purpose and the actual information needed to meet it. Identify what the workflow needs to receive, create, retain, display or share, then distinguish it from data that is convenient but not necessary. This helps product, privacy, security and procurement colleagues discuss a real system rather than a generic ‘AI data’ category. It also exposes whether a proposed feature can use a reduced, redacted or synthetic input. The result is a more proportionate design and a more accurate supplier question set.

02

Draw the complete route, including support paths

A primary hosting region is only one part of a data flow. Teams should trace user devices, browser services, APIs, model or analytics endpoints, application and database storage, logs, backups, support access, monitoring tools, email or notification services and subprocessors. For each element, note the selected service and configuration rather than assuming every product under the same supplier brand behaves alike. The map does not itself establish compliance or legality. It is the working evidence needed to identify which locations, transfers, retention points and access routes require further review.

03

Verify the selected service, not generic marketing

Supplier documentation and contract terms should be checked against the exact product tier, region, endpoint and account configuration the workload will use. Teams may need to ask about input and output retention, training or service-improvement terms, support access, subprocessors, encryption options, availability of regional controls and how changes are communicated. Record the date and source of the verification because supplier services evolve. If a requirement depends on a feature that has not been verified for the chosen configuration, treat it as an open condition rather than communicating an assurance that the technical evidence does not support.

04

Give retention and deletion an operating owner

Retention choices need to cover more than the principal database. Consider generated outputs, upload stores, application logs, analytics, support tickets, exports, backups and personal workspaces. For each, establish why it is retained, who may access it, how long it remains, and how deletion or archival is handled in normal operations and at the end of an account or engagement. A product team may need advice from appropriate privacy or legal professionals for its circumstances. The engineering role is to make the actual capabilities, limitations and data paths visible enough for that review.

05

Record decisions and revisit material changes

A short architecture or procurement record should state the requirement, selected route, evidence reviewed, residual questions, accountable owner and conditions for review. Changes to a model endpoint, hosting region, support process, retention setting or new integration can alter the original decision. The review should therefore be triggered by meaningful change rather than left to memory. This is not a substitute for a DPIA, contract review or legal advice where those are needed. It is a practical way to ensure that delivery claims about UK processing or data handling remain bounded to verified workload facts.

06

Avoid using residency as a shortcut

A stated UK region can be important, but it does not answer every data-protection, security or procurement question. The actual workload may still involve international support access, a separate analytics service, exports to a user device, backup arrangements or a processor relationship that requires review. Conversely, a requirement may be satisfiable through a carefully documented service route even when a broad marketing label is unavailable. The delivery team should describe what it has verified and what it has not, then involve the appropriate accountable specialists for the organisation’s own decision. Precision is more useful than a blanket compliance slogan.

Working prompts to adapt

Data-flow record

[Data type] enters from [source], is processed by [systems/providers], stored in [locations], accessed by [roles], retained for [period] and deleted/archived by [method].

Supplier check

For [service/account/endpoint], we have checked [region], [retention], [training/use terms], [subprocessors], [support access] and [contractual terms].

Decision boundary

This workload can/cannot meet [requirement] because [verified reason]. The accountable owner is [role] and the review date is [date].

Related routes

Continue the delivery decision

01Secure AI deployment02API and systems integration capability03Responsible AI delivery evidence pack

Primary guidance