New Zealand software and AI security rules: a 90-day plan for 2026

New Zealand has no single software supply chain law. Organisations that build, buy or run software there answer to a set of overlapping regimes instead: the New Zealand Information Security Manual (NZISM), the Protective Security Requirements (PSR) and the NCSC's Minimum Cyber Security Standards for government and its suppliers, the Privacy Act 2020 for anyone holding personal information, and the Reserve Bank's cyber incident reporting for regulated financial entities. Each one ends up asking the same questions: what software do you run, who supplied it, how fast do you patch it, and how quickly can you tell a regulator what happened.

This guide covers each regime as it stands in late October 2026, quotes the control and section numbers from the primary sources, maps the requirements to the evidence a reviewer asks for, and ends with a 30/60/90-day plan that works with the tools you already have. Safeguard appears only near the end. Nothing here is legal advice; where a rule is interpreted, check the primary text linked in Sources or ask your counsel.

Key takeaways

• The NZISM sets a two-day target for critical patches. Control 12.4.4.C.01 says agencies should apply critical security patches as soon as possible and preferably within two days of release, and 12.4.4.C.02 says they must have a patch management strategy. Version 3.9 is the current release.
• The NCSC's Minimum Cyber Security Standards turn that into a mandate. Published on 30 October 2025 under the Government Chief Information Security Officer (GCISO) mandate, the ten standards are required for GCISO-mandated agencies and cover business-critical and externally facing systems. The Patching standard expects an up-to-date asset inventory and a minimum maturity of CS-CMM 2.
• The PSR is the governance layer. Since 2014, Cabinet has directed public service departments and several other agencies to implement it, and they self-assess each year against 20 mandatory requirements.
• The Privacy Act 2020 has a fast breach clock in practice. Section 114 requires notice to the Privacy Commissioner as soon as practicable, and the Commissioner's guideline is within 72 hours of becoming aware of a notifiable breach. IPP 12 governs disclosure overseas, and IPP 3A has applied since 1 May 2026.
• Regulated financial entities report material cyber incidents to the RBNZ within 72 hours. The Reserve Bank also collects periodic reports of all cyber incidents and self-assessments against its Guidance on Cyber Resilience.
• AI is governed through existing law and public sector guidance, not an AI statute. The National AI Strategy launched in July 2025, and the non-binding Public Service AI Framework guides agencies.
• Safeguard capabilities used in this guide, all GA: SBOM generation and analysis, software composition analysis with deep transitive scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the Compliance and GRC suite with an NZISM framework page, TPRM SBOM requests, Portal and Trust Center sharing, AI-BOM discovery, autonomous remediation (ships switched off), the CLI and local runner, Zero AI mode, and private VPC, on-prem and air-gapped deployment.

The situation

The trigger is rarely a new law. It is a government agency's security questionnaire that asks you to map your controls to the NZISM, a request to show your patching maturity against the NCSC's minimum standards, a Reserve Bank survey on cyber resilience, a renewal where the customer now wants an SBOM, or a vulnerability in a widely used language runtime and a chief executive asking the next morning whether you are exposed.

That last one is not hypothetical: on 22 October 2026 the NCSC urged organisations to patch two critical PHP vulnerabilities immediately. A bad week looks like this: your privacy officer needs to decide whether a breach is notifiable, your financial regulator expects a material incident report within 72 hours, the NZISM's two-day patch target has started, nobody can say which products ship the affected version, and the supplier who might know is in a different time zone.

Who this applies to in New Zealand

New Zealand regulates by sector and by role. The table shows who sits in scope and which body owns each regime.

Two points matter for scoping. First, the NZISM, the PSR and the minimum standards bind the agencies that are mandated to follow them. They reach private companies through procurement: if an agency writes "comply with the NZISM" into your contract, it becomes your obligation, and a mandated agency that must meet the Patching standard will expect its software suppliers to support it. Second, the Privacy Act applies to almost everyone. An agency under the Act includes businesses of every size, not just government.

The rules, regulator by regulator

Each regime below was checked on its primary source on 25 and 26 October 2026.

NZISM: New Zealand Information Security Manual (GCSB and NCSC)

The NZISM is the Government's manual for information assurance and information systems security. The GCSB publishes it and its National Cyber Security Centre maintains it. Its controls are written with two levels of force: MUST for mandatory controls and SHOULD for recommended ones.

