Questions are ordered from the core framework-selection decision through the New Zealand government and SME options, international standards and attestations, entity-specific choices, mapping, implementation evidence and the misconceptions most likely to create duplicated work or false assurance.
Which cyber security framework should a New Zealand organisation use?
There is no single framework that every private New Zealand organisation must use. Start with the outcome the organisation needs. A small business needing practical protection should begin with Own Your Online and use the NCSC Critical Controls as its priority control set. An organisation needing a broad risk-management structure can use the five-function NCSC Cyber Security Framework or NIST Cybersecurity Framework 2.0. CIS Controls v8.1 is useful when the main need is a detailed, prioritised implementation list. ISO/IEC 27001:2022 is appropriate when the organisation needs a formal information security management system and may need accredited certification. SOC 2 is not a general New Zealand cyber framework or certification; it is an AICPA attestation report mainly used by service organisations to give customers assurance about controls. NZISM and the Protective Security Requirements are government-focused and may reach private suppliers through contracts or government information requirements. Whichever framework is chosen, a business holding personal information must still meet Privacy Act 2020 information privacy principle 5 by using safeguards that are reasonable in the circumstances.
- small private business — Use Own Your Online first, then the NCSC Critical Controls for a practical New Zealand baseline.
- larger or higher-risk organisation — Use the NCSC or NIST framework for governance and risk outcomes, supported by CIS or ISO controls.
- government agency or government supplier — Assess PSR, NZISM, NCSC Minimum Standards and contract-specific government requirements.
- technology or outsourced service provider — Consider ISO/IEC 27001 certification or SOC 2 attestation when customers require independent assurance.
We select cyber security frameworks according to our legal duties, information sensitivity, service criticality, threats, customer requirements and assurance needs. We maintain one control register and map each adopted framework to it. Framework adoption does not replace Privacy Act, sector, contractual or incident-notification obligations.
What are the NCSC Cyber Security Framework and the NCSC Critical Controls?
They perform different jobs. The NCSC Cyber Security Framework organises an organisation's cyber programme into five concurrent functions: Guide and Govern; Identify and Understand; Prevent and Protect; Detect and Contain; and Respond and Recover. It describes desired outcomes and can be used across sectors and organisation sizes. The Critical Controls are a more specific annual priority list based on incidents reported to NCSC and international threat information. The current top ten are: patch software and systems; implement multi-factor authentication and verification; provide and use a password manager; centralised logging; build security awareness; asset lifecycle management; implement and test backups; application control; least privilege; and network segmentation and separation. Use the framework as the programme structure and the Critical Controls as a practical priority set. They are guidance for a private organisation, not a certificate or automatic legal safe harbour.
- NCSC Cyber Security Framework — Use the five functions to organise governance, prevention, detection, response and recovery outcomes.
- NCSC Critical Controls — Use the current top ten to prioritise concrete technical, people and process improvements.
- private organisation — Adopt proportionately and retain evidence; do not describe voluntary guidance as government certification.
Our cyber programme is organised under Guide and Govern, Identify and Understand, Prevent and Protect, Detect and Contain, and Respond and Recover. We maintain an owner, scope, target, evidence source, review date and exception record for each current NCSC Critical Control and review the NCSC source at least annually.
Where do Own Your Online, NZISM and the Protective Security Requirements fit?
Own Your Online is the NCSC's plain-language route for individuals and businesses and is the best starting point for many small organisations. Its business guidance covers supported and updated systems, 2FA, backups, logging, password managers, secure devices and networks, manual payment verification, cloud-provider checks, data minimisation, an online security policy and an incident response plan. NZISM is the New Zealand Government's detailed information-security practitioner manual. It is intended for government agencies and organisations; Crown entities, local government and private organisations are encouraged to use it, and vendors or contractors serving agencies may need selected controls through contract. The Protective Security Requirements set government expectations across governance, personnel, information and physical security. Their INFOSEC mandatory requirements apply to mandated government agencies, while other organisations may use them as best practice. A private SME should not claim that NZISM or PSR automatically applies in full unless a mandate, contract, procurement condition, classification requirement or adopted internal standard makes it binding.
- Own Your Online — Plain-language starter guidance and assessment tools for small and medium businesses.
- NZISM — Detailed government control manual, useful to government suppliers and voluntarily adoptable by private organisations.
- Protective Security Requirements — Government protective-security policy framework with mandatory requirements for mandated agencies.
We use Own Your Online as our plain-language implementation baseline. NZISM and Protective Security Requirements controls apply where required by a government mandate, contract, procurement condition, information classification or approved internal standard. We record the source and status of every adopted requirement.
How do ISO/IEC 27001, CIS Controls, NIST CSF and SOC 2 differ?
ISO/IEC 27001:2022 is a requirements standard for an information security management system. It is risk-based, supports independent certification and is useful where customers want recognised management-system assurance. CIS Controls v8.1 is a prescriptive, prioritised implementation set containing 18 Controls; Implementation Group 1 is an entry point with 56 Safeguards aimed at essential cyber hygiene. NIST Cybersecurity Framework 2.0 is a flexible, country-neutral set of cyber-risk outcomes organised into six functions: Govern, Identify, Protect, Detect, Respond and Recover. It uses current and target profiles and four Tiers to help organisations describe and improve risk-management practice, but it is not a certification scheme. SOC 2 is different again: it is an AICPA examination and assurance report for service organisations, based on criteria relating to security, availability, processing integrity, confidentiality and privacy. It is not a New Zealand law, not an ISO certificate and not usually the best first internal framework for a small non-technology business.
- ISO/IEC 27001 — Certifiable risk-based management system for governance, control selection, assurance and continual improvement.
- CIS Controls v8.1 — Prioritised implementation catalogue; IG1 offers a practical essential-hygiene starting point.
- NIST CSF 2.0 — Six-function outcome framework for describing current and target cyber-risk posture.
- SOC 2 — CPA attestation report for controls at a service organisation, primarily supporting customer assurance.
We distinguish management systems, outcome frameworks, control catalogues and assurance reports. ISO/IEC 27001 governs our ISMS where adopted; NCSC or NIST structures our outcomes; CIS supports implementation detail; and SOC 2 is pursued only when service customers require an attestation report. We do not describe these instruments as interchangeable.
How do I choose a framework for my organisation type and customer market?
Choose from the outside in. First list the laws, licences, contracts, tenders and customer assurance requests that apply. Then identify the critical services, information, systems, suppliers and consequences of disruption or disclosure. A small local business with ordinary cloud systems will usually get more value from Own Your Online, the NCSC Critical Controls and a concise risk register than from immediate certification. A medium or large New Zealand organisation can use the NCSC Cyber Security Framework as its local programme structure and CIS Controls or NZISM for implementation detail. A SaaS or managed-service provider selling to enterprise or overseas customers may need ISO/IEC 27001 certification, SOC 2, or both because buyers ask different assurance questions. A government supplier should map the contract to PSR and NZISM rather than assuming an ISO certificate automatically satisfies agency requirements. An organisation with US customers may find NIST or SOC 2 familiar; one with global procurement requirements may find ISO more portable. Select one primary structure and map other requirements to it rather than operating separate programmes.
- small local SME — Own Your Online plus NCSC Critical Controls and a proportionate evidence pack.
- medium or large private organisation — NCSC Cyber Security Framework or NIST CSF for outcomes, with CIS or ISO controls.
- SaaS or managed-service provider — ISO/IEC 27001 and/or SOC 2 where customers require independent assurance.
- government supplier — Contract-led mapping to PSR, NZISM, classification and agency-specific requirements.
The security owner maintains a framework decision record identifying our legal duties, customer requirements, critical services, risk profile, selected primary framework, supporting control sources and assurance commitments. New framework requests are mapped to the existing control register before separate processes or tools are created.
How should a New Zealand organisation set a maturity target?
Do not treat maturity as a contest to reach the highest score everywhere. Set a target for each critical service based on personal-information sensitivity, operational dependence, internet exposure, likely threats, supplier access, customer promises and the harm caused by failure. The NCSC framework supplies outcome areas but is not a private-sector certification scale. NIST CSF 2.0 offers four Tiers that characterise the rigour of cyber-risk governance and management, while CIS uses Implementation Groups to prioritise safeguards according to organisational risk and resources. The NCSC's separate Cyber Security Capability Maturity Model supports its Minimum Cyber Security Standards for GCISO-mandated agencies; private organisations may learn from it but should not present an internal score as government assurance. A practical private-sector target can be documented as current state, target state, gap, owner, due date, evidence and accepted exceptions. Higher targets should be applied first to privileged access, critical services, sensitive data and externally exposed systems.
- current and target posture — Describe what operates now, what outcome is needed and the evidence required to close each gap.
- NIST Tiers or CIS Implementation Groups — Use them as decision aids rather than universal grades or legal thresholds.
- GCISO-mandated agency — Use the official NCSC Minimum Standards and capability maturity reporting requirements.
We set a current and target cyber capability for each critical service based on sensitivity, exposure, business impact, threat, regulation and customer commitments. Each gap has an owner, due date, evidence requirement and approved exception process. Maturity labels are not represented as certification or government endorsement.
How do we map several frameworks without duplicating policies, controls and evidence?
Create one internal control system and treat external frameworks as reference columns. Each internal control should have one identifier, owner, objective, scope, systems, procedure, frequency, evidence source, metric, exception process and review date. Then map that control to applicable NCSC outcomes, Critical Controls, Own Your Online guidance, IPP 5, NZISM or PSR requirements, ISO clauses and Annex A controls, CIS Safeguards, NIST outcomes and SOC 2 criteria. For example, one access-control family can cover MFA, password management, least privilege, joiner-mover-leaver processes and privileged-access review while carrying several framework references. A mapping indicates a relationship, not automatic equivalence: wording, scope, assurance period and evidence may differ. Keep a framework-specific requirement only where it genuinely adds something, such as ISO management-system clauses, a government classification rule, a customer's reporting deadline or SOC 2 complementary user-entity controls.
- single control register — Use one owner, procedure and evidence source for each real control outcome.
- crosswalk columns — Map external clauses, controls, safeguards and criteria to the internal control.
- framework-specific additions — Preserve genuinely different scope, evidence, reporting, attestation or certification requirements.
Our control register is the source of truth. Each control has one owner, objective, scope, operating procedure, frequency, metric, evidence source and exception process. External frameworks and customer requirements are mapped to those controls. A cross-reference is not treated as proof of equivalence, operation, compliance, certification or attestation.
What implementation evidence should we keep?
Keep evidence that the framework operates, not only a policy or completed questionnaire. A proportionate evidence set includes the framework decision and scope; legal and contractual requirements; asset, information, supplier and critical-service inventories; risk assessments and treatment decisions; control owners; MFA, access and privileged-account reports; patch and end-of-life reports; password-manager coverage; logging and alert configuration; backup and restore-test results; awareness and verification records; supplier reviews and security clauses; vulnerability and configuration findings; incident plans, exercises and incident records; metrics; approved exceptions; internal reviews; management decisions; and corrective-action closure evidence. Evidence should show the period, system, reviewer, exception and follow-up action. For ISO or SOC 2, the evidence must also support the precise certified or examined scope and audit period. For IPP 5, evidence helps demonstrate why safeguards were reasonable in the circumstances, but no framework or evidence folder creates an automatic legal safe harbour.
- design evidence — Scope, policies, risks, requirements, architecture and control design show what should happen.
- operating evidence — System exports, tickets, logs, reviews and test results show what occurred.
- assurance evidence — Exercises, internal audits, management review, exceptions and corrective actions show effectiveness and improvement.
Every adopted control must have dated evidence showing its owner, scope, operation, review and exceptions. Evidence is retained centrally and linked to the control register. A policy, dashboard score, certificate or attestation report is not treated as sufficient evidence for systems or periods outside its stated scope.
What are the common mistakes when choosing or using cyber security frameworks in New Zealand?
Common mistakes include calling Australia's Essential Eight or SMB1001 a New Zealand government baseline; assuming NIST CSF still has five functions when version 2.0 has six; confusing the five NCSC functions with the ten NCSC Critical Controls; treating NZISM and PSR as automatically mandatory for every private business; calling SOC 2 a certification; claiming a product itself is ISO 27001 certified when the certificate covers an organisation's scoped ISMS; implementing several frameworks as separate policy libraries; treating a mapping as proof of compliance; pursuing certification before the underlying controls operate; applying the same maturity target to every system; and assuming any framework guarantees security or Privacy Act compliance. Another frequent gap is choosing a governance framework without enough implementation detail, or choosing a technical checklist without governance, risk ownership, response and recovery. A useful programme normally combines one governing structure, one prioritised control source and only the assurance mechanism customers actually require.
- label confusion — Distinguish New Zealand guidance, international standards, control lists, certifications and attestations.
- duplication — Avoid separate owners, policies and evidence folders for controls that achieve the same outcome.
- false assurance — Do not treat scores, certificates, mappings or reports as guarantees outside their scope and period.
- private New Zealand business — Keep IPP 5, contracts and sector duties visible even when using an international framework.
We describe frameworks and assurance accurately. We do not represent Australian baselines as New Zealand government frameworks, SOC 2 as certification, a product as ISO/IEC 27001 certified, or a mapping as proof of compliance. Every assurance claim identifies its issuer, scope, period, limitations and supporting evidence.
What's my next step?
Common misconceptions
- Australia's Essential Eight is New Zealand's official private-sector baseline. It is not; New Zealand organisations should look first to Own Your Online, NCSC guidance and applicable New Zealand obligations. INFERRED
- SMB1001 is a New Zealand government framework. No such status was identified in current NCSC or New Zealand government framework material. INFERRED
- The NCSC Cyber Security Framework contains ten functions. It contains five functions; the separate Critical Controls publication contains a current top ten. VERIFIED
- NIST CSF 2.0 has five functions. Version 2.0 has six: Govern, Identify, Protect, Detect, Respond and Recover. VERIFIED
- NZISM and PSR automatically bind every private New Zealand business. They are government-focused, although contracts, procurement or handling government information may make selected requirements binding. INFERRED
- SOC 2 is a certification like ISO/IEC 27001. SOC 2 is an AICPA attestation examination and report for service-organisation controls. VERIFIED
- ISO/IEC 27001 certifies a software product as secure. Certification concerns an organisation's ISMS within the stated scope. INFERRED
- CIS Implementation Group 1 is a New Zealand legal minimum. CIS calls it essential cyber hygiene, but it is not itself New Zealand legislation. INFERRED
- Adopting a framework automatically proves compliance with Privacy Act 2020 IPP 5. IPP 5 remains a context-specific reasonable-safeguards requirement. INFERRED
- A crosswalk proves two framework requirements are identical. Mappings identify relationships but may not capture different scope, evidence, timing or assurance conditions. INFERRED
- The highest maturity score should be the target for every system. Targets should reflect risk, criticality, sensitivity, resources and obligations. INFERRED
- A certificate, SOC report or framework score guarantees that no breach will occur. These provide scoped assurance or structure, not immunity from incidents. INFERRED
Obligations at a glance
The obligations most relevant to this guide, with the regulator, the trigger and the timeframe. Follow the source links in the appendix for the authoritative wording.
| OBLIGATION | REGULATOR | TRIGGER | TIMEFRAME | PENALTY |
|---|---|---|---|---|
| Privacy Act 2020 IPP 5 reasonable security safeguards | Office of the Privacy Commissioner | A New Zealand agency holds personal information. | Ongoing while the information is held and whenever systems, suppliers, risks or handling arrangements change. | |
| Privacy Act 2020 IPP 5 service-provider safeguards | Office of the Privacy Commissioner | Personal information is given to another person in connection with a service provided to the agency. | Before and throughout the service relationship, using everything reasonably within the agency's power to prevent unauthorised use or disclosure. | |
| Use of a cyber security framework by public service departments | Protective Security Requirements system and National Cyber Security Centre | The organisation is a public service department subject to mandatory PSR obligations. | Ongoing as part of the department's cyber security and PSR assurance programme. | |
| PSR INFOSEC mandatory requirements | New Zealand Government protective-security system | The organisation is a mandated government agency or a binding instrument requires specified PSR measures. | Ongoing, with assurance and review under applicable PSR instructions. | |
| NCSC Minimum Cyber Security Standards | National Cyber Security Centre under the Government Chief Information Security Officer mandate | The organisation is a GCISO-mandated agency required to implement the ten Minimum Cyber Security Standards. | According to the NCSC and PSR assurance reporting cycle applicable to the agency. | |
| NZISM controls incorporated into a government or contractual requirement | Relevant government agency or contracting authority | A mandate, information classification, procurement condition or contract incorporates specified NZISM controls. | As stated in the applicable mandate, system-authorisation process or contract. | Contractual or government-assurance consequences may apply, depending on the instrument. |
| Contractual ISO/IEC 27001, NIST, CIS or SOC 2 assurance requirement | Customer, contracting authority or party entitled to enforce the agreement | A tender, contract or supplier schedule requires specified framework alignment, certification, attestation or reporting. | As stated in the contract, including any renewal, notice, evidence or remediation deadlines. | Contractual remedies may apply, depending on the agreement. |
Sources
- NCSC Cyber Security Framework primary
- NCSC Critical Controls: Summary primary
- NCSC Minimum Cyber Security Standards primary
- NCSC Cyber Security Capability Maturity Model primary
- Own Your Online — Top online security tips for your business primary
- Own Your Online — Create an incident response plan primary
- Own Your Online — Create an online security policy for your business primary
- New Zealand Information Security Manual primary
- Protective Security Requirements framework primary
- Protective Security Requirements — Information security primary
- Privacy Act 2020 Principle 5 — Storage and security of information primary
- ISO/IEC 27001:2022 — Information security management systems primary
- ISO certification and conformity assessment primary
- The 18 CIS Critical Security Controls primary
- CIS Controls Implementation Group 1 primary
- CIS Controls Navigator primary
- NIST Cybersecurity Framework 2.0 primary
- AICPA System and Organization Controls suite of services primary
- AICPA Trust Services Criteria primary
- AICPA Trust Services Criteria mappings primary
- Geekzone discussion of proportionate business security forum
- r/newzealand discussion of ISO 27001 scope and assurance forum
- CIS Controls Implementation Groups primary
This guide and its templates are a professionally drafted starting point, not legal advice. Your obligations depend on your industry, your contracts and your data. Have a qualified adviser review anything high stakes before you rely on it.