Copilot data residency in Australia: what 'data stays in your tenant' actually means

Every regulated Australian organisation sitting on a Copilot decision eventually arrives at the same question: when Copilot runs a query against our data, where does that processing happen, and what leaves the country? The Microsoft answer is carefully worded and largely reassuring, but 'largely' is doing real work in that sentence, and the details matter for organisations subject to Privacy Act obligations, the Australian Prudential Regulation Authority's CPS 234, or Health Records Act requirements.

This guide maps what Microsoft's data residency commitments for Microsoft 365 Copilot actually cover, where the boundaries are, and what configuration steps an Australian organisation needs to take to confirm its position before deployment. Frontrow has walked a number of regulated AU clients through this assessment; the gaps that surface are consistent.

What Microsoft commits to for AU tenants

Microsoft provisions M365 Copilot tenants in the geography corresponding to the tenant's billing address at the time of licence assignment. For Australian tenants, that means the Australia datacenter region, the Sydney and Melbourne facilities in Microsoft's AU pair. The commitments cover customer data at rest and customer data in transit within the M365 services.

For M365 Copilot specifically, Microsoft's data protection addendum (DPA) commits to processing and storing the inputs and outputs of Copilot queries, the prompts and responses, within the tenant's provisioned geography, subject to the standard M365 data residency terms. The EU Data Boundary model, which Microsoft has made more explicit in its published guidance, has an AU equivalent: AU customer data does not leave the AU tenant geography for M365 core workloads.

Where the commitment has boundaries

Connected experiences and Bing-grounded features

Not all Copilot features are covered equally. Connected experiences, those that call external services, including Bing-grounded search in Copilot Chat, route through Microsoft's global infrastructure rather than the AU tenant geography. The Researcher agent introduced in Wave 2, which uses Bing for open-web grounding, is the most material example. When a user invokes Researcher, the external search component of that query processes outside the AU geography commitment.

This is configurable. In the Microsoft 365 admin centre under Settings > Org settings > Services, administrators can disable optional connected experiences and Bing-integrated features at the tenant level. Doing so restricts some Wave 2 capabilities but brings processing fully within the AU residency boundary. For organisations under APRA, ASD, or Department of Home Affairs data handling obligations, this is the configuration Frontrow recommends verifying first.

Copilot Studio and third-party connectors

Copilot Studio agents that use connectors to external systems, Salesforce, ServiceNow, third-party APIs, route data through those external endpoints, which are entirely outside Microsoft's data residency commitment. The Copilot Studio data policy in the Microsoft Power Platform admin centre is the control surface here. Policies should be reviewed against each connector's processing geography before any Studio agent is published inside a regulated tenant.

Diagnostic and telemetry data

Service diagnostic and telemetry data, the information Microsoft collects to operate and improve Copilot, flows to Microsoft's global infrastructure and is not subject to the per-geography data residency commitment. Under the M365 DPA, this data is classified as 'service-generated data' rather than 'customer data'. For most compliance frameworks, this is an accepted position, but it should be documented in the organisation's data handling register rather than assumed.

The Microsoft 365 Advanced Data Residency add-on

For organisations that need a stronger guarantee, Microsoft offers the Advanced Data Residency (ADR) add-on. ADR extends the at-rest data residency commitment to additional M365 workloads that are not covered by the standard commitment, including some Copilot telemetry and certain Exchange Online metadata. The ADR add-on is licensed per user and sits on top of the standard M365 subscription.

Frontrow's view is that ADR is worth evaluating for organisations under APRA CPS 234, for regulated health organisations, and for any business bidding on Australian Government ICT panels where data sovereignty is a selection criterion. For most other Australian businesses, the standard M365 data residency commitment is sufficient once connected experiences are appropriately configured.

The Microsoft Cloud for Sovereignty option

For defence, government, and critical infrastructure organisations that require a genuinely isolated cloud environment, Microsoft Cloud for Sovereignty on Azure provides a dedicated, compliance-assured deployment model. M365 Copilot in a sovereign cloud deployment operates entirely within that boundary. This is architecturally distinct from the standard commercial Copilot deployment and involves a separate procurement and configuration path. It is not the right architecture for most commercial organisations, but it is the correct answer for federal government agencies and critical infrastructure operators with specific data isolation requirements under the Security of Critical Infrastructure Act.

What to verify before deployment

1. 1Confirm the tenant's provisioned geography in the Microsoft 365 admin centre under Settings > Org settings > Organisation profile. It should read Australia.
2. 2Check whether optional connected experiences are enabled or disabled under Settings > Org settings > Services > Microsoft 365 optional connected experiences.
3. 3Review the Copilot settings section in the admin centre for any per-feature data handling notes introduced under Wave 2.
4. 4Audit any Copilot Studio agents for third-party connectors and review connector data policies in the Power Platform admin centre.
5. 5Document the position in the organisation's data handling register and information security management system, noting the boundary between customer data and service-generated data.

First 30 days, practical steps

For organisations in the early stages of Copilot deployment, Frontrow recommends completing the five verification steps above before any licences are issued to users in regulated roles. For organisations already live with Copilot, a retrospective configuration review against these points is worth running before a compliance audit asks the same questions.