The current version. Version 3.9 is the current release. The NCSC's release notice says its largest change was to chapter 16, renamed Authentication and Access Controls, which updated password controls and introduced passwordless authentication and phishing-resistant multi-factor authentication. Chapter 7 was updated to improve guidance on detecting and managing security incidents and to set clearer expectations for GCISO-mandated agencies to report incidents. Section 18.2 added WPA3, and section 11.8 added a control on central logging of multifunction devices.

Patching controls. Section 12.4, Product Patching and Updating, is the part software teams meet first. The NCSC lists these controls as applicable to its Patching standard:

• 12.4.3.C.01 (SHOULD). Monitor relevant sources for information about new vulnerabilities and security patches for the software and IT equipment the agency uses.
• 12.4.4.C.02 (MUST). Implement a patch management strategy, including an evaluation or testing process.
• 12.4.4.C.01 (SHOULD). Apply all critical security patches as soon as possible, and preferably within two days of the release of the patch or update.
• 12.4.4.C.05 (SHOULD). Apply all non-critical security patches as soon as possible.
• 12.4.4.C.06 (SHOULD). Apply security patches through a vendor-recommended patch or upgrade process.
• 13.1.9.C.01 (SHOULD). Have policy and procedures for secure decommissioning when a system reaches the end of its service life.

The two-day clock runs from the release of the patch, not from when your team noticed, and "monitor relevant sources" only works if you know which software and versions you run.

NCSC Minimum Cyber Security Standards (GCISO mandate)

The NCSC developed the Minimum Cyber Security Standards as part of its GCISO mandate, and published them on 30 October 2025. They are intended for GCISO-mandated agencies, which are required to implement them; other agencies may adopt them. The NCSC says they align with the PSR Assurance Framework, which is the mechanism it uses to assess agency compliance, and that they map to its Cyber Security Framework and to NZISM technical controls.

There are ten standards: Risk Management, Security Awareness, Assets and their Importance, Secure Configuration of Software, Patching, Multi-factor Authentication, Detect Unusual Behaviour, Least Privilege, Data Recovery and Response Planning. They apply to all business-critical and externally facing systems, where applicable. Each standard carries a maturity model, the Cyber Security Capability Maturity Model (CS-CMM), with an expected minimum level.

The Patching standard is the one closest to software supply chain work. Its minimum level is CS-CMM 2. Among its suggested actions:

• a patch management policy with responsibilities, severity thresholds and alternative mitigations for vulnerabilities that stay unpatched;
• a current asset inventory, with patch versions registered and linked to the asset register;
• applying critical-rated security patches within two days (working days or not) of release on external-facing systems or where working exploits exist, and within two weeks on internal systems;
• taking patches and upgrades only from reliable sources;
• planning and funding the retirement of systems and software that will lose vendor support, well before the end-of-support date.

The standard names third-party vendors who are responsible for an organisation's patching as a focus area, and lists an up-to-date asset inventory as a key dependency. If you run systems for a mandated agency, you are inside that focus area.

Protective Security Requirements (PSR)

The PSR is the Government's best practice security policy framework for security governance and for personnel, information and physical security. In 2014, Cabinet directed all public service departments, the New Zealand Defence Force, New Zealand Police, the New Zealand Security Intelligence Service and the Parliamentary Counsel Office to implement it.

Those departments must provide assurance information on request to the lead security agencies (the GCSB, the NZSIS and the Department of the Prime Minister and Cabinet). Each year they produce a report to their chief executive with a self-assessment, supported by evidence of policy and practice, against the PSR's 20 mandatory requirements. For a supplier, the PSR usually shows up as contract clauses, security questionnaires and requests to support the agency's assurance work.

Privacy Act 2020 (Office of the Privacy Commissioner)

The Privacy Act 2020 is the one regime in this guide that applies to almost every organisation in New Zealand.

Security of personal information. Information privacy principle 5 requires that personal information is protected by such security safeguards as are reasonable in the circumstances against loss, unauthorised access, use, modification or disclosure, and other misuse. The NCSC's supplier guidance cites this duty directly.

