Regulation explainerAzure Copilot
Azure OpenAI data residency: where prompts are processed and where data is stored
Asking where Azure OpenAI keeps your data has two answers. Data at rest stays in the Azure geography of your resource; inference processing happens wherever your deployment type allows, from any region worldwide to one geography. This page explains the deployment types, the stored data and abuse monitoring that sit beside inference, how GDPR, DORA and the EU Data Boundary bear on the choice, and the controls that make it enforceable. It is a technical explainer, not legal advice.
On this page
- Processing location and storage location are separate questions
- Deployment types and where each one processes prompts
- Terms that get mixed up in residency reviews
- How GDPR, DORA and the EU Data Boundary bear on the choice
- Locking down the network path and service identities
- Abuse monitoring: stored prompts and who may review them
- Choosing a deployment type by requirement
- Making the decision stick after design sign-off
- Questions and answers
- Sources
Processing location and storage location are separate questions
Microsoft's documentation separates two things. Data stored at rest, such as uploaded files, fine-tuning data and the history behind stateful features, remains in the Azure geography where the resource was created. Inference processing, meaning the computation on prompts and responses, follows the deployment type you select12.
Azure OpenAI is now offered through Microsoft Foundry, and Microsoft groups its models with other models sold by Azure under the same data commitments2. The naming matters mostly when searching the documentation: the residency rules below apply to Azure OpenAI deployments created through Foundry, whichever portal you use.
Deployment types and where each one processes prompts
Within the standard (pay per token) and provisioned (reserved capacity) categories you choose global, data zone or geography-based processing; batch and developer types add asynchronous and evaluation options1.
| Deployment type | Where inference is processed | Billing model | When it fits |
|---|---|---|---|
| Global Standard | Any Azure region where the model is deployed | Pay per token | No location restriction; new models usually arrive here first |
| Global Provisioned | Any Azure region | Reserved provisioned throughput units | Steady high volume that needs lower latency variance |
| Global Batch | Any Azure region | Discounted asynchronous jobs | Large offline workloads with no location restriction |
| Data Zone Standard, Provisioned or Batch | Only within the Microsoft-defined zone: United States, European Union or Asia Pacific | Per token, reserved or batch | Zone-level residency with more capacity than single-geography types |
| Standard (regional) | Within the customer-specified Azure geography | Pay per token | Country-level requirements at low to medium volume |
| Regional Provisioned | Within the Azure geography | Reserved provisioned throughput units | Country-level requirements with predictable throughput |
| Developer | Any Azure region, with no data-residency guarantee | Pay per token | Short-lived evaluation of fine-tuned models only |
Model availability differs by deployment type and region, and geography-based types typically receive new models last1.
Terms that get mixed up in residency reviews
- Azure geography
- A grouping of one or more Azure regions, often a single country, that bounds data at rest and the regional deployment types.
- Data zone
- A Microsoft-defined group of regions used by Data Zone deployments. The EU zone follows the EU Data Boundary, which can include EFTA countries such as Norway and Switzerland, and Microsoft can add regions to a zone without prior notice1.
- EU Data Boundary
- Microsoft's commitment to store and process customer data and personal data for its enterprise online services within the EU and EFTA, subject to documented limited transfers4.
- Data at rest
- What the service itself stores: uploaded files and vector stores, Responses API history, Assistants threads, stored completions and the abuse monitoring data store2.
- Modified abuse monitoring
- A Limited Access arrangement under which an approved customer's prompts and completions are not stored for human abuse review, although automated review can continue3.
How GDPR, DORA and the EU Data Boundary bear on the choice
Location is one input to a transfer and risk assessment, not the whole of it. These instruments come up most often in European reviews.
General Data Protection Regulation (Regulation (EU) 2016/679), Chapter V
EU and EEAApplies whenPrompts, retrieved documents or outputs contain personal data and processing may take place outside the EEA, as it can under Global deployment types5.
- Establish whether a transfer occurs and rely on a valid mechanism, such as an adequacy decision or standard contractual clauses5.
- Record which deployment types are allowed for which categories of personal data.
GDPR Articles 28 and 35[^5]
EU and EEAApplies whenMicrosoft processes personal data for you through the service, and the assistant handles it at scale or in new ways.
- Confirm the processor terms, set out for this service in Microsoft's Products and Services Data Protection Addendum2.
- Run a data protection impact assessment where high risk is likely, recording the deployment type and stored-data features.
DORA, Regulation (EU) 2022/2554
EU financial entitiesApplies whenA bank, insurer, investment firm or other in-scope entity uses Azure OpenAI as an ICT service supporting its functions6.
- Contracts must state the regions or countries where services are provided and where data is processed and stored, and require advance notice of changes to those locations6.
- Cover the service in ICT third-party risk management, the register of contractual arrangements and exit planning.
EU Data Boundary (Microsoft contractual commitment)
EU and EFTAApplies whenAzure regional services are deployed in an EU Data Boundary region; the EU data zone for Azure OpenAI follows the same boundary41.
- Create resources in EU or EFTA regions and use Data Zone EU or regional deployment types for processing inside the boundary.
- Review Microsoft's documented limited transfers and confirm they are acceptable for your data categories4.
Locking down the network path and service identities
Residency covers where data goes; network isolation covers who can reach it on the way.
Disable public network access
Set the Foundry resource's public access to disabled and reach it through an approved private endpoint in your virtual network7.
Resolve the endpoint privately
Link the privatelink DNS zone to your network, or delegate it from your own DNS servers, so clients keep the same endpoint name7.
Use managed identities between services
Authenticate the orchestrator, Azure AI Search and Foundry with managed identities and role assignments instead of keys7.
Control outbound traffic from agents
With Foundry Agent Service, inject agents into a delegated subnet and route egress through a firewall; some agent tools still use public endpoints7.
Keep your own logs in the same geography
Logs, traces and evaluation results your code writes fall outside Microsoft's commitments, so place those workspaces in the deployment's geography.
Abuse monitoring: stored prompts and who may review them
Choosing a deployment type by requirement
- If
No contractual or regulatory limit applies to processing location, and you want the newest models.
ThenGlobal Standard, or Global Provisioned for steady volume.
Global types have the widest availability and usually receive new models first1.
- If
Processing must stay inside the EU, the United States or Asia Pacific.
ThenData Zone Standard or Data Zone Provisioned, with the resource created in a region inside that zone.
Data Zone types process prompts and responses only within the Microsoft-defined zone1.
- If
Processing must stay within one country's Azure geography.
ThenStandard or Regional Provisioned in that geography, after confirming the model is offered there.
Geography-based types are the narrowest boundary, but they get new models last and lower default quotas than Data Zone types1.
- If
You are an EU financial entity and contracts require advance notice of new processing locations.
- If
You are testing a fine-tuned model on regulated data.
ThenDo not use the Developer type for that data; evaluate on a regional or Data Zone deployment instead.
Developer deployments carry no data-residency guarantee1.
Making the decision stick after design sign-off
Questions and answers
Is every model available as a Data Zone or regional deployment?
No. Not all models support all deployment types, and new models typically launch as Global first, then Data Zone, then geography-based types, with no guaranteed date for the last step1. Check the availability tables on Microsoft Learn before promising a team a specific model under a residency constraint.
Where are fine-tuned models and their training data stored?
Training data and fine-tuned models are stored at rest in the resource's geography, are available only to your organization and can be deleted by you2. Where a fine-tuned model is processed once it serves traffic depends on the deployment type used to host it, so the same residency decision applies again at inference time.
Does the EU data zone include Switzerland and Norway?
The EU data zone follows the Azure EU Data Boundary, which Microsoft says can include EFTA countries such as Norway and Switzerland alongside EU member states1. Microsoft can also add regions to a zone without prior notice, so treat the zone as a legal-geographic boundary rather than a fixed list of datacenters1.
If we log prompts ourselves, do Microsoft's residency commitments still cover them?
No. Microsoft's commitments cover the service's own processing and stored data. Prompts, retrieved passages and answers that your application writes to logs, traces, evaluation stores or analytics tools are under your control. Place those stores in the right geography, restrict access to them and set retention according to the same assessment that chose the deployment type.
Are our prompts used to train the models?
Microsoft states that prompts, completions, embeddings and training data are not available to other customers or to OpenAI, and are not used to train generative AI foundation models without your permission or instruction2. That is separate from residency, but both usually appear in the same procurement review.
Sources
- Understanding deployment types in Microsoft Foundry Models — Microsoft Learn · checked 10 October 2026
- Data, privacy, and security for Foundry Models sold by Azure — Microsoft Learn · checked 10 October 2026
- Foundry Models sold by Azure abuse monitoring — Microsoft Learn · checked 10 October 2026
- What is the EU Data Boundary? — Microsoft Learn · checked 10 October 2026
- Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex · checked 10 October 2026
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) — EUR-Lex · checked 10 October 2026
- How to configure network isolation for Microsoft Foundry — Microsoft Learn · checked 10 October 2026