Skip to main content

Data residency is not data sovereignty

No. New Zealand data residency is not enough by itself to establish Māori Data Sovereignty. Residency can reduce some risks and may be an important preference, but it tells you principally where information is stored or processed. It does not by itself decide Māori authority, provider jurisdiction, administrator control, copying, secondary use, AI use, migration or long-term capability.

Five different questions

QuestionConcept
Where is the information stored or processed?residency
What laws and state powers can apply?jurisdiction
Who physically or technically holds it?custody
Who makes and enforces decisions about use?governance
Whose authority and interests should determine those decisions?sovereignty

Treating these as synonyms creates weak procurement decisions.

Why New Zealand residency can still matter

Keeping data in Aotearoa can:

  • reduce some cross-border exposure
  • simplify latency and operational arrangements
  • align with Māori and government preferences for some data classes
  • make provider and support relationships easier to understand
  • support local capability and infrastructure

Current Digital Government guidance on sharing Māori data states that, where possible, Māori data should be stored in Aotearoa New Zealand by a majority-owned Aotearoa New Zealand company or agency to enhance control for current and future generations. That is an important policy position for agencies.

It still does not answer every governance question.

Territorial reach

GCDO's Cloud Jurisdictional Risk guidance explains that jurisdictional exposure can arise through more than the physical location of a data centre. A provider's corporate domicile and legal obligations can matter. A foreign-headquartered provider operating New Zealand infrastructure can therefore present a different legal-risk profile from a New Zealand-owned provider, even if both store the relevant workload locally.

That does not mean the foreign service should never be used. It means the risk should be assessed accurately rather than hidden behind the word onshore.

A local provider can still create weak control

Imagine a New Zealand-hosted GIS where:

  • the consultant owns the account
  • only the consultant is administrator
  • there is no complete export
  • backups cannot be independently restored
  • no one knows what happens when payment stops
  • the organisation has no internal capability

The data are resident in New Zealand, but practical control is weak.

Now compare a managed service with:

  • organisation-owned identity and billing
  • two internal administrators
  • explicit location and processing terms
  • strong security
  • tested open-format export
  • independent archive
  • clear exit and deletion provisions

Residency is one dimension. Governance quality is another.

Overseas hosting can still have strong controls

An overseas service may provide excellent technical security, resilience, access control and portability. Those benefits can be real. It may also create jurisdictional or cultural concerns that another architecture does not.

The decision should therefore compare actual risks, benefits and capability, not slogans.

A practical residency assessment

Record separately:

  1. primary storage country or region
  2. processing locations
  3. backup and disaster-recovery locations
  4. support-access locations
  5. provider legal entity and domicile
  6. subprocessors
  7. encryption model and key control
  8. account ownership
  9. export and exit capability
  10. Māori governance requirements

If a supplier cannot answer the first five clearly, New Zealand hosted is too vague for a sensitive procurement.

Government requirements are not a universal Māori rule

The Government's Cloud First policy applies to public-service organisations within its scope. It requires case-by-case assessment and consideration of te ao Māori perspectives for Māori data. Hapū and iwi may find the guidance useful without being bound to make the same architectural choice.

Sources

Last verified: 16 August 2026