Teams that build or run systems for New Zealand government agencies are expected to meet the New Zealand Information Security Manual (NZISM), yet many treat it as a long checklist rather than a risk-based control set with a formal approval process behind it. The NZISM is maintained by the Director-General of the Government Communications Security Bureau (GCSB), acting as Government Chief Information Security Officer, through the National Cyber Security Centre (NCSC). This guide explains who it applies to, how its MUST and SHOULD controls and classification tags work, how certification and accreditation turn controls into an authority to operate, and which controls matter most for identity, privileged access and non-human identities such as service accounts. It is written for agency CISOs, IT security managers, system owners and the vendors and consultants who supply them. It covers version 3.9, the version shown on the official NZISM site when checked in November 2026. The Australian equivalent has its own page: see the Australian ISM Guide.
Key takeaways
- Mandatory for agencies, encouraged for others. Section 1.2 applies the NZISM to departments and organisations listed in Schedule 1 of the Ombudsmen Act 1975 and Schedule 1 of the Official Information Act 1982, and to any organisation with a formal agreement to access classified information; Crown entities, local government and private sector organisations are encouraged to use it.
- MUST is baseline, SHOULD is good practice. The manual uses RFC 2119 language: MUST and MUST NOT controls are baseline "systems hygiene" and take precedence over SHOULD and SHOULD NOT controls (1.1.45 to 1.1.47).
- Non-compliance is a documented decision, not a gap. Not meeting a MUST control needs a dispensation from the Accreditation Authority backed by a risk assessment (1.1.64.C.01, 1.1.65.C.01); not meeting a SHOULD control must be recorded and the residual risk acknowledged (1.1.69.C.02).
- No system goes live without accreditation. Chapter 4 requires every system to be audited and certified (4.2.10.C.01, 4.5.17.C.01) and the Accreditation Authority to accept the residual risk before accreditation (4.5.18.C.01).
- Version 3.9 rewrote identity. Chapter 16 is now "Authentication and Access Controls", with a 16 character minimum password, phishing-resistant MFA, passwordless options, a PAM policy and an inventory of privileged accounts that explicitly includes accounts held by systems and devices.
What it is and who it applies to
The NZISM sets out processes and controls for protecting New Zealand government information and systems. It sits inside the Protective Security Requirements (PSR) framework, which states the government's protective security expectations as directed by Cabinet. The manual traces back to the NZSIT policies of the early 1990s, became the NZISM in 2010, was rewritten as version 2.0 in 2014 and moved to an online platform with version 3.0 in 2018, with downloads in PDF, XML and CSV. Updates have been more frequent since. The change overview dates version 3.9 to April 2025 and the online document page shows a last update of November 2025.
| Audience | Position under the NZISM | Source |
|---|---|---|
| Public service departments and bodies in Schedule 1 of the Ombudsmen Act 1975 (Parts 1 and 2) and Schedule 1 of the Official Information Act 1982 | In scope; controls apply to their systems and related services | 1.2.3 |
| Organisations with a formal agreement to access classified government information | In scope for those systems | 1.2.3 |
| Crown entities, local government, private sector | Encouraged to use it as good practice | 1.1.2 |
| Vendors, contractors and consultants supplying agencies | Named audience; agency contracts usually pass the requirements down | About the NZISM |
| Smaller agencies | May consolidate security resources with a host agency | 1.2.10 |
Agencies designing new systems must use the latest version of the NZISM (1.2.15.C.01). Chief executives remain accountable for managing cyber risk in their own agencies, so the manual informs a risk decision rather than replacing one.
Structure and key requirements
Version 3.9 has 24 chapters. Chapters 1 to 7 cover governance, documentation, monitoring and incidents. Chapters 8 to 13 cover physical, personnel, infrastructure, communications devices, product security and media. Chapters 14 to 23 hold the technical controls, from software and email security through authentication, cryptography, networks, gateways, enterprise systems, data management, distributed working and public cloud. Chapter 24 is the glossary.
| Chapters | Theme | Examples of what they require |
|---|---|---|
| 1 to 3 | Using the manual, government services, roles | Compliance language, non-compliance process, cloud services (2.3), post-quantum preparation (2.4), Agency Head, CISO, ITSM, system owner duties |
| 4 to 5 | Certification, accreditation and documentation | C&A process, audits, Security Risk Management Plan, System Security Plan, SOPs, incident response plan, vulnerability disclosure policy (5.9) |
| 6 to 7 | Monitoring and incidents | Security reviews, vulnerability analysis, change management, BCDR, incident detection, reporting and management |
| 12 to 14 | Product and software security | Product selection, patching, supply chain (12.7), application allow listing (14.2), application and web development (14.4, 14.5) |
| 16 to 17 | Authentication, access and cryptography | Identification, privileged access, PAM, remote access, logging, MFA, approved algorithms and protocols, key management, HSMs |
| 18 to 23 | Networks, gateways, enterprise and cloud | Wireless LANs, IDS/IPS, firewalls, cross domain solutions, virtualisation, databases, BYOD, public cloud identity and logging (23.3, 23.5) |
How a control reads
Each section has an Objective, Context, References and a Rationale and Controls block. Rationale items carry IDs such as 1.1.64.R.01 and controls IDs such as 1.1.64.C.01. Each control header shows the classifications it applies to and its compliance level, with a CID number, for example "All Classifications; Compliance: Must". Version 3.9 also changed wireless controls: WPA MUST NOT be used, WPA2 SHOULD NOT be used, WPA3 SHOULD be used, and CONFIDENTIAL and above MUST use EAP-TLS or PEAP-EAP-TLS.
Classifications and baselines
- Baseline set: UNCLASSIFIED, IN-CONFIDENCE, SENSITIVE and RESTRICTED share one set of baseline controls, and all baseline controls apply to all government systems, related services and information (1.1.4, 1.1.5).
- Classified uplift: CONFIDENTIAL, SECRET and TOP SECRET systems carry additional controls on top of the baseline (1.1.5).
- Tagging: "All Classifications" covers every level including caveats and releasability endorsements (1.1.26), so filter the CSV or XML export by classification before scoping a system.
Compliance language and non-compliance
| Level | Meaning | If not implemented |
|---|---|---|
| MUST / MUST NOT | Baseline control; non-use is high risk (1.1.45) | Dispensation from the Accreditation Authority (1.1.64.C.01), supported by a system owner risk assessment covering reasons, effect on other systems, alternative mitigations, residual risk and a review date (1.1.65.C.01); records kept (1.1.69.C.01) |
| SHOULD / SHOULD NOT | Good or recommended practice; valid reasons for not using it include irrelevance or an equivalent control (1.1.47) | Formally recorded, residual risk acknowledged by the Accreditation Authority (1.1.69.C.02), reviewed at least annually (1.1.68.C.01) |
| Out of scope | Control does not apply to the system | Non-compliance process does not apply (1.1.42) |
The manual separates a waiver from an exception: a waiver is short term and conditional, while an exception is a dispensation for the term of the accreditation certificate or less (1.1.23, 1.1.24). Where classified information belongs to another agency, a foreign government or an All-of-Government system, its owners must be consulted before a non-compliance decision (1.1.66, 1.1.67).
Identity and NHI requirements
Chapter 16 was the largest change in version 3.9. The change overview says password controls now follow NIST guidance, with longer minimums and no complexity rules, adds passwordless and phishing-resistant MFA, extends logging to event monitoring, and aims to support Zero Trust and the New Zealand Government Digital Identity Standards.
| Control | Level | Requirement (summarised) | NHI relevance |
|---|---|---|---|
| 16.1.26.C.01 | MUST | All system users uniquely identifiable, authorised and authenticated each time access is granted | Give each workload its own identity rather than reusing one account across services |
| 16.1.27.C.02 | MUST NOT | No shared credentials for administrator or privileged accounts (break glass exempt) | Shared deployment or admin service credentials breach this |
| 16.1.28.C.01 | MUST | Where shared, non-user-specific accounts are allowed, an independent, logged means of identifying the user | Attribute actions taken through generic or automation accounts back to a person or pipeline |
| 16.1.31.C.03 | MUST | Passwords of at least 16 characters, long, strong and unique | Apply to service account passwords, or replace them with keys and certificates |
| 16.1.31.C.02 | MUST | At least annual password change on systems without MFA or passwordless authentication | Rotation schedules for static service account secrets |
| 16.1.39.C.01 and C.02 | MUST | Disable authentication methods open to replay, and LAN Manager | Legacy protocols often survive on old service accounts |
| 16.4.37.C.02 | MUST | Two-factor or MFA for privileged account access | Human access to vaults and consoles that hold machine credentials |
| 16.4.40.C.01 | MUST | Inventory of privileged accounts, access rights and credentials | Must include privileged service, system and device accounts |
| 16.4.41.C.01 and C.02 | MUST | Continuous discovery, monitoring and review of privileged accounts, including unusual patterns and unauthorised credential creation | Baseline service account behaviour and alert on new keys |
Section 16.4 is where non-human identity becomes explicit. It defines service accounts (running processes such as web and database servers) and system or application accounts (used by devices and systems to run operating system components) in 16.4.9, states in 16.4.12 that systems and devices, not just people, may hold privileged access and must each be individually identified, and lists accounts running Windows services, scheduled tasks, IIS application pools and network equipment in 16.4.33. There is no separate control set for machine accounts, so they fall under the general PAM controls: policy (16.4.36), least privilege (16.4.37.C.01), formal approval before credentials are issued (16.4.38), suspension and revocation (16.4.39), inventory (16.4.40) and monitoring (16.4.41). For practical methods, see the Service Account Security Guide and NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
- Break glass: 16.4.14 to 16.4.18 give guidance (not tagged controls) that emergency accounts are used only when normal authentication fails, are not tied to one person, are logged centrally, are tested after credential changes and have split passwords or FIDO2 keys held in separate safes. The text both excludes them from the MFA policy and says they should have MFA through other mechanisms, so document how your design satisfies both. See the Break-Glass Account Guide.
- Zero Trust and SSO: 16.1.25.C.01 (SHOULD) asks agencies to design Zero Trust principles into identification management, and 16.1.30.C.01 (SHOULD) asks them to assess the risk of centralised access management, including SSO and federated identity.
- Time-bound privilege: 16.4.37.C.03 (SHOULD) asks agencies to consider time-bound revocation of privileged accounts, the closest the manual comes to just-in-time access.
Implementation steps
- Confirm scope and version. Record the system's classification, whether it touches All-of-Government or other agencies' systems, and that design work uses NZISM 3.9 or later (1.2.15.C.01).
- Build the control baseline. Export the CSV or XML, filter to the system's classification, and mark each control applicable, not applicable (with reason) or inherited from a provider. Chapter 23 and section 2.3 add controls for public cloud.
- Write the documentation set. Chapter 5 expects a Security Risk Management Plan, a System Security Plan, SOPs, an incident response plan and emergency procedures. Use the NZISM baseline security templates on the official site as a starting point.
- Close identity gaps first. Inventory privileged human and machine accounts, remove shared admin credentials, enforce MFA on privileged access, apply the 16 character password floor or move service accounts to keys or certificates, and disable LAN Manager.
- Record non-compliance properly. For each MUST you cannot meet, prepare the 1.1.65 risk assessment and seek a dispensation; for each SHOULD, record the reason and get residual risk acknowledged. Set review dates.
- Certify, then accredit. Commission the audit (4.2.10.C.01), let the Certification Authority accept the controls and recommend (4.2.11, 4.2.12), then present the pack to the Accreditation Authority (4.5.18).
- Operate and re-assess. Run change management (6.3), vulnerability analysis (6.2) and security reviews (6.1), and trigger recertification when the system or its risk changes significantly.
Evidence and assessment
Section 4.1 describes certification and accreditation as two separate functions so that conflicts of interest are managed. Certification is an assessment, usually an audit, confirming the system meets NZISM minimum standards and relevant legislation. Accreditation is the Accreditation Authority's decision that residual risk is acceptable and the formal authority to operate.
| Role | Who | Responsibility |
|---|---|---|
| System Owner | Business owner of the system | Designs, documents and maintains the system; requests recertification or reaccreditation |
| Certification Authority | Normally the CISO; lead agency for multi-agency or AoG systems | Reviews evidence, accepts controls as appropriate and effective, recommends |
| Assessor or auditor | Internal or external, directed by the Certification Authority | Inspections, audits and reviews; segregation from the Certification Authority preferred |
| Accreditation Authority | Agency head or delegate at least at senior executive level; Director-General GCSB where High Assurance Cryptographic Equipment or caveated or compartmented information is involved | Accepts residual risk, issues authority to operate, advises affected agencies and the GCDO for AoG systems (4.5.18.C.02, C.03) |
Rationale 4.5.18.R.04 lists what the Accreditation Authority should see: the information security documentation from Chapter 5 including the SRMP and SSP, records of interaction with other agencies' or All-of-Government systems, compliance audit reports, the certification recommendation, supporting documents for any non-compliance, records of extra risk reduction and third-party assurance reports. In exceptional cases a system may operate before certification, but only if that is formally recorded and accepted, and certification must still happen as soon as possible (4.5.15, 4.5.16).
Useful measures for a system owner: share of applicable MUST controls implemented or dispensed, number of open dispensations past their review date, share of privileged accounts (human and machine) in the 16.4.40 inventory with a named owner, share of privileged access protected by MFA, and time from a significant change to recertification.
Mapping to other frameworks
The mapping below is indicative and drawn from the control text; the NZISM does not publish an official crosswalk on the pages checked.
| NZISM area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Certification and accreditation (Ch 4) | GV.RM-04 | CA-2, CA-6 | 5.35 Independent review of information security |
| Non-compliance records (1.1.64 to 1.1.69) | GV.RM-04 | CA-5 | Clause 6.1.3 information security risk treatment |
| System Security Plan (5.4) | GV.PO-01 | PL-2 | 5.1 Policies for information security |
| Identification and authentication (16.1, 16.7) | PR.AA-01 | IA-2, IA-5 | 5.16 Identity management, 5.17, 8.5 |
| Privileged access management (16.3, 16.4) | PR.AA-05 | AC-2, AC-6 | 8.2 Privileged access rights |
| Event monitoring and logging (16.6) | PR.PS-04, DE.CM-03 | AU family | 8.15 Logging, 8.16 |
| Vulnerability analysis and patching (6.2, 12.4) | ID.RA-08 | RA-5, SI-2 | 8.8 Management of technical vulnerabilities |
For readers moving between the two Five Eyes manuals, the Australian ISM Guide covers the Australian control set. Personal information held in NZ agency systems also falls under the New Zealand Privacy Act Guide.
Common pitfalls
- Treating SHOULD as optional. A SHOULD control that is not used still needs a written reason and the Accreditation Authority's acknowledgement of residual risk; silence is non-compliance.
- Leaving service accounts out of the privileged inventory. 16.4.12 and 16.4.33 make clear that services, scheduled tasks, application pools and devices hold privilege; an inventory of human admins alone fails 16.4.40.C.01.
- Shared admin credentials in automation. A deployment account whose password several engineers and pipelines share breaches 16.1.27.C.02. Move to per-pipeline identities and a vault. See the Secrets Management Guide.
- Accrediting once and forgetting. Dispensations carry review dates and SHOULD decisions need annual review; changes to architecture or classification should trigger recertification.
- Using an old version. Teams still working from 3.8 or earlier miss the 3.9 identity, incident reporting and wireless changes; 1.2.15.C.01 requires the latest version for design.
- Blurring certification and accreditation. When the same person assesses, certifies and accepts risk, the separation in 4.1 is lost and the evidence pack is weaker.
Practitioner checklist
- Confirm the system classification and that design uses NZISM 3.9 or later.
- Export the control set, filter by classification and record applicability for every control.
- Produce the SRMP, SSP, SOPs and incident response plan before audit.
- Inventory privileged human, service, system and device accounts with owners (16.4.40.C.01).
- Remove shared privileged credentials and enforce MFA for privileged access (16.1.27.C.02, 16.4.37.C.02).
- Apply the 16 character password minimum or replace service account passwords with keys or certificates.
- Disable LAN Manager and replayable authentication methods (16.1.39).
- Document every MUST dispensation and SHOULD non-use with a risk assessment and review date.
- Keep certification and accreditation roles separate and file the 4.5.18.R.04 evidence pack.
Standards and references
- GCSB NCSC: New Zealand Information Security Manual, ISM Document
- GCSB NCSC: About the NZISM
- GCSB NCSC: NZISM Change Overview
- GCSB NCSC: NZISM Latest Updates
- GCSB NCSC: NZISM 4.1 The Certification and Accreditation Process
- GCSB NCSC: NZISM 4.5 Conducting Accreditations
- GCSB NCSC: NZISM 16.1 Identification, Authentication and Authorisation
- GCSB NCSC: NZISM 16.4 Privileged Access Management
This guide summarises the New Zealand Information Security Manual and is not legal advice. Related NHI Mgmt Group resources: Australian ISM Guide · Privileged Access Management Guide · Service Account Security Guide · Break-Glass Account Guide