Notifiable privacy breaches. If your organisation has a privacy breach that has caused, or is likely to cause, serious harm, you must notify the Privacy Commissioner, and affected people. Section 114 requires notice as soon as practicable after becoming aware that a notifiable privacy breach has occurred. In its guidance titled "How long is 72 hours?" (16 May 2024), the Office of the Privacy Commissioner says its expectation is notice within 72 hours of becoming aware that a breach is notifiable, and calls that timeframe a guide intended to prompt early notification. It also notes that section 117(5) allows notification to be made incrementally as information comes to light. Failing to notify the Commissioner is an offence under section 118.

Cross-border disclosure. IPP 12 allows disclosure of personal information to a foreign person or entity only on listed grounds: for example, the recipient carries on business in New Zealand and is subject to the Act, is subject to privacy laws that overall provide comparable safeguards, or is required by agreement to protect the information comparably. Otherwise the individual must authorise it after being expressly told the information may not get the same protection. This is the legal backdrop to most "where is our data processed" questions in New Zealand procurement.

IPP 3A, indirect collection. The Privacy Amendment Act 2025 introduced IPP 3A, in force from 1 May 2026. When an agency collects personal information from someone other than the individual, it must take reasonable steps to make sure the individual knows it was collected, why, who will receive it, who holds it, and their rights of access and correction, subject to exceptions.

Biometric Processing Privacy Code 2025. Issued on 21 July 2025, the Code sets the rules for using technologies such as facial recognition to process biometric information. It came into force on 3 November 2025, and agencies already using biometrics had a transition period that ended on 3 August 2026. Amendment No 1, issued in March 2026, reflects IPP 3A.

Reserve Bank of New Zealand: cyber resilience reporting

The RBNZ supervises registered banks, non-bank deposit takers and insurers. In March 2024 it announced, after consultation, that it would implement formal cyber resilience reporting in phases through 2024. The Bank's announcement (read in a verbatim republication, because the RBNZ site blocked our fetcher) sets out three requirements:

• Material cyber incident reporting. Entities report material cyber incidents to the RBNZ as soon as practicable, but within 72 hours.
• Periodic reporting of all cyber incidents. Entities tell the Bank about all cyber incidents regardless of materiality: large entities every six months and other entities annually.
• Cyber resilience surveys. Entities self-assess against the RBNZ's Guidance on Cyber Resilience: large entities every year and other entities every two years.

The Bank also said it was working with the Financial Markets Authority on reporting for entities regulated by both. For a vendor selling to a bank or insurer, this lands as incident notification clauses that leave the customer room inside its own 72 hours.

NCSC guidance and incident reporting

The NCSC takes cyber security incident reports from individuals, businesses and government, and publishes alerts and guidance. Recent guidance matters directly to software suppliers:

• Third-party supplier guidance (4 August 2026). After several incidents involving third-party suppliers earlier in 2026, the NCSC released guidance for organisations that use third parties to collect and store information, including questions to ask suppliers. It frames supplier management as an ongoing process that starts before you sign.
• Frontier AI and vulnerabilities (23 June 2026). The NCSC joined its Five Eyes partners in a call to action on frontier AI, warning that AI shrinks the window between vulnerability discovery and exploitation and that organisations should prepare for a significant increase in vulnerabilities. The call asks leaders to understand risk and accountability, prioritise foundational practices, empower cyber leaders and stay engaged.

AI rules

New Zealand does not have an AI-specific statute. Cabinet agreed in June 2024 to promote the OECD AI principles as the key direction for responsible AI, and the National AI Strategy was launched in July 2025.

For the public sector, the Government Chief Digital Officer publishes the Public Service AI Framework, which sits within the National AI Strategy. Its five principles are inclusive, sustainable development; human-centred values; transparency and explainability; safety and security; and accountability. It is not binding, but agencies are encouraged to align with it, and it asks agencies to ensure traceability of data and to work with security colleagues when procuring AI tools.

The binding rules for AI that handles personal information are the Privacy Act's: IPP 5 security, IPP 12 cross-border disclosure, IPP 3A for information gathered from other sources, and the Biometric Processing Privacy Code where faces, voices or other biometrics are processed. In practice, AI governance starts with an inventory of the models, services and agents in use and the data they touch.

What the rules ask of software and open source

The regimes overlap, so map each requirement to the evidence a reviewer asks for once and reuse it.

A note on SBOMs: no New Zealand law or NZISM control quoted above uses the word in a binding requirement today. Still, the minimum standards ask for an asset inventory with patch versions linked to it, the NZISM asks you to monitor and patch the software you use, and the Privacy Act asks for reasonable safeguards. An SBOM is the cheapest way to prove all three.

