August 25, 2026

NCSC NZ Released New Minimum Cyber Security Standards. Here’s What That Actually Means.

On 30 October 2025, New Zealand’s National Cyber Security Centre (NCSC) released a document called the “Minimum Cyber Security Standards”…

By Shamila azeem

8 min read

On 30 October 2025, New Zealand's National Cyber Security Centre (NCSC) released a document called the "Minimum Cyber Security Standards" (MCSS). While I think they have done a wonderful job in explaining it, I did felt a need to make it even simpler for anyone someone thinking about getting into IT, or someone who keeps hearing terms like "cyber security framework" or "minimum standard" and wants a simpler explaination. I'm going to define terms as I go, because I remember what it's like to read a sentence with five acronyms in it and understand none of them.

What is a "minimum cyber security standard"?

Imagine you were told to make a building safe. You wouldn't just say "make it safe" and walk away. You'd need concrete rules such as smoke alarms must be installed, fire exits must be clearly marked and never blocked, wiring must meet the safety requirement. A minimum cyber security standard works the same way, but for protecting computer systems and the information stored on them.

The NCSC NZ framework defines ten specific security standards that require organisations to demonstrate tangible, practical measures rather than rely on broad or aspirational statements about being "secure." These standards represent the minimum level of acceptable security practice. They are not intended to cover every aspect of good security; instead, they establish the baseline. When an organisation fails to meet any of these standards, it is not a minor oversight. It indicates that a fundamental and essential security control is missing.

Before discussing the ten standards, it is important to understand that they apply to two specific categories of systems rather than every asset an organisation operates.

  1. Business‑critical systems: These are the systems an organisation relies on to function day to day.

  2. Externally facing systems: This is any system that can be reached from outside the organisation or is connected to something that can be.

This distinction matters because the intent is not to secure every laptop, spreadsheet, or internal tool. The focus is on securing the systems whose failure or compromise would cause real harm to the organisation.

The ten standards, explained one by one

NCSC organises the ten standards into five broader stages. The following sections outline each stage in order and explain what each standard actually requires, rather than relying on the title alone.

Stage 1: Guide and Govern

This stage focuses on leadership, structure, and intentionality. It ensures that security is not left to chance or informal practice.

1. Risk Management: This standard is based on a simple principle: an organisation cannot protect itself from risks it has not identified. It requires a defined and repeatable process for identifying cyber risks and threats, assessing the potential impact they could have, and determining how those risks will be managed. This includes formally deciding which risks the organisation is willing to accept. In practice, this means regularly reviewing emerging threats to determine their relevance and maintaining a documented process for evaluating and responding to risk, rather than relying on informal monitoring by individual staff.

2. Security Awareness: This standard focuses on people rather than technology. Its purpose is to ensure staff understand enough about cyber security to carry out their daily work safely and to feel confident reporting anything that appears suspicious. A phishing email can bypass technical controls if a staff member interacts with it before those controls take effect. To meet this standard, organisations are expected to run structured security awareness programmes, such as training modules or education sessions, and to provide clear, accessible channels for staff to report potential issues without hesitation or friction.

Stage 2: Identify and Understand

3. Assets and Their Importance: An organisation cannot protect what it has not identified. This standard requires a clear understanding of all systems, data, and services the organisation relies on, including those operated by third‑party providers. Once identified, these assets must be assessed to determine their relative importance. Not all systems carry the same weight: a public‑facing marketing website does not warrant the same level of protection as a payroll database or an identity management system.

The purpose of this standard is to ensure organisations prioritise their security efforts. By ranking assets according to their criticality, they can apply the appropriate level of protection where it matters most, rather than distributing resources evenly across all systems and diluting their effectiveness.

Stage 3: Prevent and Protect

This is the largest stage in the framework. Four of the ten standards sit here, and they focus on the practical, technical measures required to secure systems effectively.

4. Secure Configuration of Software: The Software is rarely secure in its default state. Out‑of‑the‑box configurations often include default passwords, unnecessary features enabled, and settings that prioritise convenience over security. This standard requires organisations to actively harden their software. That includes following vendor guidance for secure setup, implementing a formal change‑management process for updates and configuration changes, and regularly auditing systems to ensure they still match the intended secure configuration. For organisations that develop their own software, this standard also requires integrating security into the development lifecycle itself, rather than attempting to add it retrospectively.

5. Patching: It is the controlled process of applying vendor‑issued updates that remediate security vulnerabilities in systems and applications. The NCSC standard requires organisations to maintain a structured patch management approach, including clear timelines for addressing different severities of vulnerabilities, testing patches before deployment, and approving changes through a defined change‑control process. It also expects organisations to track systems approaching end‑of‑support and plan upgrades or replacements in advance, ensuring they do not operate technology that can no longer receive security fixes.

6. Multi-factor Authentication (MFA): MFA requires users to provide more than one form of verification when accessing a system. NCSC describes these verification types as something you know (such as a password), something you have (such as a phone or security key), and something you are (such as a fingerprint). The purpose is to ensure that even if an attacker obtains a password, they still cannot gain access without the second factor. This standard requires MFA on business‑critical systems, internet‑facing systems, and privileged accounts. It also expects organisations to manage MFA as an ongoing operational capability: budgeting for it, monitoring its effectiveness, maintaining an inventory of MFA devices, and having clear processes for resetting or revoking authentication tokens, particularly for privileged users.

