Māori GIS risk register

A risk register is useful when it describes how a project could actually go wrong. It does not need to turn kaupapa, tikanga or relationships into corporate risk scores.

Use the examples below as prompts. Delete the ones that do not fit and rewrite the consequences in terms of the real mahi.

Risk	What can happen in GIS	Possible consequence	Practical response
Context lost	a point or polygon survives after its source and kōrero are separated from it	later users misunderstand what the feature represents	keep source reference, date, representation type and useful whakapapa/context with the record
False map certainty	approximate, interpreted or relational information is drawn with precise geometry	readers treat a representation as legal, surveyed or definitive	label geometry type, uncertainty and source; show multiple representations where useful
Wrong dataset for the question	cadastral, environmental or statistical data are used outside the purpose they support	map answers a different question from the one people think it answers	record what each source is authoritative for and its limitations
Public copy contains too much detail	a working layer is published unchanged	information intended only for the working task becomes widely copied	create a public/shared version with only the geometry and fields that serve that audience
Spatial inference	ordinary layers become revealing when combined	a location, relationship or pattern becomes easy to infer	test likely joins/overlays and decide whether a less detailed shared version is sufficient
Metadata leakage	filename, title, extent, thumbnail or tags reveal more than the visible map	people can infer subject or location from the catalogue itself	review the whole published item, not only the feature geometry
Copy proliferation	exports accumulate across laptops, email, cloud folders and partner systems	nobody knows which copy is current or where old data sits	keep a simple copy/version record for important datasets and make current versions obvious
Vendor lock-in	project depends on proprietary formats, identities or custom apps	exit becomes expensive or technically difficult	keep routine exports, documentation and an independent usable copy
Consultant dependency	supplier holds the tenant, credentials, code or undocumented know-how	organisation cannot continue the GIS without the supplier	organisation-held accounts, shared administration and practical handover
One-person dependency	one kaimahi holds the passwords and project knowledge	GIS becomes inaccessible when they leave or are unavailable	at least two people can recover the system; short runbook; succession practice
Hosting mismatch	project data are stored or processed somewhere the organisation did not expect	contractual, jurisdictional or organisational requirements are missed	record actual hosting/processing arrangements and compare them with the project's needs
Hardware failure	only working copy is on one computer/server	data loss or long interruption	independent backups and a tested restore
Credential compromise	account or device is compromised	disclosure, deletion or ransomware	MFA, sensible account roles, protected backups and patching
Funding ends	subscriptions or specialist support become unaffordable	service closes or data become hard to reach	design a minimum sustainable state and keep an export/exit path
Format/app obsolescence	application or proprietary format stops being supported	information becomes difficult to reuse	open/portable exports, metadata and periodic migration
Secondary organisational use	a supplied dataset enters a wider agency or partner workflow	information is used beyond the project people expected	make the supplied version, purpose and retention arrangements explicit
AI reuse	documents, imagery or GIS layers are submitted to an AI service with broader processing terms	material may be retained, evaluated, reused or produce new inferred information	treat AI as a separate technical use; inspect current service behaviour; use local/private processing where it fits
Too little access	useful information becomes so difficult to reach that whānau or kaimahi recreate it elsewhere	duplication, shadow copies and lost benefit	design access around actual working groups and audience needs rather than one blanket restriction
Deletion misunderstood	live record is removed while backups/exports remain	people assume every copy disappeared	document what deletion means across live systems, backups and archives
Weak provenance	source, version or method is unclear	an old or derived map becomes mistaken for the source	source register, status/date fields and visible lineage
Data quality failure	categories, locations or completeness do not support the kaupapa	poor analysis or unusable outputs	design fields around the real question; report gaps and uncertainty

Use it with the project team

For each relevant risk:

1. describe what it would look like in this project
2. describe the consequence in plain language
3. identify the practical change that would reduce the problem
4. note who is doing that work
5. record any cost or trade-off
6. revisit it when the platform, audience or source data changes

A restoration project, historical archive and public iwi profile will have different risk pictures. That is expected.

Balance risk and benefit

Reducing one risk can create another. A completely disconnected system may reduce external access while making whānau collaboration, remote work and disaster recovery harder. A highly simplified public map may protect detail but become too vague to explain the kaupapa.

Use the Benefits register beside the risk register so the project does not optimise itself into uselessness.

Useful companion pages

• What belongs in GIS?
• Sensitive places
• Inference risk
• Consultants and contracts
• The one-person problem
• Ten-year cost models

Last reviewed: 26 August 2026