Real public incidents in or affecting New Zealand

These come from the NCSC's own publications. Nothing here comments on what any organisation should have done beyond what the sources say.

• Critical PHP vulnerabilities (22 October 2026). The NCSC said two critical PHP vulnerabilities could let an attacker take full control of a website, web server or web service, and recommended patching immediately or, failing that, considering disabling public-facing web services. It noted the patch protects only actively supported versions and that end-of-life versions stay vulnerable unless teams compile patches or receive backports. It told organisations to check with third-party suppliers whether they use PHP. Our related posts cover what PHP2Shell is and how to find and patch every PHP runtime.
• Canvas data breach (8 May 2026). The NCSC said some New Zealand universities and other tertiary and education institutions were affected by a data breach of the Canvas learning management system, and that it was engaging with the Ministry of Education and the institutions. A breach at a widely used SaaS platform becomes many organisations' privacy question at once.
• Highly significant incidents in early 2026 (report of 22 June 2026). The NCSC's insights report for January to March 2026 recorded three C2, or highly significant, incidents, the first since the 2021/22 financial year, and said basic measures such as multi-factor authentication, managing who has full network access and protecting network edges could have helped defend against them. It handled 1,164 incidents in the quarter.
• Cyber Threat Report 2026 (24 September 2026). The NCSC reported 369 incidents of potential national significance in 2025/26, of which 162 were linked to criminal or financially motivated actors, an 18 percent rise. It recorded four C2 incidents in the year, as many as in the previous ten years combined, and described a North Korean IT worker obtaining remote IT work with a New Zealand business.

The personas who own the problem

CISO

The CISO answers to the chief executive, the board and, in regulated finance, the RBNZ. They need a defensible view of cyber risk from third parties and open source, and a fast route to the 72-hour reporting decision. Their triggers are an RBNZ survey, a board risk report, the NCSC's Cyber Threat Report landing on the chair's desk, and any incident with privacy impact.

Head of AppSec or product security

This person owns the backlog. They need to know which vulnerabilities are actually reachable and which products ship them, so their team spends its first two days on the right fixes. Their trigger is usually a customer questionnaire that asks for NZISM patching evidence, or an NCSC alert like the PHP one.

VP or Director of Engineering or Platform

They care about release speed and engineering time. They need one process that produces SBOMs, scans and gates in CI without slowing every pull request, and that satisfies both government and private customers. Their trigger is a government contract that references the NZISM or the minimum standards, or an end-of-support date that the Patching standard says should have been planned for.

GRC, compliance and regulatory affairs

They own the mapping from rules to evidence. They need a control set that lines up with the NZISM, the minimum standards and the PSR's mandatory requirements, plus the Privacy Act's breach and cross-border rules, with evidence that stays current without a scramble before the annual PSR self-assessment or the RBNZ survey.

Procurement and vendor risk

They need to know which suppliers matter, what to ask them, and how to keep that current. They request supplier SBOMs and write the incident notification clauses. Their trigger is a contract renewal, the NCSC's supplier guidance, or a supplier breach like the Canvas incident.

Privacy officer

The Privacy Act requires every organisation to have at least one person who fulfils the privacy officer role. They decide whether a breach is notifiable, and they need to know fast what personal information sits in the affected system. Their trigger is any incident involving personal information, and the 72-hour guideline starts when the organisation becomes aware.

Step by step: a 30/60/90-day plan

The plan works with or without Safeguard. Use whatever tools you have.

Days 1 to 30: know what you have and which clocks apply

1. List the regimes that bind you. Use the scope table above. Label each "by law" (Privacy Act, RBNZ reporting if you are regulated) or "by contract" (NZISM, PSR, minimum standards).
2. Write down your clocks. NZISM 12.4.4.C.01 two-day patch target, the Patching standard's two days external and two weeks internal, RBNZ material incident reporting within 72 hours, the Privacy Commissioner's 72-hour guideline, and any contractual notification windows. Name a decision-maker and a backup for each.
3. Build the asset inventory. For each system and product, record the owner, where it runs, whether it is business-critical or externally facing, what data it holds and whether personal information is involved.
4. Generate an SBOM for every product you build. Use SPDX or CycloneDX, and make it part of the build so it stays current. Link the component versions to the asset inventory, as the Patching standard suggests.
5. List your suppliers. Start with the ones that host your data, run your infrastructure, patch your systems or ship code into your products.