7. Least Privilege: The principle of least privilege states that users, applications, and processes should only have the access necessary to perform their role, and nothing more. NCSC highlights a common real‑world issue: as people move between roles, their access often accumulates rather than being adjusted. Over time, this results in accounts with far broader permissions than required, increasing the potential impact if those accounts are compromised. This standard requires organisations to formally define the access needs for each role, maintain a register of accounts and permissions, and conduct regular reviews of who has access to what. More mature implementations may also use just‑in‑time access, where elevated permissions are granted temporarily for a specific task and automatically revoked afterwards, rather than being permanently assigned.

Stage 4: Detect and Contain

8. Detect Unusual Behaviour: No organisation prevents every attack, so this standard focuses on the ability to recognise when something abnormal is occurring within systems. This standard focuses on an organisation's ability to identify abnormal or unintended activity within its systems so potential compromises can be detected early and contained quickly. It requires establishing a baseline of normal behaviour, monitoring for indicators such as repeated login failures, unexpected privilege escalation, unusual network or compute usage, or authentication from improbable locations, and having a defined response plan when such activity occurs. Effective detection relies on centralised logging, continuous monitoring, and clear processes that allow organisations to recognise suspicious behaviour before it escalates into a wider incident

Stage 5: Respond and Recover

9. Data Recovery: This standard focuses on ensuring organisations can restore critical information if data becomes lost, corrupted, deleted, or otherwise inaccessible. It requires having defined recovery objectives, appropriate recovery methods, and a clear policy that supports business continuity. Organisations must understand which systems are most critical, identify their data retention needs, and regularly test their recovery procedures to confirm they work in realistic scenarios. Effective data recovery relies on sound backup practices, clear roles and responsibilities, and ongoing investment to ensure that essential systems can be restored quickly and reliably when incidents occur.

10. Response Planning: This standard requires organisations to have a structured, well‑developed, and regularly tested plan for responding to cyber incidents. Rather than improvising during a crisis, organisations must identify the types of events most likely to occur, define how those incidents will be managed, and ensure the plan aligns with their risk appetite. Effective response planning includes clear roles and responsibilities, adequate resourcing, documented procedures, and routine exercises so staff can confidently execute the plan. The goal is to minimise the impact of an incident, restore operations efficiently, and maintain organisational resilience.

The part that surprised me most: this isn't pass or fail

One of the most striking aspects of the NCSC framework is that it is not a binary standard. It does not ask whether an organisation simply "has" a control or "does not have" it. Instead, NCSC evaluates each standard through the Cyber Security Capability Maturity Model (CS‑CMM), which measures how reliable, repeatable, and embedded a security practice is within the organisation. Rather than checking a box, agencies assess the maturity of each control across four levels.

CS‑CMM 1 — Informal: Security practices may exist, but they are ad‑hoc, inconsistent, and dependent on individual staff rather than institutional processes. Capability is fragile: if the one person who set up MFA left, the practice might collapse. This level reflects activity that is happening, but not reliably.

CS‑CMM 2 — Planned and Tracked (the minimum requirement): Security capability is defined, documented, and repeatable. Policies and processes exist, are followed, and are designed to meet core organisational requirements. This is the baseline NCSC expects: not perfection, but deliberate, structured practice that does not rely on individual heroics.

CS‑CMM 3 — Standardised: Security capability is integrated and applied consistently across the entire organisation. Controls are governed at an enterprise level, not implemented unevenly across business units. NCSC recommends agencies aim for this level because it eliminates patchiness and ensures security is uniformly understood and executed.

CS‑CMM 4 — Quantitatively Controlled: The most advanced level. Security performance is measured, monitored, and improved using data. Controls are continuously refined, and security becomes a strategic organisational priority rather than an IT function.

Understanding this model reframes what the minimum maturity requirement represents. Setting the baseline at CS‑CMM 2 means it is not sufficient for a security control to exist informally or depend on the expertise of a single individual. The capability must be intentional, documented, repeatable, and resilient to staff turnover. This establishes a higher and more meaningful bar than a simple yes‑or‑no compliance check, while remaining realistic and achievable for most organisations. It provides a clear foundation to build from and a defined pathway for progressing toward more mature, enterprise‑wide security practices over time.

Agencies self‑assess against this maturity model using the Protective Security Requirements (PSR) Self‑Assessment Tool, answering "Yes," "No," or "Partial" for each requirement, with space to explain context or planned investment. The first reporting period ran from 1 November 2025 to 30 April 2026, meaning this framework is already in active use. It is not a theoretical document; organisations are expected to measure themselves against it regularly and demonstrate progress over time.

Why does this matter?

The introduction of the Minimum Cyber Security Standards represents a significant shift in how New Zealand approaches cyber resilience. Instead of relying on broad expectations or inconsistent practices across agencies, the standards establish a shared baseline and a common language for what acceptable security looks like. They require organisations to treat cyber security as an ongoing capability rather than a one‑off project, and they provide a structured path for improvement over time. For people entering IT or cyber security, the framework offers a clear view of the essential practices that form the foundation of modern security. It shows that effective security is not about perfection, but about deliberate, documented, and repeatable processes that can be sustained regardless of staff changes. By focusing on critical systems and measurable maturity, the standards give organisations a realistic starting point and a practical way to strengthen their security posture in a consistent and accountable manner.

Closing thoughts

If you have ever completed a CS‑CMM self‑assessment in a government agency or elsewhere, I would genuinely value hearing what that experience was like. In particular, I am interested in how the shift from Informal to Planned and Tracked felt in practice. That kind of insight is impossible to obtain from published guidance alone, and it is exactly the perspective that helps turn frameworks into something real and lived.

Thank you for taking the time to read this. I appreciate you being here, and I hope this helped make the Minimum Cyber Security Standards a little clearer. Your curiosity and willingness to understand the details genuinely matter. See you in the next one.

Sources: