Templates and registers
These are optional starting points for projects that need a written record. Adapt, shorten or ignore them to suit the kaupapa. They are not a substitute for the relationships and decisions around the work.
Decision context register
This can be useful where somebody returning to a dataset later will need to know why it exists and how the current version has been used.
| Field | Record |
|---|---|
| Dataset / knowledge group | |
| Kaupapa | |
| People or decision process | |
| Knowledge holder or source relationship | |
| Intended uses | |
| Intended audiences | |
| Spatial detail | |
| Derived analysis in the current kaupapa | |
| Public version, if any | |
| AI use in the current kaupapa, if any | |
| Review trigger or date | |
| Contact / role | |
| Notes / contested interests |
Only record personal or cultural detail here when it is actually useful to the purpose of the register.
Sensitive-layer review
For a layer where location or attributes could matter, these questions can help shape a shared version:
- What is the current kaupapa?
- Who is the intended audience?
- Is exact geometry useful for this output?
- Would a generalised version do the same job?
- Could the map imply more certainty than the source supports?
- What can be inferred using parcels, imagery, elevation, roads, historic maps and environmental data?
- What does the metadata reveal?
- Are attachments part of the intended output?
- Are all fields useful to this audience?
- Can users export or cache the data?
- Does access need to be temporary for this project?
- What change would prompt another review?
Copy register
For datasets with several working or external copies, a simple register can show where they have gone:
| Copy | Location / provider | Purpose | Custodian | Audience | Users / group | Created | Review | Status |
|---|---|---|---|---|---|---|---|---|
| Main working copy | ||||||||
| Backup | ||||||||
| Disaster recovery | ||||||||
| Mobile/offline | ||||||||
| Test/development | ||||||||
| Consultant | ||||||||
| Archive | ||||||||
| Public derivative |
Add rows for material exports and research copies where useful.
Cloud assessment worksheet
Organisation and use
- Who owns the subscription or tenant?
- Who are the organisational administrators?
- What kaupapa will the service support?
- What kinds of data are expected to be held there?
- What material, if any, will stay elsewhere?
Location and jurisdiction
- Primary storage region/country:
- Processing locations:
- Backup/DR locations:
- Support-access locations:
- Provider contracting entity:
- Provider domicile:
- Relevant foreign jurisdiction considerations:
- Subprocessors:
Security
- MFA available/enforced:
- Role model:
- Encryption in transit:
- Encryption at rest:
- Customer-managed keys if relevant:
- Logging available:
- Incident notification:
- Backup restore tested:
Data lifecycle
- Complete export format:
- Attachments exportable:
- Metadata exportable:
- Deleted-data retention:
- Backup expiry:
- Exit process:
- Egress/exit cost:
- Independent archive location:
AI
- Is content used for shared model training?
- Is content used for evaluation or product improvement?
- Can AI features be disabled?
- Are prompts/outputs retained?
- How would use of AI change the original kaupapa or audience?
Supplier questionnaire
Questions worth getting clear answers to before relying heavily on a GIS or data supplier include:
- Who owns the tenant, account and billing relationship?
- Who owns the domain and certificates?
- Who holds administrator rights?
- Where is each data class stored?
- Where is it processed?
- Where are backups and disaster-recovery copies?
- Which subprocessors are used and where?
- What legal jurisdictions may apply to the provider?
- What security certifications or assurance reports are available?
- Is customer material used for AI training, evaluation or unrelated model improvement?
- What activity and access logs are available to the client?
- What happens if payment stops?
- How is a complete export performed?
- Which spatial formats are available?
- Are attachments included?
- Is metadata included?
- Are relationships, schemas and coded values included?
- Is application configuration included?
- How long does deleted information remain in backups?
- What is the termination process?
- What is the exit or egress cost?
- Who owns custom source code?
- Where is that code stored?
- What documentation is delivered?
- What internal capability will exist after handover?
- How are supplier and subprocessor copies returned or deleted?
- How will a migration be tested before contract end?
Consultant handover checklist
At project close it can be useful to confirm:
- production accounts sit with the organisation continuing the work
- more than one organisational administrator can access the system
- domain and certificates are under organisational control
- source code is in the agreed repository
- main data have been exported
- attachments are included
- metadata and schema are included
- public derivatives are identified
- passwords/secrets are transferred securely
- supplier access is documented and can be removed
- backup and restore procedure has been demonstrated
- full export has been tested
- runbook is current
- licences and renewal dates are recorded
- known risks and unresolved issues are listed
- working copies and backup-retention arrangements are understood
- internal staff have had practical administration handover
Data-sharing agreement outline
For projects that need a formal data-sharing agreement, the headings below can help structure the discussion. Consequential agreements may also need legal advice. Te Kāhui Raraunga's 2026 Iwi Data Sharing Guidance is a useful reference for individual-level iwi data.
Parties and kaupapa
- parties
- kaupapa and expected iwi or collective benefit
- people or process involved in the sharing decision
- whether the purpose can be met without individual-level data
- effective period
Information
- datasets covered
- minimum information required
- whether information can be de-identified before transfer
- source
- spatial precision
- sensitive attributes
- metadata
- attachments
Use
- named purpose
- users/roles
- analyses expected
- whether the data will be linked or integrated with other datasets
- whether derived data will be created
- secondary uses that are outside the agreement
- public outputs
- mapping and precision arrangements
Decision context
- contacts
- consent or other requirements that apply to the particular data
- correction process
- review process
- handling of contested interests
- agreed benefit or capability contribution where relevant
Security and copies
- access controls across the full data pipeline
- storage/processing locations
- subcontractors
- exports
- mobile copies
- backups
- breach notification
AI
- whether AI forms part of the work
- purposes for which it will be used
- model training or product-improvement settings
- treatment of AI-derived spatial information
Return, archive and deletion
- data return format
- derivatives to return
- repatriation arrangements
- archive responsibilities
- retention period
- live deletion
- backup expiry
- evidence of destruction where the agreement calls for it
Termination
- what happens when the kaupapa ends
- continuing obligations
- transfer to another custodian
- dispute or escalation process
Annual recovery check
For systems expected to last, an occasional recovery check can confirm:
- another person in the organisation can find the data
- another administrator can recover the platform
- one backup has been restored
- a complete export still works
- external access still reflects current projects
- supplier details and costs are current
- important technology claims have been rechecked
Related pages
Source
Last reviewed: 25 August 2026