Checklist for day 30:

Days 31 to 60: connect inventory to risk

6. Match components to vulnerabilities. Scan SBOMs against vulnerability data and enrich with EPSS and CISA KEV so the "critical or working exploit" cases are obvious, because those are the ones on the two-day clock.
7. Write the patch policy. Set timeframes by severity and exposure, measured from the release of the patch. Include alternative mitigations for anything you cannot patch in time, and a test or pilot step, as NZISM 12.4.4.C.02 asks.
8. Add a gate in CI. Block or warn on releases that break your policy (for example a known exploited vulnerability with a fix available), with an exception process that records who approved it, why and until when.
9. Ask your top suppliers for SBOMs and incident terms. Use the questions in the NCSC's supplier guidance and include notification timeframes that leave you room inside your own 72 hours.
10. Run a tabletop exercise. Use the October 2026 PHP alert or another public vulnerability in a common runtime. Time how long it takes to answer "which products and systems are affected", "are any end-of-life versions involved" and "is any personal information at risk".

Days 61 to 90: evidence and governance

11. Map controls. Map your controls to the NZISM sections, the minimum standards and the PSR requirements that apply to you. Record which evidence proves each one.
12. Build the end-of-support register. List components and runtimes approaching end of support, with upgrade plans, so you are not relying on backports during the next alert.
13. Write the AI inventory. List the AI models, services, SDKs and agents in use, what data they touch, whether biometrics are involved and who approved them.
14. Document cross-border data flows. For each system, record where data and code are processed and the IPP 12 basis for any overseas recipient.
15. Package the evidence and report. Build a pack you can hand to an agency, the RBNZ or an auditor: SBOMs, scan results, gate history, exceptions, supplier records and incident decision logs. Show the board the clocks, the tabletop timings, open exceptions and supplier coverage.

Decision table for the first hours of an incident:

How Safeguard does this

Everything below is GA and comes from Safeguard's offering documentation and docs.safeguard.sh. Safeguard holds no New Zealand certification or assessment and is not on any government panel or catalog; it helps a team produce and keep the evidence these regimes ask for.

1. Use the NZISM framework page. Safeguard's Compliance and GRC suite (GA) includes a New Zealand NZISM framework page. The docs describe its focus as the software asset register, supplier management and software integrity, and say it is on in your workspace unless you switch it off in Compliance › Manage. The page lists requirements decided by a scan, extra controls from Safeguard's own control catalog, and policy templates, including a Government Information Security Policy Framework template and a Cryptography and Network Security Policy template written for the NZISM. The requirement and control IDs on that page are Safeguard's own labels, not the NZISM's control numbering.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX. Software composition analysis with deep transitive dependency scanning (GA) covers the open source underneath. From the CLI, the docs show safeguard scan --dir . for a local directory, safeguard scan --image for a container image, safeguard scan --repo for a Git repository and safeguard scan --sbom for an SBOM you already have. Results are written as JSON under ./output.
3. Let each scan check the NZISM requirements. The docs list six requirements decided by a scan against the product's SBOM, under Safeguard's labels: NZISM-ASSET-REG (an inventory of components in use), NZISM-PATCH (the installed version of each component is known, so it can be patched), NZISM-SUPPLIER (named suppliers for software components), NZISM-INTEGRITY (integrity hashes so software can be verified as unmodified), NZISM-VULN (PURL or CPE identifiers so components match vulnerability sources) and NZISM-DOC (dated, identifiable SBOM documentation). Controls a scan cannot see, such as a policy framework or business continuity planning, are evidenced with automated tests, uploaded evidence, policies or an attestation.
4. Rank vulnerabilities for the two-day window. Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis (GA) shows which vulnerable code paths your application actually calls. That gives you the split between "on the two-day clock" and "on the normal schedule" that a written patch policy depends on.
5. Enforce with policies and gates. Policies, gates and guardrails (GA) let you write rules such as blocking critical CVEs or unmaintained dependencies, from Policies → Create Policy, using the visual builder or YAML. Each policy's action is Block, Warn or Notify. Approval for a legitimate exception runs through the exception workflow, with a business justification and an expiration date. In CI, the docs show:

