NZISM 3.6 compliance gap analysis: where NZ government security controls actually fail
Amara OkaforApril 29, 2026
Key takeaways
NZISM 3.6 classifies controls by system impact level — Low, Medium, High — and the required controls at High impact are not a superset of Medium. They are a different set. Organizations that implement Medium-impact controls and assume they satisfy High-impact requirements will fail at least 11 control families where the requirements diverge.
The most consistently failed NZISM 3.6 control in Vulnox assessments of NZ government-aligned environments was configuration baseline management: organizations had approved configurations documented but no mechanism to detect or alert on drift from those baselines in production systems.
NZISM 3.6 requires security assessment of systems before they go live and after significant changes. In assessed environments, 'significant change' had no defined threshold. System changes that introduced new network paths, new authentication mechanisms, or new data flows were not triggering reassessment because no one had defined when reassessment was required.
Patch management under NZISM 3.6 has explicit timeframes: critical patches within 48 hours for High-impact systems, within 1 month for Medium. In assessed environments, no organization had a technical mechanism that differentiated patch urgency by system classification. The same monthly patch cycle was applied to air-gapped low-sensitivity systems and internet-facing High-impact ones.
Supply chain controls in NZISM 3.6 extend to cloud service providers. Government agencies using hyperscale cloud services frequently have not conducted the NZISM-required security assessment of the cloud service itself, treating vendor compliance certifications as a substitute for the agency-level assessment the manual requires.
TL;DR
NZISM 3.6 is more technically specific than most frameworks its size, and that specificity is where most compliance programs break. The failures are not in governance documentation — they are in configuration drift detection, patch tiering by classification level, and the gap between what change management approves and what security assessment actually reviews. A gap analysis that checks policies against the manual will score organizations higher than they deserve.
The configuration that passed change management and failed the assessment
A New Zealand government-adjacent organization running a High-impact classified system completed its annual NZISM compliance review with a satisfactory result. Four months later, a Vulnox assessment found that a network path had been opened between the High-impact system and a development environment during a routine infrastructure change. The change had been through the change management process. The change management process did not include a security assessment step. NZISM 3.6 requires security assessment after significant changes. The organization's change management policy did not define what constituted a significant change. The network path had been open for four months. No one had looked at what was traversing it.
The compliance review had checked whether a change management process existed and whether changes were logged. It had not checked whether the change management process triggered security reassessment for the class of changes that NZISM 3.6 requires it to cover. The policy satisfied the checklist. The control did not function.
How NZISM 3.6 control requirements actually work by classification level
NZISM 3.6 organizes controls into families: gateway security, access control, cryptography, malware protection, network management, patch management, software security, system monitoring, and others. Each control has a requirement that varies by the impact level of the system it applies to — Low, Medium, or High. The manual uses the terms SHOULD (recommended) and MUST (mandatory) to differentiate obligatory from advisory controls at each level.
The error organizations make is treating the classification tiers as additive. They are not. A High-impact system does not simply need everything a Medium-impact system needs plus more. Several controls change their character entirely at different classification levels. Cryptographic requirements at High impact specify algorithm and key length requirements that have no equivalent at Medium. Network segmentation requirements at High impact require documented and tested isolation that Medium does not mandate. Treating the tiers as a simple escalation produces a compliance assessment that misses the controls where the requirement diverges, not just intensifies.
The manual also distinguishes between controls that apply to the system and controls that apply to the agency. Agency-level controls cover governance, personnel security, physical security, and supply chain. System-level controls cover configuration, patching, access, and monitoring. A gap analysis that focuses on system-level controls — the technically visible ones — and treats agency-level controls as documented policy review will miss the operational failures in the governance layer. Both need hands-on validation.
The current version is 3.7 as of late 2023. Organizations still referencing 3.6 as their compliance baseline need to review the delta. The changes between 3.6 and 3.7 are not cosmetic — cloud security controls were substantially revised, and organizations using hyperscale cloud services under a 3.6 assessment have a gap that a 3.7 review will surface.
Example
In a Vulnox assessment of a NZ Crown entity, the patch management control was assessed against a single monthly patch cycle applied across all systems. NZISM 3.6 requires critical patches on High-impact systems within 48 hours. The organization had 6 systems classified at High impact. All 6 were on the monthly cycle. The gap between the required 48-hour window and the actual 30-day cycle had not been flagged in two prior internal compliance reviews because the reviews had checked whether a patch management process existed, not whether the process differentiated by classification level.
NZISM 3.6 and 3.7 are published by the Government Communications Security Bureau (GCSB). The full manual including control-by-control MUST/SHOULD breakdowns by classification level is publicly available. Reading the actual control text is faster than reading secondary summaries of it.
What NZISM assessments actually find
Assessment base: Vulnox NZISM gap assessment data, New Zealand government-aligned engagements, 2024.
Configuration baseline drift with no detection mechanism
Every assessed organization had approved configuration baselines for their major system types — server builds, network device configurations, endpoint builds. In the majority of assessed environments, there was no automated mechanism to compare running configurations against the approved baseline and alert on divergence. Configuration drift was discovered during assessments through manual comparison: running 'show running-config' against approved baseline documents, comparing installed software against approved build lists, reviewing firewall rules against the approved rule set. Drift ranged from minor additions to substantive rule changes that had been made informally and never documented. (Vulnox assessment data, 2024)
NZISM 3.6 requires that configurations are maintained in accordance with approved baselines. A baseline document that no one is comparing against running systems is an audit artifact, not a security control. The drift accumulates over months. By the time an assessment runs, the gap between what the baseline says and what is running can be substantial. In two assessed environments, firewall rules granting access to production systems from development networks had been in place for over 8 months without detection.
Change management processes that bypass security assessment
NZISM 3.6 requires security assessment of systems before go-live and after significant changes. In every assessed environment, the change management process had an approval workflow. In the majority of cases, the approval workflow did not include a security assessment step for infrastructure and network changes — only for application deployments. Network path changes, firewall rule additions, and authentication configuration changes were going through change management without triggering security review. The definition of 'significant change' was absent from change management policy in most assessed organizations. (Vulnox assessment data, 2024)
Network path changes are the class of infrastructure modification most likely to introduce new attack surface. They are also the class most commonly handled outside the security assessment loop because they are perceived as operational, not security-relevant. An opened network path between a High-impact system and a lower-classified environment represents an NZISM control failure even if the change was operationally justified and properly change-managed.
Patch tiering not implemented by classification level
NZISM 3.6 requires critical patches on High-impact systems within 48 hours and on Medium-impact systems within 1 month. In every assessed NZ government-aligned environment, patch management operated on a single cycle — typically monthly, occasionally fortnightly — applied uniformly across system classifications. No organization had implemented a mechanism to identify High-impact systems as requiring the 48-hour patch cycle for critical vulnerabilities. The result was that internet-facing High-impact systems received the same patch cadence as isolated Low-impact systems. (Vulnox assessment data, 2024)
A critical CVE affecting a High-impact system on a monthly patch cycle is unpatched for up to 29 days beyond the NZISM-required window. CVSS 9+ vulnerabilities with public exploit code exist for most major platforms. The 48-hour requirement for High-impact systems is not arbitrary — it reflects the exploitation timeline for critical vulnerabilities in targeted environments. An organization that cannot identify its High-impact systems for emergency patching does not have a patch management program that satisfies NZISM 3.6.
Cloud service provider assessments not conducted
NZISM 3.6 requires that agencies assess the security of cloud services they use, in addition to reviewing vendor compliance certifications. Several assessed government-adjacent organizations using AWS, Microsoft Azure, and Google Cloud had conducted no agency-level NZISM security assessment of the cloud service. They held vendor compliance documentation — SOC 2 reports, ISO 27001 certificates, FedRAMP authorizations. They had not conducted the assessment the manual requires: evaluating whether the cloud service's security controls meet NZISM requirements for the classification level of data being processed. The vendor certifications were treated as a complete substitute for the agency assessment. (Vulnox assessment data, 2024)
A SOC 2 Type II report documents a vendor's internal controls against a specific framework at a point in time. It does not assess whether those controls satisfy NZISM requirements for High-impact NZ government data. The gap is not about whether the cloud provider is secure in general — AWS and Azure have substantial security programs. It is about whether the specific configuration of the agency's cloud environment, and the shared responsibility boundary, satisfies NZISM 3.6 requirements. That is an agency-level question, not a vendor-level one.
The organizations with the most detailed NZISM documentation have the hardest time demonstrating operational compliance
Common belief
Detailed security documentation — comprehensive policies, extensive control registers, thorough risk registers — indicates a mature NZISM compliance posture. More documentation means fewer gaps.
What we found
In Vulnox assessments of NZISM-aligned environments, the correlation between documentation volume and operational control effectiveness was negative for organizations above a certain governance maturity threshold. Organizations with extensive compliance documentation had more documentation findings resolved and more operational findings open at the end of assessments than organizations with leaner documentation and more technically engaged security teams. (Vulnox assessment data, 2024)
The relationship inverts under technical scrutiny. Organizations that have invested heavily in documentation tend to have compliance programs that optimize for document production. The governance layer looks strong. The operational controls layer is where the failures accumulate, because the energy went into policies that describe what should happen, not mechanisms that enforce it.
The specific pattern: a detailed patch management policy that describes the 48-hour critical patch requirement for High-impact systems, written by someone who read the NZISM manual carefully. And a patch management tool configured to run on a monthly cycle that has never been updated to reflect the tiered requirement. The policy says one thing. The tool does another. The compliance review checks the policy.
Organizations with less formal documentation but technically competent infrastructure teams sometimes have better operational control alignment. Their patch cycles were set by engineers who thought about what made sense for each system. Their firewall rule sets have been reviewed recently because someone actually uses them. Their configuration baselines are shorter but current.
This is not an argument against documentation. It is a description of what happens when documentation becomes the output of a compliance program rather than the evidence of operational controls that are actually running.
What standard NZISM gap analyses miss
The 3.6 to 3.7 delta
NZISM 3.7 was released in late 2023. The cloud security section was substantially revised, with new controls addressing shared responsibility models, cloud-native service configurations, and identity federation. Organizations that completed a 3.6 gap analysis and have not reviewed the 3.7 changes are missing a set of cloud-specific controls that did not exist in the version they assessed against. The gap is largest for organizations that moved workloads to hyperscale cloud after their last NZISM review.
Privileged access management at the technical level
NZISM 3.6 requires that privileged access is controlled, logged, and reviewed. Most gap analyses check for a privileged access management policy and a log review process. The technical controls underneath — whether privileged sessions are actually proxied through a PAM solution, whether just-in-time access is enforced, whether standing administrative access exists to High-impact systems outside a PAM boundary — require hands-on enumeration. In assessed environments, standing local administrator accounts on High-impact servers were the norm, not the exception, regardless of what the PAM policy described.
System monitoring log coverage
NZISM 3.6 requires monitoring of systems for security-relevant events. Gap analyses typically check whether a SIEM or log aggregation platform exists. The question that determines whether the control works is which systems are sending logs, whether those logs contain the events the manual requires, and whether anyone reviews alerts. In assessed environments, log coverage was typically 60-70% of in-scope systems by volume. The systems not sending logs were frequently the highest-risk ones: legacy servers running outdated OS versions that did not support the log shipping agent, network devices that required manual configuration not completed during SIEM deployment.
Physical security controls for High-impact systems
NZISM 3.6 has specific physical security requirements for High-impact systems: dedicated secure areas, visitor access logging, media handling procedures. Technical gap analyses typically skip physical security because it requires on-site inspection. Remote assessments working from documentation cannot verify whether a server room has the access logging and escorted visitor policy that the NZISM requires for High-impact environments. The physical controls are also the ones most likely to have degraded since the last on-site review.
Where NZISM compliance pressure is heading
GCSB will introduce mandatory third-party assessment requirements for High-impact systems in Crown entities within 24 months, replacing self-assessment as the primary compliance verification mechanism for the highest classification tier.
The pattern of self-assessed NZISM compliance not reflecting operational control effectiveness is visible to GCSB through incident investigations and the audit findings of the Office of the Auditor-General. The self-assessment model works for Low and Medium classification levels where the consequences of control failure are bounded. For High-impact systems, the divergence between documented compliance and operational reality has been noted in multiple OAG reports on government IT security. Mandatory third-party assessment for the highest tier is the logical regulatory response, and it matches the direction taken by comparable frameworks internationally.
Confidence: mediumNo mandatory third-party assessment requirement for High-impact systems introduced by GCSB by end of 2027 would falsify this prediction.Within 18 months, a NZ Crown entity will experience a publicly disclosed breach traceable to a misconfigured cloud environment where the agency had current NZISM compliance documentation but had not conducted the NZISM-required agency-level assessment of their cloud configuration.
The structural conditions are present across multiple assessed environments: High-impact data in cloud environments, no agency-level NZISM cloud assessment conducted, vendor compliance certifications used as a substitute. Cloud misconfigurations resulting in data exposure are the most common initial access vector in government-sector breaches globally. NZ government cloud adoption has accelerated. The NZISM cloud assessment requirement is consistently not met. These factors together make this a question of when, not whether.
Confidence: highNo publicly disclosed Crown entity breach with a cloud misconfiguration root cause by end of 2026 would reduce confidence in this prediction.
The NZISM's MUST/SHOULD distinction is being applied backwards in most self-assessments
NZISM 3.6 uses MUST for mandatory controls and SHOULD for recommended ones. In theory this creates a clear compliance floor: MUST controls are non-negotiable, SHOULD controls are good practice. In practice, self-assessments treat SHOULD controls as aspirational and MUST controls as the complete compliance requirement.
The problem is that several MUST controls are technically shallow. 'Organizations MUST have a patch management policy' is a MUST control. 'Organizations SHOULD implement automated configuration drift detection' is a SHOULD control. The compliance program produces a patch management policy — MUST satisfied. It does not implement configuration drift detection — SHOULD noted as aspirational.
The result is that the compliance program reliably produces the documentation the MUST controls require and reliably defers the operational controls that only appear at SHOULD level. But from a technical standpoint, the SHOULD controls often have more security value than the MUST controls they accompany. An organization with no patch management policy and automated patch deployment is more secure than one with a detailed patch management policy and no deployment mechanism.
The MUST/SHOULD distinction was designed to create a compliance floor, not a ceiling. Organizations that treat SHOULD as optional are misreading the manual's intent and producing compliance programs that optimize for the floor.
Counterargument
The counterargument is that SHOULD controls are genuinely optional — that is what the word means in the RFC sense NZISM borrows from, and requiring organizations to implement SHOULD controls would remove the flexibility the manual intentionally provides. This is technically correct. The issue is not the definition of SHOULD — it is the selection of which controls ended up at each level. If the SHOULD controls with the highest operational security value had been designated MUST, the compliance floor would be higher. That is a criticism of the manual's control classification decisions, not the MUST/SHOULD mechanism itself.
One thing to do this week
Pick one High-impact classified system. Pull the last 30 days of patch records for that system. Find every CVE with a CVSS score above 9 affecting software on that system in the last 30 days. Check when the patch was applied against the date the CVE was published. If any critical vulnerability was unpatched for more than 48 hours, your patch management control is not meeting the NZISM 3.6 requirement for High-impact systems — regardless of what your policy says. That is a one-hour check. It tells you more about your actual NZISM compliance posture than a full policy review does.
Further Reading
Gap Analysis
gap analysis frameworkDigital Footprint
digital footprint analysisAPAC cybersecurity and privacy compliance frameworks: the complete guide
NZISM 3.6 compliance gap analysis and where government security controls fail in practiceNIST SP 800-30 Risk Assessment Guide
NIST Risk Assessment GuideNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionThird-Party Risk Management
third-party risk management
Frequently Asked Questions
What are the patch management timeframes required under NZISM 3.6?
NZISM 3.6 requires critical patches on High-impact classified systems within 48 hours of availability. Medium-impact systems must be patched within 1 month. In Vulnox assessments, no NZ government-aligned organization had implemented a patch management mechanism that differentiated by classification level — a single monthly cycle was applied to all systems regardless of their NZISM impact classification.
What is the difference between NZISM 3.6 and NZISM 3.7?
NZISM 3.7, released in late 2023, substantially revised the cloud security controls section. New controls address shared responsibility models, cloud-native service configurations, and identity federation that were not present in 3.6. Organizations that completed a 3.6 gap analysis and moved workloads to cloud after that assessment have a gap specifically in cloud security controls that the 3.6 baseline did not cover.
What does NZISM 3.6 require for cloud service provider assessments?
NZISM 3.6 requires agencies to conduct their own security assessment of cloud services used to process classified data, not just review vendor compliance certifications. A SOC 2 report or ISO 27001 certificate does not substitute for this agency-level assessment. The assessment must evaluate whether the specific cloud configuration and shared responsibility boundary satisfies NZISM requirements for the classification level of data being processed.
How does NZISM 3.6 classify control requirements by impact level?
NZISM 3.6 assigns controls to Low, Medium, and High impact levels using MUST (mandatory) and SHOULD (recommended) designations. The classification levels are not additive — several controls change their character entirely at High impact, not just intensity. Cryptographic requirements, network segmentation standards, and patch timelines differ substantively between Medium and High, not just in degree.
What is the most common NZISM 3.6 gap finding in NZ government environments?
Configuration baseline drift with no detection mechanism. In Vulnox assessments, every assessed organization had approved configuration baselines documented. None had an automated process to compare running configurations against those baselines and alert on divergence. Firewall rule additions, network path changes, and software installations were accumulating outside the approved baseline without detection. In two assessed environments, network paths from development environments to High-impact production systems had been open for over 8 months.
What does NZISM 3.6 require for security assessment of system changes?
NZISM 3.6 requires security assessment before system go-live and after significant changes. The failure point is that 'significant change' is not defined by the manual — organizations must define it themselves. In assessed environments, the definition was absent from change management policy, and network path changes, authentication configuration changes, and firewall rule additions were not triggering security reassessment even when they introduced new attack surface on High-impact systems.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.