If your organisation moves workloads to the cloud and you operate within the New Zealand public sector, local government, or any agency handling government-classified data, the New Zealand Information Security Manual (NZISM) sets the standard you must meet. This NZISM compliance checklist covers the cloud-specific control areas most likely to generate findings during a security review — and gives you a practical framework to assess where you stand right now. Whether you are migrating to a hosted environment for the first time or reviewing existing cloud deployments against the latest NZISM version, this guide will help your IT team work through the requirements systematically.
What Is NZISM and Who Must Comply?
NZISM is published by the Government Communications Security Bureau (GCSB) and is New Zealand’s authoritative framework for protecting government information and information systems. Compliance is mandatory for all New Zealand government agencies, Crown entities, and their significant third-party service providers. Universities, district health boards, local councils, and other organisations that process or store government-classified information are also expected to align with NZISM — and public sector procurement requirements increasingly reference it explicitly.
Version 3.8 (released 2022) introduced a dedicated Chapter 23 for public cloud security, covering identity and access management, data protection, and logging obligations specifically for cloud-hosted environments. This chapter acknowledged that traditional on-premises controls need to be re-expressed for shared infrastructure managed by a third party.
NZISM uses the New Zealand Government Security Classification System. Most agency workloads fall into the UNCLASSIFIED or RESTRICTED bands; SECRET and above carry substantially stricter requirements and often cannot be hosted in commercial cloud environments without explicit approval. For most NZ organisations reading this guide, the RESTRICTED-and-below controls represent the day-to-day compliance target.
According to the GCSB’s 2023 cybersecurity survey, approximately 70% of New Zealand government agencies were already using public or hybrid cloud services — yet many were doing so without a formal mapping of their cloud configuration to NZISM controls. That gap is what this checklist aims to close.
The NZISM Compliance Checklist: Identity and Access Management
Access control is the most densely populated area of NZISM cloud requirements, and it is also the most commonly misconfigured. The following checks correspond to NZISM controls in Chapter 16 (Identity and Access Management) and Chapter 23 (Public Cloud Security):
Multi-factor authentication (MFA) MFA is mandatory for all users accessing cloud management consoles and administrative interfaces (Controls 7436, 7437, 6953). Root and superadmin accounts require hardware MFA. Partial MFA deployment — applying it only to some users — is not compliant.
Privileged access restrictions Control 1946 requires that admin-level permissions are not granted broadly: no wildcard admin policies without documented justification, no active root access keys, and privileged accounts distinct from day-to-day accounts. Violations here are common in environments stood up quickly without formal access design.
Unused credential removal Control 1893 requires credentials unused for 30 days to be disabled or removed. Cloud environments accumulate stale service accounts and API keys; an automated weekly or monthly check against unused credential age is the practical way to stay on top of this.
Least privilege across roles Every service account, application identity, and human user should have only the permissions they need. Over-permissioned roles are among the most common NZISM audit findings. A quarterly review of IAM roles and policies, removing unnecessary permissions, keeps this under control.
The NZISM Compliance Checklist: Encryption and Data Protection
NZISM Chapter 17 covers cryptography in significant detail. For cloud environments, the key requirements translate into two distinct obligations: encryption at rest and encryption in transit.
Encryption at rest (Control 2082) All RESTRICTED or above data must be encrypted at rest using AES-256 or equivalent. In cloud environments: enable server-side encryption on all storage — object storage, databases, disk volumes, snapshots, and backups. A common gap is encrypting primary storage but not snapshots or backup copies. Customer-managed keys are preferable for organisations that need control over key lifecycle.
Encryption key rotation (Control 3021) Automated key rotation must be enabled for customer-managed keys. NZISM expects a documented Key Management Plan covering generation, rotation frequency, storage, and revocation. Most cloud platforms support automatic annual rotation — enable it and record the policy.
Encryption in transit (Controls 1847, 2090, 2598, 2600) All data in transit must use TLS 1.2 or higher — TLS 1.0 and 1.1 must be disabled. This applies to user-to-service connections, service-to-service (node-to-node) traffic within the cloud environment, and connections to on-premises systems. Expired certificates in production are a compliance failure; automate certificate renewal and expiry monitoring.
Data sovereignty NZISM does not mandate NZ-only residency for all classifications, but sector guidance from GCSB, Te Whatu Ora, and MBIE consistently points to onshore storage for sensitive government workloads. For RESTRICTED data, offshore storage requires a documented risk assessment. Using a NZ-hosted provider removes that assessment requirement entirely.
The NZISM Compliance Checklist: Logging, Auditing, and Monitoring
Chapter 16 Section 6 of NZISM sets out detailed event logging requirements that many organisations underestimate. Logging is not simply a matter of switching it on — the controls specify what must be logged, how logs must be protected, and how long they must be retained.
Log retention (Controls 1998, 2028) Event logs must be retained for a minimum of 18 months — longer than most cloud platform defaults (often 30–90 days). Review retention across all log sinks: cloud audit logs, load balancer access logs, database query logs, and API gateway logs. Logs must be stored with tamper-evident protection; write logs to a separate storage bucket where the production environment cannot delete them.
What must be logged (Controls 2013, 7496) Required event categories include: authentication attempts (successful and failed), privileged access activity, security configuration changes, data access events, and gateway traffic. In cloud terms: enable full audit logging, access logs on load balancers, CDNs, and API gateways, database query logging, and WAF logs. A common gap is having audit logging on but load balancer access logs switched off.
Log file integrity and monitoring (Controls 2022, 3815, 3875) Log file validation must be enabled so tampering is detectable. Log groups must be encrypted. Intrusion detection services must be active across cloud workloads. Feeding logs into a SIEM or centralised monitoring platform allows cross-service correlation and faster incident detection.
The NZISM Compliance Checklist: Network Security and Gateway Configuration
Network-layer controls in NZISM are primarily addressed in Chapter 18 (Network Security) and Chapter 19 (Gateways). Written before cloud was widespread, they translate directly to cloud network architecture.
No public exposure of databases or sensitive services (Controls 3562, 3623) Databases, search clusters, and any service storing sensitive data must sit in private subnets or VPCs with no public IP addresses. A common misconfiguration is leaving a database port accessible from 0.0.0.0/0 — NZISM compliance requires this is closed.
Web Application Firewall on all public-facing services (Controls 3562, 4333) A WAF is mandatory for internet-facing applications. WAF policies should cover OWASP Top 10 attack patterns and logging must be enabled.
VPC flow logs and port restrictions (Controls 3205) Network flow logs must be enabled and fed into your centralised log store. Security group rules must not allow unrestricted access on unauthorised ports — HTTPS (443) is the standard permitted inbound port for public services. Periodic audits of security group rules catch configuration drift.
The NZISM Compliance Checklist: Backup, Recovery, and System Availability
Automated backups with protection (Control 4849) Backup must be enabled across all production workloads: databases, file systems, volumes, and object storage. Snapshots must be encrypted. Manual backup processes are not sufficient — NZISM expects automated, policy-driven backup schedules.
Availability and immutability (Controls 4829, 4838) Multi-availability zone deployment is expected for RESTRICTED cloud workloads. Controls 4849 and 4838 together create a practical requirement for backup immutability: backup data must be protected from deletion by a compromised account. Object Lock or equivalent on backup storage directly addresses this.
Patching (Controls 3449–3453) Automated patching must be enabled or a documented manual process with defined timelines put in place. Patch compliance must be monitored, and container images scanned for vulnerabilities before deployment.
ASI Solutions provides cloud infrastructure designed to support these requirements, with NZ-hosted infrastructure including Backup as a Service (BUaaS) and Disaster Recovery as a Service (DRaaS) that maintain data onshore and align with NZISM data sovereignty expectations.
Practical Next Steps: Working Through Your NZISM Cloud Review
Getting to grips with NZISM compliance for a cloud environment can feel daunting — the manual runs to hundreds of controls, and mapping every one to your cloud configuration requires methodical effort. Here is a practical approach:
1. Download the NZISM Baseline Security Templates The GCSB publishes baseline security templates at nzism.gcsb.govt.nz for each classification level. Use the RESTRICTED baseline as your benchmark. These templates are regularly updated and represent the minimum acceptable configuration.
2. Map your cloud environment to the control areas above Document your current state against each checklist section. Where you find a gap, record it and assign an owner. A spreadsheet is sufficient to begin — you do not need GRC tooling at this stage.
3. Prioritise identity, encryption, and logging first These three areas generate the most findings and carry the most audit weight. Address MFA, at-rest encryption, and 18-month log retention before tackling network hardening and patching compliance.
4. Automate compliance checking where possible Cloud platforms offer native compliance monitoring tools (AWS Config, Azure Policy, Google Cloud Security Command Center) that continuously check configurations against NZISM-mapped rules — providing ongoing visibility rather than point-in-time audit results.
5. Engage your cloud provider or managed services partner A managed services partner with NZISM experience will have templates, runbooks, and prior mapping work that saves weeks of effort for organisations without dedicated security staff.
The cloud shared responsibility model is central to NZISM cloud compliance: the cloud provider secures the infrastructure, but your organisation is responsible for configuration, identity, data, and applications. Closing the gaps on your side of that boundary is the core of the work.
ASI Solutions has supported NZ public sector and education organisations including local councils and universities for over 40 years. Our NZ-hosted cloud platform — with 1,760+ vCPUs, 7,100+ GiB RAM, and 2,164+ TiB of storage — is operated by a team with deep experience in government and regulated sector requirements. If you are working through an NZISM cloud review, Book a Meeting to discuss how we can help you close compliance gaps and keep your data in New Zealand.
FAQ
What does an NZISM compliance checklist cover for cloud hosting?
An NZISM compliance checklist for cloud environments covers six main areas: identity and access management (MFA, privilege restrictions, unused credentials), cryptography (encryption at rest and in transit, key management), event logging (18-month retention, log integrity, centralised monitoring), network security (no public database exposure, WAF, VPC flow logs), backup and availability (automated backups, multi-zone resilience), and patching. Each area maps to specific NZISM controls across Chapters 16–23.
Which organisations must comply with NZISM?
NZISM is mandatory for New Zealand government agencies and Crown entities, including their significant third-party service providers. Universities, local councils, and district health boards handling government data are expected to align with it, and many procurement frameworks explicitly require it. Private sector organisations on government contracts are increasingly required to demonstrate NZISM alignment as part of supplier assurance.
Does NZISM require data to be stored in New Zealand?
NZISM does not contain an absolute data residency mandate, but it requires that the security risks of offshore storage are formally assessed and accepted. For RESTRICTED data, storing information overseas creates risks around foreign government access and legal jurisdiction that must be documented and signed off. Practical guidance from GCSB consistently points towards NZ-hosted storage for sensitive government workloads — using a NZ-hosted provider removes the need for that assessment entirely.
How long must cloud event logs be retained under NZISM?
NZISM Control 1998 and Control 2028 require event logs to be retained for a minimum of 18 months. This applies to all categories of required logs: cloud audit logs, authentication events, privileged access activity, network flow logs, and access logs on public-facing services. The default retention period in most cloud platforms is significantly shorter (often 30–90 days), so this is one of the most common compliance gaps found during NZISM reviews. Logs must also be stored with tamper-evident protection.
What is the difference between NZISM RESTRICTED and CONFIDENTIAL compliance for cloud?
NZISM RESTRICTED is the baseline for most agency cloud workloads and is achievable on commercial cloud platforms with the right configuration. CONFIDENTIAL imposes stricter controls around access management, infrastructure physical security, and incident response. SECRET and above generally cannot be hosted on commercial public cloud. Most organisations using cloud are targeting RESTRICTED compliance; for CONFIDENTIAL or above, engage GCSB guidance and seek specialist security advice before proceeding.