safeguard ci scan --wait --fail-on-gate <gate>

6. Collect supplier SBOMs. TPRM (GA) lets you open a vendor, click Request SBOM, set a deadline and send, or send bulk requests to many vendors. Received SBOMs get a completeness check. Automatic reminders go out seven days before the deadline and at the deadline, with escalation seven days after. That is evidence for supplier questions in the PSR self-assessment, the RBNZ survey and the NCSC's supplier guidance.
7. Share SBOMs with your own customers. The Portal publish and share product (GA) and the Trust Center (GA) let you publish your posture and share SBOMs with customers, including NDA-gated sharing. That answers an agency questionnaire asking what is inside your product.
8. Inventory AI assets. AI-BOM discovery (GA) inventories models, ML dependencies, notebooks, prompts, vector stores, agents, MCP servers and inference endpoints, including model files such as .safetensors and .gguf, into one tenant-scoped AI bill of materials. That is the starting point for Public Service AI Framework and Privacy Act conversations about where AI is used.
9. Fix, with a human in charge. Autonomous remediation (GA) can open tested, policy-gated pull requests that move a dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual.
10. Keep code and data where your rules need them. Safeguard's SaaS runs in US, EU and Gov regions only; there is no New Zealand region. For residency or IPP 12 concerns, the GA answers are private VPC or dedicated tenancy, full on-prem, fully air-gapped deployment with the AI models running inside your environment, the local runner built into the Safeguard CLI (it scans on your own machine; source code never leaves your environment and only encrypted results are sent), and Zero AI mode, in which the platform runs with no LLM in the loop.

What Safeguard does not do

• It does not file your reports. Safeguard can shorten the time to answer "are we affected", but deciding that a breach is notifiable or that an incident is material for the RBNZ, and notifying the Commissioner, the Bank or a customer agency, stays with your nominated people.
• It does not make you compliant or assured. A framework page with every scan requirement met is evidence, not a finding. Your chief executive's PSR self-assessment, the NCSC's assurance work, your auditors and your regulators decide whether your programme meets the standard.
• It does not hold New Zealand certifications. Safeguard's own posture is "SOC 2 Type II audit in progress" and "designed for FedRAMP High". It is not on any New Zealand government panel.
• It does not host in New Zealand. SaaS regions are US, EU and Gov. If data or code must stay in New Zealand, use private VPC, on-prem, air-gapped deployment or the local runner.
• It does not patch systems it does not build. Vendor appliances, hosted services and operating system packages you do not build yourself still need the vendor's fix, and end-of-life runtimes still need a backport or an upgrade.
• It does not cover all ten minimum standards. Security awareness, multi-factor authentication, data recovery and least privilege are mostly outside a software supply chain tool. The NZISM page lists catalog controls you evidence yourself.
• It does not write your privacy impact assessments or AI policies. It inventories AI assets; the judgements the Privacy Act, the Biometric Code and the Public Service AI Framework ask for are yours.

Common mistakes

• Treating the NZISM as government-only. If your contract references it, it binds you, and a mandated customer will pass the Patching standard's expectations to you.
• Starting the clock at triage. The NZISM's two days run from the patch release, and the Privacy Commissioner's 72 hours from awareness, not from when a decision memo is signed.
• Treating the SBOM as a one-off deliverable. The two-day window needs SBOMs per release, queryable in minutes.
• Forgetting end-of-life versions. The October 2026 PHP fix covered supported versions only. An inventory that does not record end-of-support dates hides the hardest systems to fix.
• Assuming the supplier will tell you. The NCSC told organisations to ask their suppliers about PHP. Your contracts and your supplier SBOMs decide how fast you get an answer.
• Waiting for an AI law. The Privacy Act and the Biometric Code already apply to AI that handles personal information.
• Using floating version ranges in production manifests. They make patch timeframes impossible to evidence.

FAQ

Is the NZISM mandatory for private companies?

Not by law. The NZISM is written for government agencies. Suppliers to government adopt it through contracts, and once a contract requires it, it is mandatory for that supplier.

What is the NZISM patching timeframe for critical vulnerabilities?

Control 12.4.4.C.01 says agencies should apply critical security patches as soon as possible and preferably within two days of the patch release. The NCSC's Patching standard suggests two days for critical patches on external-facing systems or where working exploits exist, and two weeks on internal systems.

