Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Keeping data in Australia: region controls, key custody, support access and APP 8

Technical article
Cloud

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Selecting an Australian cloud region does not by itself settle Australian Privacy Principle 8 (APP 8), and encrypting the data does not settle it either. APP 8 asks whether personal information was disclosed to someone overseas. Region policy, key custody and support approvals are the technical evidence for that answer, and they only work alongside the contract.

This is technical guidance, not legal advice. Have a privacy adviser assess the actual arrangement and validate policy designs in a test account. Identifiers are examples.

Interpretations are editorial; no lab testing was performed.

Why it matters

Before an APP entity discloses personal information to an overseas recipient, it must take reasonable steps to ensure the recipient does not breach the APPs, other than APP 1. Under section 16C of the Privacy Act, the entity is accountable for acts of the overseas recipient that would breach the APPs. That accountability has exceptions, covered below, but by default it stays in Australia even when the data does not.

"Data sovereignty" tends to merge three separate questions, and each has different controls:

Question Controls that answer it What they cannot answer
Where is the data stored and processed? Region restriction, replication settings Who can read it
Who can read it? Identity, key custody, provider access approval Whether a law can compel it
Whose law can compel it? Provider's corporate structure, contract terms Where the bytes sit

An Australian region provides evidence for the first row; replication and service-specific flows still need checking.

How it works

What APP 8 tests

The OAIC's guidelines draw the line between disclosure and use. An entity discloses when it makes personal information accessible to others outside the entity and releases subsequent handling from its effective control. It uses information when it handles it within its effective control. "Holds" extends beyond physical possession to a record the entity has the right or power to deal with.

An overseas recipient is a person who receives the information and is not in Australia or an external Territory, not the entity itself and not the individual. For a foreign-owned provider's Australian region, give your adviser three facts: which legal entity you contract with, where it is, and whether anyone outside Australia can access the data.

The guidelines apply the use and disclosure line to these cases:

Situation OAIC position in the chapter 8 guidelines
Overseas office of the same entity Not APP 8, because the recipient is the same entity
Overseas related body corporate APP 8 applies
Overseas contractor A disclosure in most circumstances, and subcontractors too
Routing through overseas servers in transit Usually a use; no disclosure until an overseas recipient is able to access or modify it
Unauthorised access in a cyber attack Not a disclosure, but may breach APP 11
Overseas cloud provider that only stores the data and ensures access May be a use, in limited circumstances

The guidelines say it may be a use where a binding contract limits handling to storing and ensuring access, subcontractors are bound the same way, and the contract gives the entity effective control. Issues to consider include the right or power to access, change or retrieve the information, who else can access it and for what purposes, the security measures, and retrieval or permanent deletion when no longer required or at contract end. Even then the entity still holds the information and may breach the APPs if it is mishandled.

Two points follow:

  • The test depends on the contract. A configuration setting cannot create "effective control" on its own. Technical controls show that the contract's limits are real.
  • Encryption is not decided in the text. Neither chapter says whether encrypted data sent overseas is disclosed. Chapter B mentions decryption software only in its holds test, and chapter 11 lists encrypting data as a technical security measure. A view that ciphertext sent overseas is not a disclosure is therefore a legal position to test.

If an arrangement is a disclosure, the default is an enforceable contract requiring APP handling, including subcontractors and a data breach response plan. Exceptions exist, including a reasonable belief in a substantially similar law or binding scheme with enforcement, a country or scheme prescribed by regulations, or consent after the person is expressly informed. We did not establish whether any country has been prescribed, so check the Federal Register of Legislation.

Region restriction on AWS

AWS states that you choose the Regions, and that it will not move or replicate content outside them "except as necessary to provide the services you initiated, or as necessary to comply with the law or a binding order of a governmental body". The two Australian Regions are Asia Pacific (Sydney), ap-southeast-2, enabled by default, and Asia Pacific (Melbourne), ap-southeast-4, disabled by default and so requiring opt-in.

The enforcement tool is the aws:RequestedRegion condition key. AWS publishes a deny pattern using NotAction to exempt global services. This is that pattern with the Region list changed to the two Australian Regions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideRequestedRegions",
      "Effect": "Deny",
      "NotAction": [
        "cloudfront:*",
        "iam:*",
        "organizations:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-southeast-2", "ap-southeast-4"]
        }
      }
    }
  ]
}

Warning: applied organisation-wide, this denies every other action outside those Regions, and it will break any workload that calls a global service you have not listed. AWS says to extend NotAction for the other global services you use. Test it on a non-production account first.

Its limits:

