Data Residency Is Not an Architecture
[NAVIGATION LINKS: none for this article]
Six years. That is how long section 214 of the Privacy Act 2020 has sat on the statute book without being used.
Section 214 lets the Governor-General, by Order in Council, prescribe countries whose privacy laws New Zealand regards as comparable to its own. Prescribe a country, and Information Privacy Principle 12 gets much simpler for every agency and every company sending personal information there. The Ministry of Justice consulted on exactly this in late 2020, asking which countries should be prioritised for assessment. The consultation closed on 4 December 2020. No government response has been published. The Ministry still lists prescribed countries as future work on its regulatory stewardship page.
No countries have been prescribed. No binding scheme regulations have been made under section 213 either.
For architects, that single fact disposes of the most common assurance in the New Zealand cloud market. Australia is not on a whitelist, because there is no whitelist. When a vendor tells you their Sydney region satisfies your cross-border obligations, they are not citing a determination. They are citing an assumption.
That is the small problem. The large one is that most residency conversations are answering a question nobody asked.
The question is not where the data lives
Ask an architect where a system's data is hosted and you will get a country. Sometimes a city. Occasionally a region identifier.
None of those is an answer, because a modern platform does not have one location. It has at least four, and they are frequently different.
Storage is where records rest. This is the only one most residency clauses address, and it is the one vendors answer readily because it is the one they have engineered to be answerable.
Processing is where computation happens in real time. Artificial intelligence platforms and modern software as a service routinely decouple the two. Inference can run in a region other than the one holding the primary database, and for AI features it very often does, because model serving capacity is concentrated where the accelerators are.
Logging is where operational and diagnostic records land. Application logs, audit trails and error traces carry the content of what was done and frequently fragments of the data it was done to. They are almost never covered by a residency clause because the clause was drafted about the database.
Telemetry is where support and product data flows. Usage metrics, crash dumps, performance traces, and the diagnostic packages a support engineer collects when a ticket is raised. This is the least visible and, for a system holding sensitive information about people, often the most exposed.
An agency that secures onshore storage and does not ask the other three questions has secured one quarter of the problem and reported it as the whole.
This is not an argument against offshore hosting. It is an argument against believing you have characterised your exposure when you have only characterised your database. The failure mode is not a bad decision. It is a decision made against an incomplete map, then recorded in a risk register as though the map were complete.
What IPP 12 actually requires
Information Privacy Principle 12 restricts disclosure of personal information outside New Zealand. It permits it on several distinct grounds. The recipient is subject to the Privacy Act itself. The recipient is subject to comparable safeguards, whether through the law of that country or through contract. The individual expressly authorises the disclosure having been informed that comparable protections may not apply. Or the recipient is subject to the laws of a country prescribed under section 214.
The prescribed country limb is dead. It has never been used. That leaves the comparable safeguards limb, which in practice means the Privacy Commissioner's model contract clauses, and the agency's own assessment that the safeguards are comparable.
There is a threshold question underneath all of this that many assessments skip. If the vendor acts only as a processor on the agency's behalf, section 11 treats the information as held by the agency, and IPP 12 may not be engaged at all, because no disclosure to a third party has occurred. Government guidance supports that reading, and it is sound under normal operating conditions.
It is less sound at the moment it matters. When a foreign statute compels the vendor to disclose, or to provide access, the vendor is no longer acting solely on the agency's behalf. It is acting under compulsion of another state's law, potentially under a prohibition on telling the agency it has done so. The processor characterisation is difficult to sustain in that scenario, and if it falls away, full IPP 12 obligations apply to a transfer that was never assessed against them.
That argument follows from the statutory text. It is untested. No published determination confirms it, and an architect should present it as an argument requiring formal guidance rather than as settled law. Flagging it honestly is better than resolving it optimistically.
What is actually binding, and what only sounds binding
Here is where most New Zealand residency arguments go wrong in both directions.
The Cloud First policy, as it currently stands following the April 2023 Cabinet refresh, contains nine requirements. Two of them bear on this decision, and the difference between them is the whole argument.
The first is a must: organisations "must only store data classified as RESTRICTED or below in a public cloud service." That is a hard ceiling on classification, and the New Zealand Information Security Manual restates it in its cloud computing guidance, noting that the ceiling applies "whether it is hosted onshore or offshore."
The second is a should: organisations "should over time, store RESTRICTED information in a New Zealand-based data centre, where a suitable onshore service exists."
Read those together and the position is clear, and it is not the position most sovereignty arguments assume. Offshore hosting of RESTRICTED information is permitted. It is not an exception, it does not require a dispensation, and an architect who tells a governance body otherwise will be corrected by the first person in the room who has read the policy. What is prohibited is putting CONFIDENTIAL and above into public cloud at all, onshore or offshore.
The onshore requirement is conditional in three ways at once. It is a should rather than a must. It is qualified by "over time." And it applies only "where a suitable onshore service exists."
Note also the provenance. The RESTRICTED ceiling is a Cabinet requirement restated by the NZISM, not an NZISM control in its own right. Attributing it to the NZISM alone is imprecise, and precision matters when the assessment is going to a chief executive.
The NZISM does carry its own control on the offshore question, and it is more interesting than the ceiling. Control 2.2.5.C.02 provides that agencies should not engage industry for off-site information technology services in countries with which New Zealand does not have a multilateral or bilateral security agreement. That control is keyed to alliance structure rather than to commercial assurance, and applied honestly it points towards Australia rather than away from it. An architect building the sovereignty case has to engage that, not route around it. The NZISM separately requires that cloud risks be identified, understood and formally accepted by the agency head or chief executive together with the accreditation authority, and that agencies cannot outsource accountability for protecting their data.
One requirement added in the 2023 refresh deserves more attention from architects than it gets, because it is rarely read as a design constraint. Organisations must implement a multi-cloud policy that ensures resilient digital infrastructure. Set that next to the residency question and the two turn out to be the same conversation approached from different directions. Both are about not concentrating exposure in a single place you do not control. The drift in most agencies runs the other way, towards consolidation onto one hyperscaler, because the commercial and operational case for one platform is far easier to write than the case for two.
The condition that just changed
"Where a suitable onshore service exists" was, for most of the life of the Cloud First policy, a condition that failed. There was no hyperscale region in New Zealand, so the onshore preference cost nothing to acknowledge and nothing to act on.
That has changed, recently and completely.
Microsoft opened the Azure New Zealand North region in Auckland in December 2024. Amazon Web Services made its Asia Pacific (New Zealand) region generally available on 1 September 2025, its first infrastructure region in the country, against a stated investment of NZD 7.5 billion. The Government Chief Digital Officer runs a Public Cloud Data Centre Certification scheme that standardises the physical and personnel security assessment of onshore facilities so that agencies do not each repeat it, with the first certifications granted in March 2025.
And in June 2025 the Government Communications Security Bureau opened Mātai at the Royal New Zealand Air Force base at Whenuapai, an all-of-government facility for the most sensitive government information, its name gifted by mana whenua Ngāti Whātua o Kaipara. Reported cost, NZD 326 million.
Take those four developments together and the architectural position is different from the one the guidance describes. Above the public cloud ceiling, there is now a domestic home. Below it, there are now onshore hyperscale regions in the two largest platforms. The condition attached to the onshore preference is satisfied far more often in 2026 than it was in 2023.
Which means the word "should" now costs something. An agency choosing offshore hosting for RESTRICTED information today is making a live choice against an available alternative, not acknowledging a theoretical preference it cannot act on. That is a different conversation to have with an accreditation authority, and it is a different sentence to write in a risk acceptance record.
There is a further wrinkle worth naming. The government's own Cloud Jurisdictional Risk guidance was last updated on 14 August 2024. It predates the AWS Auckland region, the first certifications under the certification scheme, and Mātai. It is a careful document, and its analytical framework holds up. Its picture of what is available onshore does not.
Onshore is not the same as sovereign
The guidance makes one point that deserves more attention than it gets, because it cuts against the conclusion people reach too quickly.
Jurisdictional risk does not disappear at the border. A data centre in Auckland owned or operated by a vendor incorporated overseas remains subject to the laws that reach that vendor. The guidance puts the doctrine plainly: data lawfully accessible in one state and stored or processed in another does not engage extra-territorial considerations, which is to say that both the state of storage and the state with legal reach over the provider may be able to obtain it.
So "we moved it to the Auckland region" answers the storage question and leaves the corporate jurisdiction question untouched. Sovereignty is a property of legal reach, not of geography, and an architecture that treats the two as the same thing has substituted a map for a legal analysis.
The same reasoning disposes of two other assurances that arrive in every vendor pack.
Certification does not answer jurisdiction. A vendor holding ISO 27001 or SOC 2 has demonstrated the maturity of its internal controls. Those controls describe how the vendor protects data from unauthorised access. Lawful access by a host government is, by definition, authorised access under the law of that jurisdiction. The certification is silent on it.
Encryption does not answer jurisdiction either, unless you follow the keys. Encryption is a sovereign control only where the legal authority and the technical capability to compel decryption both remain in New Zealand. Where the vendor holds or can access the keys, a foreign authority can compel the vendor to produce plaintext, and the encryption has protected the agency from everyone except the party of concern. The question to put in the architecture document is not "is it encrypted." It is "who can be lawfully compelled to produce the decrypted data, and under whose law."
What to ask, and what evidence closes the question
The value in a residency assessment is not the conclusion. It is whether each answer is backed by a document rather than an assurance. Six questions, each with the artefact that closes it.
Where does data rest, including backups, replicas and disaster recovery copies? Backups and recovery copies frequently sit in a different region from the primary and are the most commonly missed element. Evidence: a vendor architecture statement, in writing, naming regions for each.
Where does real-time processing occur, and is it the same region as storage? Evidence: an end-to-end data flow map confirmed by the vendor in writing, not a statement of storage location.
Where do operational logs, diagnostic data and support telemetry go, including through sub-processors? Evidence: a vendor telemetry statement with the sub-processor list attached.
Who can be lawfully compelled to produce decrypted data? Evidence: the key management design with the compulsion analysis stated explicitly.
What is the classification ceiling of the system? Nothing else can be settled until this is known, and agencies frequently do not know it, because content accumulates in a document management system for years without systematic marking. Evidence: a signed classification review, commissioned before the vendor conversation, not after.
Has the vendor priced an onshore option? Cost is a legitimate consideration and should be quantified rather than dismissed. It should also be quantified rather than assumed. Ask for the number. The condition in the Cloud First policy turns on whether a suitable onshore service exists, and the honest way to test that is to price it.
Write each answer as a data location contract term rather than a general residency clause. A general clause will be satisfied by an onshore database served by offshore compute. Specify storage and processing and logging and telemetry by name, or the clause will not cover them.
A word on what to do when the answers do not arrive. Vendors sometimes decline to provide a written data flow map, or answer the storage question and treat the other three as commercially sensitive. That refusal is itself an answer, and it should be recorded as one. An unanswered question is not a low risk. It is an unquantified risk, and the difference matters at the point where a chief executive is asked to formally accept residual risk. Write it into the record as unknown rather than as acceptable, and put the gap in front of the person whose signature is required. If the organisation then decides to proceed without the answer, that is a legitimate decision, and it should be minuted as a decision rather than left as a silence.
One further element sits underneath all of this and deserves its own treatment rather than a paragraph. A material portion of the information held by New Zealand public sector systems is Māori data, and Māori data carries obligations that do not travel with it when it leaves the country. The Cloud First policy requires agencies to consider te ao Māori perspectives for Māori data in adoption decisions, and the jurisdictional risk guidance cites Te Kāhui Raraunga directly on the inherent rights and interests Māori hold in the collection, ownership and application of Māori data. Identifying what Māori data a system actually holds is harder than it sounds, because it is rarely in a discrete repository. That is the subject of a following article, and it deserves the full length.
Two jurisdictions, one dataset
The lawful access question is not abstract. The instruments are specific. Australia's Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018, known as TOLA, creates three tiers of industry assistance, of which technical assistance notices and technical capability notices are mandatory for designated providers operating there. The Telecommunications Legislation Amendment (International Production Orders) Act 2021 inserted a framework into the Telecommunications (Interception and Access) Act 1979 enabling Australian agencies to compel disclosure irrespective of where data is stored. The United States Clarifying Lawful Overseas Use of Data Act reaches providers under United States ownership regardless of storage location, and the Australia to United States bilateral agreement under it came into force on 30 January 2024. A dataset held in Sydney by a United States owned provider therefore sits within reach of two legal systems, neither involving a New Zealand court. That is a design input, not a compliance footnote.
The instinct when a governance body asks about data residency is to answer with a country. Resist it. Answer with four locations, a key management design, and a note on who holds legal reach over the corporate entity. If you cannot answer all four, say which one you cannot answer and what evidence would close it.
What is the residency assurance you were given that turned out not to cover what you assumed it covered?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of any client, government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. He writes The Hamberger Report.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] New Zealand Government. "Privacy Act 2020, section 214: Regulations (prescribed countries)." Reprint as at 27 November 2025. https://www.legislation.govt.nz/act/public/2020/0031/latest/LMS138198.html
[2] Ministry of Justice. "Have your say about cross-border disclosures under the Privacy Act 2020." Consultation opened 27 October 2020, closed 4 December 2020. https://consultations.justice.govt.nz/policy/privacy-cross-border-disclosures/
[3] Ministry of Justice. "Regulatory stewardship: Privacy." Accessed 22 August 2026. https://www.justice.govt.nz/justice-sector-policy/regulatory-stewardship/regulatory-systems/civil-law/privacy/
[4] Office of the Privacy Commissioner. "Information Privacy Principle 12: Disclosure of personal information outside New Zealand." https://www.privacy.org.nz/privacy-act-2020/privacy-principles/12/
[5] Department of Internal Affairs. "Cloud First policy: Cabinet requirement." Page last updated 19 December 2025. https://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/cloud-services/cloud-adoption-policy-and-strategy/cabinet-requirement
[6] Department of Internal Affairs. "Proposals for refreshing the Cloud First policy and strengthening cloud adoption across the public service." Cabinet paper, April 2023. https://www.digital.govt.nz/assets/Documents/2023-Cabinet-paper-Proposals-for-Refreshing-the-Cloud-First-Policy-and-Strengthening-Cloud-Adoption-Across-the-Public-Service.pdf
[7] Department of Internal Affairs. "Cloud jurisdictional risk guidance." Last updated 14 August 2024. https://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/cloud-services/assess-the-risks/cloud-jurisdictional-risk-guidance
[8] Government Communications Security Bureau. "New Zealand Information Security Manual, version 3.9." Released May 2025, document last updated November 2025. Section 2.3 Using Cloud Services; control 2.2.5.C.02; control 2.3.27.C.02; Chapter 23 Public Cloud Security. https://nzism.gcsb.govt.nz/ism-document
[9] Government Communications Security Bureau. "NZISM frequently asked questions: cloud computing." https://nzism.gcsb.govt.nz/resources/faq/cloud-computing
[10] Department of Internal Affairs. "Public Cloud Data Centre Certification: certified facilities and areas." Register last updated 25 July 2025. https://www.digital.govt.nz/products-and-services/products-and-services-a-z/public-cloud-data-centre-certification-pcdcc/certified-pcdc-facilities-and-areas
[11] Government Communications Security Bureau. "All-of-government data centre opened at Whenuapai ceremony." 27 June 2025. https://www.gcsb.govt.nz/news/all-of-government-data-centre-opened-at-whenuapai-ceremony
[12] Amazon Web Services. "Now Open: AWS Asia Pacific (New Zealand) Region." 1 September 2025. https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-new-zealand-region
[13] Commonwealth of Australia. "Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018, No. 148, 2018." https://www.legislation.gov.au/C2018A00148/latest/text
[14] Commonwealth of Australia. "Telecommunications Legislation Amendment (International Production Orders) Act 2021, No. 78, 2021." Assented 23 July 2021. https://www.legislation.gov.au/C2021A00078/asmade
[15] Australian Government Department of Home Affairs. "Australia to United States CLOUD Act Agreement." Brought into force 30 January 2024. https://www.homeaffairs.gov.au/about-us/our-portfolios/national-security/lawful-access-telecommunications/australia-united-states-cloud-act-agreement