Audit evidence requests arrive, and an IT compliance manager confirms that Salesforce data is hosted in the UK, only to discover that cross-border sub-processor transfers still lack signed safeguards and assessment records. The real problem is not where the data sits. It is proving, before the audit deadline, who reviewed the transfer risk and which mechanism made each transfer lawful.
This article cuts through that challenge. It explains what UK law actually requires, covers the transfer mechanisms Salesforce environments need, and identifies the documentation gaps that standard tools leave open. IT compliance managers and data officers will come away with a practical framework for mapping obligations, verifying transfer safeguards, and preparing audit-ready evidence, all grounded in one core principle: UK data residency compliance depends on proving that each cross-boundary transfer meets documented safeguard requirements.
What UK Law Actually Requires
The short answer: UK law does not impose a general data residency requirement. It regulates international transfers. Neither UK GDPR nor the Data Protection Act 2018 requires personal data to be stored in the UK, and the term data residency does not appear in either statute. What the law regulates is the act of transferring personal data to an organisation outside the UK, and whether that transfer is covered by a lawful mechanism.
That distinction is the starting point for UK compliance, because geographic controls alone do not satisfy UK rules. UK-hosted Salesforce data residency arrangements can still involve restricted international transfers. Getting this right determines whether an organisation can defend its practices during an ICO audit.
UK law regulates international data transfers through a transfer protection model defined in Part 3, Chapter 5 of the Data Protection Act 2018.
Under that model, a restricted transfer occurs when three conditions are met:
- UK GDPR applies to the processing
- Your organisation is initiating the transfer of personal data to an organisation located outside the UK
- The receiving organisation is a separate legal entity from your own
The second condition carries more weight than it first appears. The ICO draws a distinction between initiating a transfer and merely authorising one, and only the organisation that initiates it is responsible for complying with the transfer rules. Initiating means making the initial decision that causes the transfer to happen: designing the transfer structure or choosing the receiver. Where a UK processor sends data to its own sub-processor outside the UK, the processor initiates that transfer, not the controller who authorised it.
This test is organisational, not geographic. A UK-hosted cloud provider still triggers a restricted transfer when it sub-processes data to an entity outside the UK.
When a transfer is restricted, three categories of mechanism can make it lawful: UK adequacy regulations, appropriate safeguards, and Article 49 exceptions. Appropriate safeguards include the International Data Transfer Agreement, Binding Corporate Rules, and standard contractual clauses. Article 49 exceptions, by contrast, cover narrower situations such as explicit consent or the establishment of legal claims.
Financial services organisations subject to FCA rules, NHS implementations, and public sector contracts may face additional hosting requirements on top of these mechanisms. Those obligations come from the contract or the sector regulator, not from data protection law itself. Even so, general obligations still focus on transfer safeguards rather than storage location.
Do UK Data Residency Requirements Mean Data Must Stay in the UK?
No. This is the most persistent misconception in UK data protection, and it costs organisations money in unnecessary infrastructure while leaving the actual compliance gap unaddressed.
UK GDPR permits personal data to leave the UK provided the transfer is covered by adequacy regulations, appropriate safeguards, or an Article 49 exception. There is no provision requiring UK residents' personal data to remain physically within UK borders.
The ICO is explicit that what matters is contractual location, not server location. Its guidance sets out two consequences that most teams find counterintuitive:
- If your service provider is a UK entity, you are not making a restricted transfer, even if the servers are physically located outside the UK
- If your service provider is located outside the UK, you are making a restricted transfer, even if the servers are physically located in the UK
That second point is the one that catches Salesforce customers. Selecting a UK or EU instance does not by itself remove a transfer obligation, because the transfer analysis follows the contract, not the data centre.
The ICO addresses cloud services directly. Many large cloud providers are headquartered in the United States but operate through regionally incorporated subsidiaries that are legally separate entities, so the first step is to review your terms and establish which specific legal entity you are contracting with. If you contract with a UK entity, your use of the service does not create a restricted transfer between you and the provider. You still need to understand how that provider moves data to its own global network of processors.
Sector-specific rules can introduce genuine hosting obligations, and those should be identified separately rather than assumed to apply. Where they exist, they typically arrive through procurement terms, an FCA outsourcing requirement, or an NHS data security standard, not through UK GDPR.
How this plays out varies by sector, and the difference is usually contractual rather than statutory.
Financial services firms regulated by the FCA work under outsourcing and operational resilience expectations that require them to identify where material outsourced processing happens and to retain audit and access rights over it. In Salesforce terms, that usually means documenting the sub-processor chain and the exit plan, not insisting on a UK instance. The obligation is to know and control the arrangement, not to keep it onshore.
NHS organisations and their suppliers work to the Data Security and Protection Toolkit and to contractual terms that often do specify UK or EEA hosting for patient data. Here the hosting requirement is real, but it originates in the contract and the NHS data security standard rather than in UK GDPR, so it should be evidenced against those documents.
Public sector bodies frequently inherit hosting commitments through procurement terms and security classification. A department running Salesforce under an OFFICIAL-SENSITIVE classification may hold explicit location commitments, and those sit alongside, not instead of, the transfer rules that govern any sub-processing outside the UK.
The common pattern across all three is that the hosting obligation, where it exists at all, comes from somewhere other than data protection law, while the transfer obligation applies to every one of them.
Operational takeaway: budget the effort where the obligation actually sits, which is documented transfer governance rather than UK-only hosting.
International Transfer Mechanisms for Salesforce Environments
Because data in a Salesforce environment can move across controllers, processors, and sub-processors within a single operating model, teams need to review each transfer individually. The following mechanisms are the building blocks of that review, and understanding how they apply helps close gaps before audit testing starts.
One mechanism is frequently overlooked in Salesforce environments. The UK Extension to the EU-US Data Privacy Framework, given effect by the Data Protection (Adequacy) (United States of America) Regulations 2023 and in force since 12 October 2023, allows UK organisations to transfer personal data to US businesses that are certified under the UK Extension without additional safeguards. Salesforce has certified to the US Department of Commerce under the EU-US DPF, the UK Extension, and the Swiss-US DPF. Where the UK Extension applies, it operates as adequacy, which means no IDTA and no Transfer Risk Assessment are required for that transfer. Before relying on it, confirm the receiving entity holds active status on the DPF list, because certification lapses are the failure mode auditors look for.
The IDTA and UK Addendum
Older contract language can leave Salesforce customers exposed, so the first check is whether UK transfers rely on a current IDTA or a valid UK Addendum.
The International Data Transfer Agreement replaced EU SCCs for UK-only transfers on 21 March 2022, and organisations that continued to rely solely on EU SCCs for UK transfers became non-compliant on 21 March 2024.
Two formats are available today. A standalone IDTA covers UK-only transfers, while a UK Addendum to EU SCCs serves organisations running combined UK and EU transfer programs. The Salesforce Data Processing Addendum already incorporates the UK Addendum, but teams should verify that their signed agreement version includes this provision, since older agreements may require amendment.
Salesforce Binding Corporate Rules
When Salesforce support, operations, or sub-processing involves entities outside the UK, transfers within the Salesforce corporate group may rely on Binding Corporate Rules. Salesforce BCRs are an ICO-approved safeguard for these intra-group transfers, and Salesforce further strengthens this safeguard by committing to annual audits, giving organisations a documented reference point for their accountability records.
It is important to note, however, that BCRs cover intra-group transfers only. They do not extend to every downstream transfer in the service chain, which is where the next step becomes critical.
Transfer Risk Assessments
A transfer mechanism alone is not enough. Each transfer made under appropriate safeguards also requires a Transfer Risk Assessment, and without one, the legal basis remains unsupported during audit review. Transfers made under adequacy regulations, including the UK Extension, do not require a TRA, which is a practical reason to establish which mechanism applies before starting the assessment work.
The assessment standard is whether the level of protection for data subjects is materially lower after the transfer takes place than it would be under UK law. To apply that standard in practice, teams should map sub-processor flows using the Salesforce infrastructure and sub-processors documentation and identify which transfers need review. The risk here is operational as well as legal: in Salesforce environments, an incomplete sub-processor map leaves the entire transfer assessment unsupported during audit testing.
A TRA is a document, and auditors assess it as one. Record the specifics rather than the conclusion, and date and version every assessment so a reviewer can see when it was last revisited.
Operational takeaway: a TRA that names the receiver, the data, the destination law, and the reviewer will survive audit scrutiny; one that records only a conclusion will not.
Audit Trail and Documentation Gaps
Audit-ready transfer compliance requires complete records. Teams must show who changed what, when, and why the change affected personal data processing. That evidence burden sits at the intersection of two overlapping frameworks: UK GDPR accountability duties and security change-control requirements. Standard Salesforce logging does not capture enough detail to satisfy either one on its own.
On the regulatory side, UK GDPR Article 30 requires records of processing activities, and the ICO has made clear that generic documentation with no meaningful links between items does not satisfy that requirement. Article 5(2) goes further, creating a positive duty to demonstrate compliance. On the security side, ISO 27001 Annex A control 8.32 requires formal change management controls, including authorisation, testing, and review evidence.
Salesforce's native audit capabilities fall short of these combined requirements in four key areas. Setup Audit Trail retains configuration change records for only 180 days, which falls short when auditors request evidence spanning longer periods, and that limit cannot be extended. Standard Field History Tracking covers up to 20 fields per object and retains roughly 18 months of history, so changes to other personal data fields go unrecorded. Deployment approval evidence does not exist natively at all, leaving no built-in way to prove who authorised a change, what testing preceded it, or which risk assessment covered it. And Field Audit Trail retention policies are configured through the Metadata API rather than a setup screen, so they sit outside the normal admin workflow and are easy to leave undeployed.
These gaps compound at the metadata level. The ICO's granularity requirement means that a Setup Audit Trail entry for a field label change is not sufficient on its own; teams must also document which personal data was affected and why the change was made.
Operational takeaway: the evidence auditors ask for is the link between a change and its authorisation, which is exactly the link native logging does not record.
UK Data Residency Compliance Checklist
The checklist below consolidates the article into a working sequence. It is deliberately ordered: mapping comes first because every later step depends on knowing which transfers exist, and periodic review comes last because the map goes stale as sub-processors change. Assign each group an owner and a review cadence, because an unowned checklist produces no evidence, and evidence is what an ICO reviewer asks for. Treat it as a recurring control rather than a one-time project, and re-run it whenever a new integration is added, a sub-processor changes, or a contract renews.
The Data (Use and Access) Act 2025
For Salesforce administrators, the DUA Act matters in three concrete ways: it changes how automated decision-making is regulated, which touches Einstein scoring and automated case routing; it raises PECR penalties to UK GDPR levels, which affects marketing operations run out of Salesforce; and it creates a statutory complaints process that most organisations will need to operate through a Salesforce-based service desk. None of these are optional, and the first two change how existing configuration should be assessed.
The DUA Act received Royal Assent on 19 June 2025. The majority of its data protection provisions came into force on 5 February 2026 through the Commencement No. 6 Regulations.
A UK-specific framework now applies in some areas of UK GDPR. Organisations operating across the UK and EU may need separate control mappings as a result.
Key changes affecting Salesforce deployments include restructured automated decision-making rules, which replace the Article 22 prohibition with a permissive framework in new Articles 22A to 22D and affect Einstein AI, lead scoring, and automated case routing; enhanced PECR penalties raised to match UK GDPR fine levels; and new powers allowing the ICO to require reports on specified matters.
The statutory complaints duty is now live. Section 103 of the Act, which inserts a new section 164A into the Data Protection Act 2018, came into force on 19 June 2026. Controllers must provide a means of making a data protection complaint, including an electronic complaints form, acknowledge complaints within 30 days of receipt, and respond without undue delay while keeping the complainant updated. Section 103 also removes the Article 77 UK GDPR right to complain directly to the ICO, making the controller the required first step. For Salesforce teams, that means a case type, an intake form, a 30-day acknowledgement SLA, and reportable evidence that the process runs.
Operational takeaway: the complaints duty is a configuration task as much as a legal one, and the evidence that it works will come out of Salesforce.
Closing Compliance Gaps in Salesforce Deployments
The recommendations in this article reduce to five: establish which legal entity you contract with before assessing hosting; map every restricted transfer and identify who initiates it; match each transfer to a mechanism, using the UK Extension where it applies and an IDTA or BCRs where it does not; document a dated Transfer Risk Assessment for every safeguarded transfer; and retain change evidence for longer than 180 days, linked to the authorisation that permitted it.
Closing the last of those gaps requires more than native logging. Teams need longer record retention, clear change evidence, and consistent deployment controls to support audit review. In practice, that means automating audit trail generation so change activity is documented for compliance reporting, implementing version control with rollback capabilities to create the recovery evidence ISO 27001 auditors expect, and enforcing policy-based deployment controls that require checks to pass before metadata reaches production.
Purpose-built Salesforce DevOps platforms can replace these manual workarounds with a single integrated workflow. Flosum, an end-to-end enterprise DevSecOps platform purpose-built for Salesforce, generates audit trails for compliance reporting, provides version control and rollback, and supports policy-based deployment controls within one platform. Flosum DevOps offers three deployment options, Salesforce-native, cloud, and customer-hosted, which is relevant here because the deployment model determines where change evidence is held, a question UK reviewers do ask.
If you are starting from nothing, four steps will tell you where you stand within a week. First, confirm which Salesforce contracting entity your agreement names, because that single fact determines whether your use of the platform creates a restricted transfer at all. Second, pull the current sub-processor list and mark which entries sit outside the UK. Third, match each of those to a mechanism, checking DPF list status where you intend to rely on the UK Extension. Fourth, try to produce a dated Transfer Risk Assessment and the change history for one of them.
Whatever that exercise cannot produce is your actual gap, and it is almost always the evidence rather than the mechanism.
When review deadlines approach, a well-structured change record shortens audit preparation significantly. Request a demo with Flosum to explore how automated audit trails can support your compliance requirements.
Frequently Asked Questions (FAQ)
Thank you for subscribing
