Skip to main content

Access and security

Security and Māori Data Sovereignty overlap, but they are not the same thing. A system can be technically secure while still being a poor fit for the kaupapa. It can also have strong kaupapa and weak operational security through shared passwords, missing backups or one administrator holding everything together.

This page is about the technical side: how a system carries access decisions into accounts, roles, devices and services.

More than public and private​

Different versions or workspaces can be set up for different audiences, for example:

  • public
  • public but generalised
  • whānau
  • hapū
  • named project or kaitiaki group
  • temporary external access
  • highly limited access
  • information kept outside the shared system

The point is not to impose these categories. They are examples of how technical access can reflect the way a particular kaupapa is organised.

See Who decides what?, Sensitive places and Publishing maps with sensitive locations.

A practical security baseline​

For a shared system holding important data, useful controls can include:

  • individual named accounts
  • multifactor authentication where supported
  • roles matched to actual jobs
  • organisation-owned accounts and subscriptions
  • more than one capable organisational administrator
  • managed passwords or secrets
  • protected devices where data are downloaded
  • protected backups
  • a tested restore
  • logging for high-consequence material where useful
  • lost-device and compromised-account procedures
  • administrator succession
  • software patching and lifecycle planning
  • periodic export and account-recovery tests

The level of control can scale with the sensitivity of the material, number of users and size of the organisation.

Shared accounts make everything harder​

A login called gisadmin used by five people makes it difficult to know who changed a layer, exported data or altered a sharing setting.

Individual identities make ordinary administration, troubleshooting and accountability much easier. Emergency recovery credentials can still exist, but they are better kept for recovery than everyday work.

Separate technical roles where useful​

A larger system may separate:

  • identity administration
  • GIS editing
  • web publishing
  • external sharing
  • infrastructure administration

That separation is mainly operational. It does not turn a software role into cultural authority over the information.

Temporary external access​

Consultants, researchers and government partners often only need a particular dataset or workspace for a particular piece of work.

Useful technical options include:

  • read-only roles
  • named project groups
  • temporary accounts
  • time-limited credentials
  • separate shared versions rather than the main working dataset
  • removal of access when the work ends
  • export settings where they materially help

Screenshots and copied information can still travel, so technical settings work best when the purpose and expectations of the relationship are clear.

See Working with consultants, Templates and registers and Working with iwi, hapū and whānau.

MFA is useful, but it is only MFA​

MFA helps prevent account takeover. Encryption protects devices and traffic. Backups support recovery. Logs help explain what happened.

None of those technologies decides what belongs in GIS, what a place means, which representation is useful, or what tikanga applies. Those are different questions.

See What belongs in GIS? and Kaupapa Māori GIS.

Third-party providers​

The Office of the Privacy Commissioner states that organisations remain responsible for personal information stored or processed by third-party providers acting on their behalf. Its guidance also asks organisations to consider practical control, overseas providers and Māori data-sovereignty implications where relevant.

For GIS procurement, that means it is useful to know where data is stored, what provider accounts exist, what subprocessors are involved and how the organisation can recover or export its information.

See Cloud is not one thing and Data residency is not data sovereignty.

Recovery is part of security​

A system may need to recover after:

  • ransomware
  • accidental deletion
  • administrator departure
  • lost device
  • vendor failure
  • corrupted database
  • account lockout

A restore test tells you much more than a note saying backups enabled.

See Backups are data too, The one-person GIS and GIS succession.

A simple access review​

For an important dataset, it can be useful to know:

  1. Who can view it?
  2. Who can edit it?
  3. Who can change sharing settings?
  4. Who can export it?
  5. Who can administer the tenant or database?
  6. Who can restore a backup?
  7. Where do offline copies exist?
  8. Which external users still need access?
  9. Can more than one person recover the system?
  10. When were these settings last checked?

That is a technical inventory, not a tikanga checklist.

Sources​

Last verified: 26 August 2026

Last updated on