NZISM Explained: The New Zealand Information Security Manual for Cloud and SaaS Providers

Short answer: The NZISM (New Zealand Information Security Manual) is the New Zealand government's manual of information assurance and systems security practice, published by the GCSB through its National Cyber Security Centre. Government agencies apply it to their systems, and SaaS or cloud providers selling to them are assessed against it during the agency's risk assessment and accreditation process.

Related guides:

• The ultimate ISO 27001 guide: how to build an ISMS and get certified
• ISO 27001 vs other frameworks: SOC 2, NIST, GDPR, and Cyber Essentials
• Data classification policy

Key takeaways

• The NZISM is published by the Government Communications Security Bureau (GCSB) through its National Cyber Security Centre (NCSC) and works alongside the Protective Security Requirements (PSR).
• It applies to New Zealand government departments and agencies and is recommended for other organisations, including suppliers that host or process government information.
• Controls use "must" and "should" language, and departures from them go through a formal risk acceptance process owned by the agency's Accreditation Authority.
• There is no NZISM certificate for vendors. Agencies accredit their own systems, so your job is to give them the evidence they need, usually by mapping your ISO 27001 or SOC 2 controls to the NZISM.
• The classification of the data you handle, and where it is stored, shape almost every question you will get.

---

What is the NZISM?

The NZISM is the New Zealand government's authoritative manual for securing information systems, covering both policy and technical controls.

It is published by the GCSB, with the NCSC responsible for its content. The manual sets out the minimum technical security standards the government expects agencies to apply, and explains the rationale behind controls so teams can make informed risk decisions.

The NZISM works alongside the Protective Security Requirements (PSR), the government's overall protective security framework spanning governance, personnel, physical and information security. The PSR sets out what agencies must achieve for information security, and the NZISM supplies the detailed technical practice.

The manual is organised into chapters that cover, in general terms:

• Governance, roles, certification and accreditation, and incident handling
• Physical and personnel security as they relate to ICT
• Communications infrastructure and product security
• ICT equipment and media management, including sanitisation and disposal
• Software security, access control and logging
• Cryptography and key management
• Network and gateway security
• Cloud computing, virtualisation and working off-site

The NCSC updates the manual periodically, so always work from the current version published on the GCSB's NZISM site rather than a copy saved in a shared drive.

Who has to follow the NZISM?

Government departments and agencies are expected to apply the NZISM, while other organisations, including suppliers, are encouraged to use it as good practice.

In practice the audience is wider than it looks:

1. Public service departments and agencies that fall under the PSR mandate. They carry the formal obligation.
2. Crown entities and other public sector bodies, which often adopt it by policy or contract.
3. Health sector organisations, including Health New Zealand | Te Whatu Ora, which may ask NZISM-based questions when assessing systems that handle health information, alongside health sector (HISO) standards.
4. SaaS vendors and cloud providers that host, process or connect to government information. You are not directly regulated, but the buying agency must show your service meets its requirements, and that obligation flows down through questionnaires, contract clauses and assurance reviews.

For an SMB or HealthTech startup, the trigger is usually procurement: a security questionnaire, a request for assurance reports and questions about how your controls line up with the NZISM.

How do "must" and "should" controls work?

NZISM controls are written with compliance language: "must" controls are mandatory, and "should" controls are recommended good practice.

This distinction matters for both agencies and vendors:

Language	What it means	What happens if you cannot comply
Must / must not	A mandatory requirement for systems in scope	The agency needs a documented case for non-compliance, a risk assessment and formal acceptance by the Accreditation Authority
Should / should not	Recommended practice that agencies are expected to follow unless there is a justified reason not to	The deviation and its rationale should be documented and considered as part of the system's risk profile

Non-compliance is allowed only through a transparent, recorded decision in which the agency weighs residual risk and compensating controls and an accountable senior person signs off. Many controls also apply differently by classification, so read each one alongside its applicability.

For vendors, this means a gap is not automatically a deal breaker. If you cannot meet a particular control, explain why, describe your compensating controls and give the agency enough detail to make its own risk acceptance decision.

Security classifications and why they drive scope

The classification of the information your service will hold is the single biggest factor in how much of the NZISM applies to you.

New Zealand's government classification system includes the following levels, from lowest to highest:

• UNCLASSIFIED
• IN-CONFIDENCE
• SENSITIVE
• RESTRICTED
• CONFIDENTIAL
• SECRET
• TOP SECRET

IN-CONFIDENCE and SENSITIVE cover information whose compromise would harm government functions, commercial interests or personal privacy. RESTRICTED and above are national security classifications with increasingly strict handling rules.

Most commercial SaaS and HealthTech products handle information at the lower end, such as personal or health data typically treated as IN-CONFIDENCE or SENSITIVE. Higher classifications bring much stricter requirements for vetting, cryptography and system separation that rarely suit a multi-tenant product. Confirm the expected classification with the agency before answering any questionnaire, and map your internal labels to it explicitly.

How does certification and accreditation work?

Under the NZISM, agency systems go through certification, where controls are assessed, and accreditation, where a senior official formally accepts the residual risk and authorises the system to operate.

The process typically looks like this:

1. Define the system. The agency sets the boundary, classification and connections.
2. Select controls. Applicable NZISM controls are identified by classification and system type.
3. Document the posture. Security documentation records which controls are in place, which are not, and why.
4. Certification. A Certification Authority reviews the evidence and recommends acceptance or remediation.
5. Accreditation. The Accreditation Authority, usually the agency head or a delegated senior executive, accepts the residual risk and accredits the system.
6. Ongoing assurance. Significant changes, incidents or the passage of time trigger reassessment.

