Skip to main content

The one-person problem

If one person is the only person who can recover the GIS, the organisation does not have durable control of it. This is one of the most ordinary and serious sustainability risks for small GIS programmes.

What it looks like​

  • one volunteer has all passwords
  • one employee understands the data model
  • one consultant owns the cloud tenant
  • the domain is registered in a personal account
  • scripts exist only on one laptop
  • only one person holds encryption keys
  • nobody else has restored the backup
  • the service account purpose is undocumented
  • the original administrator has left
  • users know the map URL but not where the source data are

Nothing needs to be malicious for the system to become inaccessible.

Why this is a sovereignty issue​

The organisation may formally own the data while lacking the practical ability to:

  • change access
  • recover it
  • migrate it
  • correct it
  • publish it
  • stop a service

Authority without operational capability can be fragile.

Minimum two-person rule​

For an important shared GIS, aim for at least two organisational people who can:

  • access administrative accounts
  • recover credentials
  • locate authoritative data
  • identify backups
  • contact suppliers
  • export the system
  • follow the recovery procedure

They do not both need to be expert GIS administrators. They need enough access and documentation to prevent complete dependency on one person.

Organisation-owned accounts​

Use organisational ownership for:

  • domain registration
  • cloud tenant
  • ArcGIS organisation
  • code repository
  • password vault
  • billing account
  • certificate management
  • storage accounts
  • supplier relationships

A named employee can administer them without personally owning them.

Write a one-page runbook​

For a small system, a concise handover can be more useful than a large manual nobody updates.

Include:

  1. what the system does
  2. where the authoritative data are
  3. platform and account owner
  4. administrators
  5. where credentials are managed
  6. backup locations
  7. how to restore or recover access
  8. important renewal dates
  9. supplier contacts
  10. how to export the full data
  11. what must not be made public
  12. last test date

Review it annually and whenever staff change.

Test succession​

Once a year, ask the secondary custodian to perform a small recovery exercise without the primary administrator doing it for them.

Examples:

  • sign in using documented recovery
  • locate the authoritative database
  • restore a test backup
  • export one layer and its metadata
  • identify the supplier agreement

The test often finds missing information before an emergency does.

Consultant dependency is the same structural problem​

A helpful consultant can provide capability while the client still owns and understands the system. A weak arrangement leaves the consultant indispensable.

See Working with consultants.

Practitioner note​

GIS capability building is often more durable when training includes administration and data management rather than only map production. People need to know not just how to make the map but how to keep the underlying system alive when the original trainer or specialist is no longer available.

Last verified: 16 August 2026

A common Māori GIS pattern​

This can happen in iwi, hapū, marae and community GIS when one kaimahi becomes the only person who knows the file structure, accounts, source history and how the map is produced. GIS succession and the one-person GIS guide turn that risk into practical handover work.

Last updated on