A bucket's Region and its replication destinations are separate facts:

aws s3api head-bucket --bucket example-bucket
aws s3api get-bucket-replication --bucket example-bucket

S3 replication can target buckets in other Regions or other accounts. Any Destination outside Australia needs an explanation. This check only detects a replication rule; it does not block one. The first command returns BucketRegion.

Region restriction on Azure

Microsoft states that it will not store or process customer data outside the customer-specified Geo without your authorisation, and that it may copy data between regions within the Geo. Most Azure services are regional, so the Geo depends on where you deploy.

The built-in Allowed locations policy, version 1.1.0 restricts matching resource deployment locations; it does not control every data-processing, support or replication flow. Its parameter is listOfAllowedLocations and its definition name is e56962a6-4747-49cd-b67b-bf8b01975c4c. Review the parameter design before assigning a policy:

The deployment policy can list australiaeast and australiasoutheast as allowed locations. Review its resource exclusions and evaluate existing resources in audit mode before planning enforcement. No policy-assignment command is supplied here because organisation-specific assignments and exemptions require validation.

Warning: this definition's effect parameter defaults to Deny, so without --enforcement-mode DoNotEnforce the assignment blocks non-compliant deployments at once. The definition also accepts an effect value of Audit. We composed this command from the references and have not run it. Remove the flag only after reviewing the results.

The Microsoft description says this policy excludes resource groups, Azure AD B2C directories and resources that use the 'global' region. A separate built-in covers resource groups. Global resources need a separate review.

Australia East pairs with Australia Southeast, so geo-redundant storage there stays in Australia. Microsoft says geo-redundant storage replicates within the same Geo, and its redundancy page advises locally redundant storage if governance requires replication only within a region. Read the redundancy and paired location on each account:

az storage account show --name examplestorage --resource-group example-rg

In the output, check sku.name, primaryLocation and secondaryLocation, which is only meaningful for a geo-redundant account. These are the properties in the REST reference, and az may nest them differently. To check that assignments exist, use az policy assignment list.

The exceptions are what to read closely:

Key custody: what each option changes

Option Where key material lives What you gain What remains true
AWS KMS, AWS-generated FIPS 140-3 Level 3 HSMs; keys never leave KMS unencrypted Key policy and audit AWS operates the service
AWS KMS, imported A copy in KMS, the original with you Expiry and deletion you control, without the 7 to 30 day deletion wait You remain responsible for the key material; ciphertext cannot be decrypted outside KMS
AWS external key store Your key manager outside AWS You control the root of trust; AWS KMS first encrypts with its own key material, so neither party alone can decrypt You own availability, durability and latency
Azure customer-managed key Key Vault or Managed HSM Disabling the key makes the listed data operations fail with 403; others can proceed, so read the list Azure still unwraps the account key to read and write
Azure Managed HSM Single-tenant, FIPS 140-3 Level 3, customer-specific security domain Isolation from other tenants. Microsoft claims complete customer sovereignty Still a Microsoft-run service, so test that claim against the three questions above
Azure Managed HSM external key management Key encryption key stays in your external HSM External custody Microsoft calls it a last-resort option when legal or contractual requirements mandate external custody

Three checks are worth doing on every key:

Check the key's Region and shape. A customer-managed key can sit in a different region and tenant from the storage account.

Check AWS keys for replication. Multi-Region keys share the same key material and key ID across Regions, which means one logical key exists outside Australia if a replica does. describe-key shows it, along with Origin (AWS_KMS, EXTERNAL, AWS_CLOUDHSM or EXTERNAL_KEY_STORE):

aws kms describe-key --key-id alias/example --region ap-southeast-2 \
  --query 'KeyMetadata.{Origin:Origin,Manager:KeyManager,Multi:MultiRegion,Regions:MultiRegionConfiguration}'

Replicating needs kms:ReplicateKey on the primary key and kms:CreateKey in the replica Region. To restrict where a multi-Region key can be replicated, use the kms:ReplicaRegion condition key, which limits only kms:ReplicateKey.

Check what is covered. Azure Queue and Table storage are not automatically protected when you enable customer-managed keys on an account.

Custody has a real cost. AWS says external key stores are a major departure from the shared responsibility model, and that the availability and latency risk will, for most customers, exceed the perceived security benefit. While access to the external key manager is disconnected, ciphertext cannot be decrypted; if access is permanently revoked, it becomes unrecoverable. Services that briefly cache data keys continue working until the resource is deactivated or the cache expires, so revocation is not always instant.

A key held by the customer also does not stop the provider's service from processing plaintext while the key is available to it (our reasoning from the unwrap flow). Customer-held keys let you stop the operations that depend on them.

