New Zealand6 min read

External Attack Surface Management in New Zealand: MCSS, NZISM and What Actually Binds You

New Zealand's external attack surface obligations do not come from where most people look. NZISM is the document everyone cites, and it is not the one that creates the requirement.

The Minimum Cyber Security Standards, published by the NCSC on 30 October 2025, are the operative instrument. They apply to GCISO-mandated agencies at a minimum CS-CMM level 2, assured through PSR reporting, and their scope is defined as "all business-critical and externally facing systems".

That scoping phrase is the hook. The standards are deliberately written to cover the internet-facing estate.

MCSS Standard 3 and the maturity ladder

Standard 3 covers assets and their importance, and it escalates in a way worth reading carefully.

  • CMM2 requires a basic inventory.
  • CMM3 requires that all assets have an owner, explicitly "to help manage shadow IT".
  • CMM4 requires a "continuous monitoring regime for tracking and recording any changes in assets".

The focus areas name "external-facing/internet-facing systems" directly, and the suggested inventory fields include IP address and URL. An inventory with IP addresses and URLs, continuously monitored for change, scoped to externally facing systems, is an attack surface inventory by another name.

Patch timeframes

Standard 5 sets a two-tier patch expectation: critical patches within two days on external-facing systems or where working exploits exist, and within two weeks on internal systems.

Two days is not achievable if you find out about your exposure through a quarterly report. It requires knowing, continuously, which of your internet-facing systems are running what.

What NZISM does and does not say

Since NZISM v3.9 (April 2025) is the version people cite, it is worth being precise about what it contains, because two claims circulate that are not accurate.

NZISM does not contain a control requiring periodic vulnerability scanning of internet-facing systems. Control 6.2.5.C.01 is event-triggered and is a SHOULD, not a MUST. NZISM also does not contain a control requiring an inventory of internet-facing services. That obligation comes from PSR INFOSEC 1.1, which requires an inventory of information and ICT systems, and from MCSS Standard 3.

What NZISM does require is relevant in a different way. Control 5.9.24.C.01 is a MUST to publish a vulnerability disclosure programme, and 5.9.23.C.01 is a MUST to risk-assess which public-facing systems are in scope for it. Control 5.9.24.C.02 requires a scoping statement listing the covered systems. To publish that scoping statement honestly, you need to know what your public-facing systems are. It is an inventory obligation arriving through the back door.

Control 19.1.23.C.01 also recommends gateway security testing at random intervals no more than six months apart.

One further correction: NZISM is not law. Section 1.2.6 states plainly that "compliance with the NZISM is not required as a matter of law". It binds through agency policy and contract, not statute.

Who this reaches

Directly, GCISO-mandated agencies. Indirectly, and this is the larger population, every vendor selling into them. NZISM is explicitly written to cover vendors, contractors and consultants serving agencies, and supplier assurance is how these standards travel.

If you are a New Zealand company that sells to government, your customer's MCSS Standard 3 obligation becomes your evidence obligation. Being able to produce a current, monitored inventory of your internet-facing assets is increasingly the difference between passing an assurance review and spending three weeks answering follow-up questions.

EASMLens builds that inventory from external observation rather than from what you remembered to write down, and monitors it for change continuously, which is the CMM4 expectation.

Other regions