What are the NCSC Minimum Cyber Security Standards?

Ten foundational standards, published on 30 October 2025 under the GCISO mandate and required for GCISO-mandated agencies. They cover risk management, awareness, assets, secure configuration, patching, MFA, detection, least privilege, data recovery and response planning, each with a maturity model.

Does New Zealand require an SBOM?

No New Zealand law or NZISM control quoted here requires an SBOM by name. An SBOM is still the most direct evidence for the asset inventory, vulnerability monitoring and two-day patching expectations, and for the Privacy Act's reasonable safeguards.

How fast must a privacy breach be reported in New Zealand?

Section 114 of the Privacy Act 2020 requires notice to the Privacy Commissioner as soon as practicable after becoming aware of a notifiable privacy breach. The Commissioner's guideline is within 72 hours, and notification can be made in stages as information comes to light.

Does the RBNZ require cyber incident reporting?

Yes. The Reserve Bank requires regulated entities to report material cyber incidents as soon as practicable and within 72 hours, to report all cyber incidents periodically, and to self-assess against its Guidance on Cyber Resilience.

Does New Zealand have an AI law?

No. The National AI Strategy launched in July 2025 without an AI statute, and public agencies are encouraged to align with the non-binding Public Service AI Framework. The Privacy Act and the Biometric Processing Privacy Code apply to AI that handles personal information.

Can personal information be sent outside New Zealand?

Yes, on the grounds IPP 12 lists, such as the recipient being subject to the Act or to comparable privacy laws, or being bound by an agreement to protect it comparably. Otherwise the individual must authorise it after being told it may not get the same protection.

Can our source code stay in New Zealand if we use Safeguard?

Safeguard has no New Zealand SaaS region. You can keep code in your own environment with the local runner, or deploy Safeguard in a private VPC, on-prem or fully air-gapped, with Zero AI mode if no model may touch the code.

Every New Zealand regime above eventually asks how fast a known vulnerability stops running in production, whether that is the NZISM's two-day target or the reasonable safeguards IPP 5 demands. The block below explains how Safeguard closes the gap between a published fix and your builds, and what to do when no fix exists yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows the residency answer in practice: you set up the runner on your own machine, approve it with its device code, then scan from the terminal. For a New Zealand team that cannot send source code offshore, this is how SBOMs and findings get produced without the code leaving your environment.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session: it installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That is the shape of meeting a two-day patch target without handing control to a tool.

Click through it at your own pace, or open it full screen.

The Claude demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. GRC and AppSec teams can use the same pattern to ask an assistant which products contain a component during the first hours of an incident, with access limited to the tools you allow.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• PHP2Shell, CVE-2026-109618 and CVE-2026-109619 explained
• Find and patch every PHP runtime after PHP2Shell
• SBOM incident response: finding affected products fast
• Incident response playbook for a compromised dependency

Sources

• NCSC: NZISM v3.9 release
• NCSC: Minimum Cyber Security Standards
• NCSC: Minimum Cyber Security Standards, Patching
• NCSC: Protective Security Requirements annual self-assessment
• NCSC: encourages immediate patching against PHP vulnerability
• NCSC: Canvas data breach affecting some learning institutions
• NCSC: Quarter One sees significant cyber incidents
• NCSC: Cyber Threat Report 2026
• NCSC: Strengthening your supply chain security
• NCSC: Five Eyes call to action on AI preparedness
• Office of the Privacy Commissioner: privacy breaches
• Office of the Privacy Commissioner: How long is 72 hours?
• Office of the Privacy Commissioner: Principle 12, disclosure outside New Zealand
• Office of the Privacy Commissioner: Principle 5, storage and security
• Office of the Privacy Commissioner: Principle 3A
• Office of the Privacy Commissioner: Biometric Processing Privacy Code 2025
• Office of the Privacy Commissioner: information for privacy officers
• Reserve Bank of New Zealand: New measures to build cyber resilience (4 March 2024, as republished by Scoop)
• Government Chief Digital Officer: Public Service AI Framework
• Safeguard docs: New Zealand NZISM
• Safeguard docs: compliance frameworks
• Safeguard docs: CLI
• Safeguard docs: CLI usage
• Safeguard docs: policies and gates
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: AI-BOM discovery
• Safeguard docs: air-gapped deployment

To try the CLI and local runner yourself, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.