Provider support access

AWS states it does not access or use your content without your agreement. Its Nitro paper goes further for one layer, stating no operator can log in to EC2 Nitro hosts or access instance memory or data on encrypted volumes. That statement covers EC2 on the Nitro System only.

On Azure, Customer Lockbox gives an approval step when a Microsoft engineer needs customer data. It needs a support plan of at least Developer level, and requests expire after four days if not actioned. Azure Storage and Virtual Machines are on the supported list; check yours.

Its exclusions matter as much as its function. Emergency access to restore service, prevent data loss or investigate security incidents is excluded, and external legal demands do not trigger a request. Nor does an engineer troubleshooting the platform who is inadvertently exposed to customer data, for example through a packet capture, although Microsoft says such cases rarely expose meaningful quantities of data.

One path no region control covers is your own staff. A support ticket with a memory dump or log file attached moves data by hand. AWS Support is one of the global services in the deny exception. Sanitise attachments and make it a procedure.

Foreign legal process

Under the US CLOUD Act provision, a provider must comply with disclosure obligations for data in its possession, custody or control, whether located inside or outside the United States. So location alone does not remove a provider subject to US jurisdiction from that reach (our reading; take legal advice on how it applies to your provider).

The US Department of Justice lists a US and Australia CLOUD Act agreement dated 15 December 2021. A joint statement by the two attorneys-general, now on the Department's archive, says the agreement has been brought into force, giving each country's authorities more timely access to electronic data held by service providers in the partner nation. Archived pages can be out of date, so confirm its status.

The OAIC addresses compulsion directly. Under section 6A(4), an act required by an applicable foreign law does not breach the APPs if done outside Australia, and the entity is not responsible for it under the accountability provision. Its example is the USA PATRIOT Act. That does not apply to acts done within Australia, so ask your adviser where a provider acting inside an Australian region stands. The OAIC suggests considering telling individuals that a foreign law may require disclosure. Section 16C also does not apply to a disclosure under an APP 8.2 exception, or to a recipient with an Australian link.

AWS says it will try to redirect a government demand to the customer, and will give notice unless prohibited. Microsoft says it will not give third parties direct or blanket access, or platform encryption keys. These are provider statements. Compare them with your contract.

For Australian Government workloads, the Hosting Certification Framework is a separate regime.

What to choose and why

A workable order:

  1. Classify the data. Find which systems hold personal information. APP 8 applies only to personal information held.
  2. Map every flow. Include backups, replicas, logs, monitoring, identity, email and support channels.
  3. Get the legal position on each provider. Use or disclosure, and which APP 8 path applies, is your adviser's call.
  4. Write the contract terms against the 8.14 list. Purposes, subcontractors, access, security, and return or deletion.
  5. Enforce location. Use the deny policy or Allowed locations, in audit first where a DoNotEnforce mode or Audit effect is available.
  6. Choose custody by threat. Use provider-managed keys unless you have a specific need. Move to customer-managed keys when you need the ability to revoke. Take external custody only where a requirement mandates it, as both AWS and Microsoft, for Managed HSM external key management, advise.
  7. Keep evidence. Export policy assignments, replication settings and key metadata on a schedule.

Risks and limits

Deletion is part of the test. The guidelines list retrieval or permanent deletion at contract end. APP 11.2 separately requires reasonable steps to destroy or de-identify information no longer needed. That obligation has exceptions, including legally required retention and Commonwealth records. Plan the lifecycle of immutable backups, replicas and logs accordingly.

Breach duties still apply. Under the Notifiable Data Breaches scheme, organisations and agencies the Privacy Act covers must notify individuals and the OAIC when the eligible-data-breach criteria are met, taking applicable exceptions and effective remedial action into account, and must quickly assess a suspected breach. An entity disclosing under APP 8.1 is deemed to "hold" the information for the scheme and stays responsible for assessing an eligible data breach, unless it disclosed under an APP 8.2 exception. Your incident plan needs a named contact at each provider.

Claims to avoid:

  • "Data never leaves Australia." Identity, global services and support make this hard to prove.
  • "It is encrypted, so APP 8 does not apply." The chapters read do not say so.
  • "A customer key means the provider cannot access the data." While the key is available, the service can use it.
  • "Sydney region, so no foreign law applies." Location does not decide jurisdiction.

Provider documents change. These are vendor statements as of 10 November 2026, and service lists move. Recheck them at each review, and read the contract terms that actually bind you.

Sources

Opened 10 November 2026.

This article was originally published on .