When your service forms part of the system, your controls are part of what gets reviewed, and the agency relies on your documentation and audit reports to build its case.

What does the NZISM expect from cloud services?

The NZISM expects agencies to carry out a documented risk assessment before adopting public cloud services and to understand which controls the provider delivers and which remain the agency's responsibility.

For agencies, that usually means:

• Confirming the service is appropriate for the classification of data going into it.
• Understanding the shared responsibility model across the cloud platform, the SaaS vendor and the agency.
• Considering data sovereignty and jurisdiction, including where data is stored and whether offshore hosting is acceptable.
• Reviewing independent assurance such as ISO 27001 certificates and SOC 2 reports, and checking their scope.
• Planning for exit, including data return and deletion.

Vendors should expect questions about hosting regions, encryption, key management, tenant isolation, privileged access, logging, incident notification and subprocessors, and should be able to explain which controls they inherit from their cloud platform. Our overview of ISO 27017 cloud security controls is a useful companion for that conversation.

NZISM vs ISO 27001 vs SOC 2: how do they compare?

The NZISM is a prescriptive government control manual, ISO 27001 is a certifiable management system standard and SOC 2 is an independent attestation report, so they complement rather than replace each other.

Aspect	NZISM	ISO 27001	SOC 2
Owner	GCSB, through the NCSC	ISO and IEC	AICPA
Primary audience	New Zealand government agencies and their suppliers	Any organisation, worldwide	Service organisations, mainly selling into North American markets
Nature	Prescriptive technical and policy controls	Risk-based management system with a reference control set	Attestation against the Trust Services Criteria
Outcome	Agency certification and accreditation of a specific system	Certificate from an accredited certification body	Auditor's report (Type 1 or Type 2)
Control language	"Must" and "should", scaled by classification	Controls selected through risk assessment and justified in a Statement of Applicability	Organisation designs its own controls to meet the criteria
Handling gaps	Formal non-compliance and risk acceptance by the Accreditation Authority	Risk treatment decisions within the ISMS	Exceptions noted in the auditor's report
Vendor certificate available?	No. The agency accredits its own system	Yes	No certificate, but a shareable report

An ISO 27001 certificate or SOC 2 report is strong evidence for an NZISM assessment but does not answer every control. Data location, classification handling, cryptography and network architecture usually need extra attention.

How vendors prepare for an NZISM review

The fastest route is to reuse the security program you already have and fill the gaps that are specific to the New Zealand government context.

Preparation checklist

• Confirm scope and classification. Ask what classification the data will carry and whether your service will connect to agency systems.
• Map your existing controls. Build a crosswalk from your ISO 27001 Annex A controls or SOC 2 criteria to the relevant NZISM chapters. If you already maintain an ISO 27001 to SOC 2 mapping, extend it rather than starting again.
• Answer data residency questions clearly. Document where data, backups and logs live, who can access them and which subprocessors are involved.
• Document cryptography. Record algorithms, protocols and key management, including who controls the keys.
• Describe shared responsibility. Show which controls you operate, which your cloud platform provides and which the agency configures.
• Prepare for gaps honestly. Where you miss a "must" control, describe compensating controls and remediation plans.
• Package your evidence. Keep policies, audit reports, penetration test summaries and incident procedures ready to share under NDA.
• Align privacy obligations. Health and personal information in New Zealand also falls under the Privacy Act 2020 and, for health data, the Health Information Privacy Code, so security answers should be consistent with your privacy commitments.

For agencies assessing a vendor, the same checklist works in reverse: confirm the classification, request the crosswalk and assurance reports, test the residency and cryptography answers, and record any residual risks for the Accreditation Authority.

How SecureSlate helps

SecureSlate gives you a single control library mapped across frameworks, so the controls you already run for ISO 27001, SOC 2 or HIPAA can be mapped and tracked against NZISM-style requirements without duplicating work. Automated evidence collection from your cloud and SaaS stack keeps proof current, while policy templates, a risk register and vendor risk management help you document compensating controls and risk decisions the way agencies expect.

When an agency or Health New Zealand | Te Whatu Ora sends a security questionnaire, audit-ready exports and a trust center let you share policies, reports and answers quickly and consistently, which shortens the review that stands between you and a signed contract.

Start your free SecureSlate trial

FAQ

Is there an NZISM certification for SaaS vendors?

No. The NZISM does not certify vendors. Agencies certify and accredit their own systems, and your service is assessed as part of that process. What you can provide is strong evidence, such as an ISO 27001 certificate, a SOC 2 report and a clear mapping to NZISM controls.

Does my data have to be hosted in New Zealand?

Not always. Agencies decide based on the classification of the data, their risk assessment and current government policy on offshore hosting. Expect detailed questions about hosting regions and legal jurisdiction, and be ready to offer New Zealand or nearby hosting options if the data is sensitive.

How is the NZISM related to the Protective Security Requirements?

The PSR is the government's overall protective security framework covering governance, people, physical and information security. The NZISM provides the detailed technical practice that supports the information security part of the PSR.

Is ISO 27001 enough to satisfy the NZISM?

ISO 27001 covers much of the same ground and is valuable evidence, but it is not a substitute. The NZISM contains more prescriptive requirements in areas such as classification handling, cryptography and network architecture, so plan on a gap review and a control mapping.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.