Data Residency and Processing Location

Selecting a region during setup answers part of the question. Support access, sub-processors and backups answer the rest.

General description of common requirements. Rules differ by jurisdiction and change; take advice for your situation.

The questions that matter

Where is data stored at rest? The region you chose, usually.

Where is it processed? Not always the same. Analytics, machine learning features and search indexing may run elsewhere.

Where are backups held? Frequently a different region for resilience, and frequently not disclosed by default.

Where is support delivered from? A support engineer in another country accessing your tenant is a transfer, whatever the storage region says.

Who are the sub-processors and where are they? The vendor's own suppliers, each with their own locations.

Ask all five. Most vendors answer the first readily and the others only when asked specifically.

Why it matters

Regulatory requirements in several jurisdictions restrict transfers of personal data outside a region or require specific safeguards.

Sector rules in finance, health and government frequently impose stricter location requirements than general data protection law.

Contractual commitments you have made to your own customers, which may be stricter than the law.

Government access regimes differ by jurisdiction, and this is increasingly a factor in vendor selection rather than a theoretical concern.

What to record per application

Storage region.

Processing regions, including for optional features.

Backup regions.

Support access locations.

Sub-processor list and its last update.

The legal transfer mechanism relied upon, where a transfer occurs.

Whether a regional option exists and what it costs, since many vendors offer one at a premium that nobody asked about.

The sub-processor problem

Vendors use vendors. Your data reaches parties you have no relationship with.

Sub-processor lists change, and most contracts provide for notification rather than approval.

Subscribe to the notification where offered, and route it to someone who reads it.

Review the list annually for the applications holding regulated data.

A vendor who cannot produce a sub-processor list has either not thought about it or does not want to say, and both are findings.

Practical steps

Classify first. Residency requirements apply to specific data types. Knowing which applications hold regulated or personal data at scale tells you where to spend the effort.

Ask the five questions at procurement, when you have leverage, rather than during an audit.

Choose the regional option where it exists and the data warrants it, and budget for it.

Record the answers in the register, with the date, because they change.

Re-ask on vendor acquisition, which is the event most likely to move data.

What not to do

Assume the storage region answers the question.

Rely on a marketing page. Get it in the contract or the data processing agreement.

Treat it as a one-time check. Vendors change architecture, add features that process elsewhere, and acquire companies in other jurisdictions.

Apply the strictest requirement to everything, which makes the programme expensive and slow and produces no additional protection for the data that does not need it.

The five questions as a procurement template

Asking at procurement costs nothing and asking during an audit is expensive.

Where is our data stored at rest, by region?

Where is it processed, including for optional and analytical features?

Where are backups held?

From which countries can your support staff access our tenant, and is that access logged?

Who are your sub-processors, where are they, and how are we notified of changes?

Put them in the standard questionnaire for medium and high tier applications.

Record the answers with the date, and re-ask on vendor acquisition. Answers given verbally by a salesperson are worth recording and worth confirming in the contract for anything holding regulated data.

Regional options and what they cost

Many vendors offer a regional deployment at a premium that nobody asks about at purchase.

Ask whether one exists, for every application holding regulated or personal data at scale.

Ask what it costs, which is frequently a percentage uplift rather than a different product.

Ask what it constrains: some regional deployments lag on features or lack certain integrations.

Ask whether support access is also regional, since a regional data centre with support from elsewhere addresses only part of the question.

Decide at procurement, because migrating an existing tenant between regions is usually impossible without a full export and reimplementation.

Budget for it where the classification requires it, rather than discovering the requirement during an audit.