Apps Script data residency: scope checks

Apps Script data residency should be assessed across the automation's full data path. Check what Google's regional policy covers, then identify the other services, destinations and logs involved. A regional setting for part of the workflow is not evidence that every step follows the same boundary.

For a small business using spreadsheet automations, this is a practical design review: describe what moves, where it goes and which owner can explain each part.

What Google made generally available

On 16 September 2026, Google announced general availability of data regions support for Apps Script. Its policy scope includes script files, code, manifests, trigger metadata, Property Service and Cache Service at rest, plus supported runtime operations for processing. Existing organisation policies apply. Google's Apps Script data regions announcement.

The announcement lists in-region storage and processing for Enterprise Plus and Frontline Plus, and storage only for Education Standard and Education Plus. External services and custom cloud logging require separate review. Edition and service boundaries therefore matter before you describe an automation as regionalised. Availability and coverage details.

This announcement does not establish UK-only processing or automatic compliance for your business. The following mapping exercise is practical guidance for reviewing a workflow, rather than a legal conclusion or a promise about unsupported services.

Draw the workflow before checking the setting

Take one automation and write its steps in order. An illustrative example could read an approved supplier list from a spreadsheet, transform selected fields and send an update to another business system. Include where errors and operational events are recorded.

For each step, identify the information involved and the service handling it. Avoid describing the whole workflow as "in Google" when one step calls an external destination or copies information into a separate log.

Ask the technical owner to inspect the actual script and configuration. A process diagram supplied when the automation was first built may no longer describe what it does today.

Separate the coverage questions

Build a small map with these four columns. The example rows are questions to investigate, not claims about a particular implementation.

Link each answer to the current policy, configuration or supplier evidence. Mark a component unresolved when the team cannot establish its treatment, rather than copying the answer from a neighbouring row.

Keep storage and processing distinct

Check whether your organisation's edition and policy cover storage, processing or both for the relevant component. Preserve that distinction in project notes and supplier discussions. Do not compress a limited answer into an unrestricted statement that data "stays in the region".

Ask which other controls or settings affect the workflow. Before changing a setting, have the responsible administrator assess what functionality could be affected and how they would test the result. A data-location objective still needs a functioning, understood business process.

Use a test case with suitable non-production information to trace expected destinations. Record what that test demonstrates and what depends on provider documentation; a successful test cannot independently prove the provider's internal processing location.

Decide what to change and who owns it

Finish with a short decision record: accepted components, unresolved destinations, changes needed and the person responsible for each action. Possible actions might include removing unnecessary fields, choosing a different destination or obtaining clearer supplier evidence. Assess them against the actual requirement rather than assuming every integration must be rebuilt.

Set a review trigger for new destinations, material script changes or edition and policy changes. Keep the map with the automation's maintenance notes so a later developer can see why a boundary was chosen.

For help assessing automation data boundaries and evidence requirements, explore IT compliance consulting. Bring the script's purpose, connected services and the data-location questions your team needs to resolve.