The Filing Cabinet Problem
The short version: Only 31% of NZ small and mid-sized businesses have formal IT policies, and most of those were written once and never reviewed. Template policies that sit in a drawer are treated the same as no policies at all by insurers, auditors, and the Privacy Commissioner — but turning them into living, functional documents is a structured process, not a rebuild from scratch. Start with a Security Baseline Assessment to find out which of your policies actually protect you. Read on for the full breakdown.
Somewhere in your organisation — in a shared drive, a Teams folder, or perhaps literally in a filing cabinet — there is a set of security policies. They were written at some point. They were probably written for a reason: a client questionnaire, a compliance audit, a well-intentioned project to "get our security sorted."
They are almost certainly not being used.
This is not a fringe observation. Research from ASI and NZ-based studies indicates that only 31% of New Zealand small and mid-sized businesses have formal IT policies in place at all (ASI/NZ research). Among the businesses that do have policies, a familiar pattern appears: the documents were created once, filed away, and have not been reviewed, tested, or meaningfully referenced since.
The result is a specific kind of organisational risk — the false confidence that comes from having documentation that looks like governance but does not function as governance. Your policies exist. Your policies do not work. And the gap between those two facts is where breaches, compliance failures, and insurance claim denials live.
According to Kordia's 2025 New Zealand Cyber Resilience Report, 59% of New Zealand businesses experienced a cyber attack or incident in 2024 (Kordia, 2025). Approximately 50% have never tested their incident response plan (Kordia, 2025). Around 33% do no board-level reporting on cyber risk at all (Kordia, 2025). These numbers describe a country where security governance is, for the majority of businesses, either absent or performative.
This article is about the difference between performative policy and functional policy — and what it takes to move from one to the other.
Why Template Policies Fail
The template policy industry is thriving. You can buy a pack of security policy documents online for a few hundred dollars, or download free templates from dozens of cybersecurity vendors. Many managed service providers include a set of template policies as part of their onboarding package.
These templates are not inherently bad. A well-written template provides structure, covers the right topics, and uses language that meets general compliance standards. The problem is not what template policies contain. The problem is what they lack.
They Are Generic by Design
A template acceptable use policy describes what employees should and should not do with "company IT resources." But it does not name your systems. It does not reference your specific tools, platforms, or workflows. It does not address the particular risks your industry faces or the regulatory environment you operate in. It is written to be applicable to any business, which means it is specific to none.
When staff read a generic policy — if they read it at all — they see a document that does not describe their actual work. It feels abstract. It feels like a compliance exercise. And they treat it accordingly: acknowledge it, file it, forget it.
They Are Never Tested
Template policies arrive as finished documents. There is no built-in expectation that they will be tested, simulated, or stress-tested against real scenarios. An incident response plan that was purchased as a template and never run through a practice run exercise is not a plan. It is an untested hypothesis about what might happen if something goes wrong.
Kordia's 2025 data reinforces this: approximately 50% of New Zealand organisations have never practised their response plan (Kordia, 2025). For many of those organisations, the plan exists only because a template was purchased and filed. The purchase felt like progress. But progress without practice is false comfort.
They Are Disconnected from Operations
The most damaging characteristic of template policies is that they exist in isolation from how the business actually operates. They describe processes that no one follows, name roles that do not exist in the organisation, and reference review cycles that have never occurred.
This disconnect is not just an inefficiency. It is a liability. When a regulator, auditor, or insurer examines your policies, what they are looking for is evidence that the policies reflect reality. A policy that says "all access is reviewed quarterly" when no access review has ever been conducted does not demonstrate compliance. It demonstrates a gap between stated practice and actual practice — and that gap is often treated as a more serious finding than having no policy at all.
What a Living Policy Actually Looks Like
A living policy is a document that describes how your organisation actually operates, is known by the people who need to follow it, and is reviewed regularly to make sure it stays current. That definition sounds simple. In practice, it requires a fundamentally different approach to how policies are created and maintained.
It Is Specific to Your Organisation
A living information security policy does not say "the organisation shall protect its information assets." It names the assets. It references your specific systems — your Microsoft 365 environment, your accounting platform, your CRM, your cloud storage. It describes the controls that are actually in place, not the controls that a template author imagined might be in place.
When a new staff member reads a specific policy, they recognise the systems they use every day. When an insurer reviews it, they see evidence that the policy was written for this business, not downloaded from the internet.
It Is Reviewed Regularly
A living policy has a review date and an owner. The owner is accountable for ensuring the policy is examined at least annually — and updated whenever a significant change occurs. The review does not need to be a rewrite. In many cases, a 30-minute review confirms that the policy is still current. The value is in the discipline of checking — and in the documented evidence that the check occurred.
It Is Known by Staff
A living policy is actively communicated. Staff are trained on it during onboarding. Key policies are reinforced through awareness activities. Kordia's 2025 data found that 25% of New Zealand organisations cite employee awareness as their top cybersecurity challenge (Kordia, 2025). Policies are the foundation of awareness. If staff do not know the policies exist, awareness training has no anchor.
It Has Been Tested
For response-oriented policies — incident response, business continuity, disaster recovery — a living policy has been tested through practice runs or scenario walkthroughs. Testing reveals the assumptions that do not hold, the contact details that are wrong, and the notification paths that make no sense when real pressure is applied.
The Three Tests
We use three questions to determine whether a policy is functional or performative. These apply to every policy in your suite, from information security to acceptable use to incident response.
Test One: Is It Current?
Does the policy reflect the technology, people, roles, and regulatory environment of your organisation today — not two years ago? If it references systems you no longer use or names people who have left, it is stale and needs updating.
Test Two: Is It Specific to Your Business?
Could this policy belong to any business in any industry? A policy that could be swapped into a competitor's shared drive without anyone noticing is not specific enough. It must reference your actual environment, tools, risks, and processes.
Test Three: Has It Been Tested?
For response-oriented policies, has the organisation run a practice run exercise within the past twelve months? For operational policies, can you demonstrate they are being followed in practice — through audit logs, access review records, or training completion data?
If a policy passes all three tests, it is a living policy. If it fails any one of them, it is a document that creates risk rather than reducing it.
The Minimum Viable Policy Suite for a New Zealand Small and Mid-Sized Business
Not every business needs a fifty-document policy framework. But every business needs a core set of policies that covers the fundamentals. For a New Zealand small and mid-sized business, and aligned with the expectations of regulators, auditors, and cyber insurers, these are the twelve essential policies.
1. Information Security Policy. The overarching policy that establishes the organisation's commitment to information security, defines scope, and assigns accountability. This is the keystone document from which all other policies flow.
2. Acceptable Use Policy. Defines what staff can and cannot do with the organisation's IT systems, devices, and data. Covers personal use, prohibited activities, and consequences for violations.
3. Access Control Policy. Describes how access to systems and data is granted, reviewed, and revoked. Covers principles such as least privilege, role-based access, and onboarding/offboarding procedures.
4. Data Classification Policy. Establishes categories for information (e.g., public, internal, confidential, restricted) and defines handling requirements for each category. This is foundational for data protection and privacy compliance.
5. Incident Response Policy. Documents how the organisation detects, responds to, contains, and recovers from security incidents. Includes notification paths, roles, and notification obligations. This is the policy that cyber insurers scrutinise most closely — and 87% of ANZ insurers now require documented email security controls as part of broader incident readiness (Insurance Business Magazine).
6. BYOD (Bring Your Own Device) Policy. If staff use personal devices for work — and in most New Zealand small and mid-sized businesses they do — this policy defines the security requirements for those devices, including minimum configurations, acceptable applications, and the organisation's rights regarding data on personal devices.
7. Password and Authentication Policy. Defines minimum password requirements, mandates multi-factor authentication for critical systems, and describes how credentials are managed and stored. With cyber insurance applications increasingly requiring documented MFA enforcement, this policy has direct commercial consequences.
8. Backup and Recovery Policy. Describes what is backed up, how frequently, where backups are stored, and how restores are tested. This policy must address immutable or offline backups — a requirement that cyber insurers now treat as non-negotiable.
9. Vendor and Third-Party Policy. Establishes how third-party vendors are assessed, onboarded, monitored, and reviewed. Given that Kordia found 19% of incidents in 2024 were related to third-party breaches (Kordia, 2025), this policy addresses a material source of risk for every New Zealand business.
10. Privacy Policy (Internal). Goes beyond the website-facing privacy statement. This is the internal policy that describes how the organisation collects, stores, uses, and disposes of personal information in compliance with the Privacy Act 2020 and, from 1 May 2026, Information Privacy Principle 3A.
11. Remote Work Policy. Defines the security requirements for working outside the office, including network security, device management, physical security of devices, and approved tools for communication and collaboration.
12. Change Management Policy. Describes how changes to IT systems, configurations, and infrastructure are requested, approved, tested, and documented. This is the policy that prevents well-intentioned changes from introducing unintended vulnerabilities.
These twelve policies are not an exhaustive governance framework. They are the minimum. Larger or more regulated organisations will need additional policies covering areas such as cryptography, physical security, software development, or regulatory-specific requirements. But for a New Zealand small and mid-sized business, these twelve documents — if they are living, specific, and tested — provide a defensible governance foundation.
How Often Policies Should Be Reviewed (and by Whom)
A policy without a review cycle is a policy that is already going stale. Establishing a clear cadence for reviews — and clear ownership of those reviews — is what separates governance from documentation.
The Annual Review Cycle
Every policy should be formally reviewed at least once per year. The review confirms that systems referenced are still in use, people named are still accurate, the regulatory environment has not changed, controls are still being followed, and any incidents since the last review have been accounted for.
The annual review is a checkpoint, not a rewrite. It often takes 30 minutes per policy. The important thing is that it happens and is documented.
Triggered Reviews
Some events should trigger an immediate, out-of-cycle review: a significant incident that exposes a policy gap, a regulatory change (such as the introduction of IPP 3A under the Privacy Amendment Act 2025), a major system migration, or an organisational restructure. These events do not wait for the annual cycle and neither should your policy updates.
The Ownership Model
Every policy needs a named owner — the person accountable for ensuring it stays current. In a small business, one person may own most policies. In a larger organisation, ownership should be distributed to those closest to the subject matter: the IT manager for technical policies, the HR lead for acceptable use, the privacy officer for data-related policies.
Board and Leadership Oversight
Approximately 33% of New Zealand organisations do no board-level reporting on cybersecurity (Kordia, 2025). Policy governance should be visible at the senior leadership level. At minimum, boards should receive an annual summary of policy status — which are current, which are due for review, and which were updated. This single page demonstrates governance oversight and is increasingly expected by regulators, auditors, and insurers.
Policies Are Not a One-Time Purchase
The businesses that treat policies as a one-time purchase are the ones that find themselves exposed when it matters. When an incident occurs, the response plan does not match reality. When an insurer asks for evidence, the policies reference departed staff. When the Privacy Commissioner asks how personal data is handled, the documented process bears no resemblance to actual practice.
The Mercury IT ransomware attack in November 2022 illustrated this failure at national scale. When LockBit ransomware compromised the Wellington-based MSP, it cascaded across the Ministry of Justice, Te Whatu Ora, and health insurer Accuro — exposing over 14,500 coroners' files and 4,000 post-mortem reports (SecurityWeek, 2022). The downstream agencies had policies. What they did not have was a living vendor risk policy that had been tested against the scenario of their managed service provider being compromised. The policies described a world where the MSP relationship was secure. Reality proved otherwise.
The difference between these organisations and the ones that respond effectively is not budget or headcount. It is discipline: the commitment to review, to test, and to keep documentation aligned with reality.
Start With What You Have
When the OPC investigates — and complaint volumes surged 21% last year — the first thing they ask for is documentation. Policies that were written once and never reviewed are treated the same as no policies at all.
The fix is not starting from scratch. It is identifying which of your existing policies actually protect you and which ones need work. A security baseline assessment maps your current policy coverage, identifies the gaps, and gives you a prioritised path to policies that are board-approved, staff-readable, and regularly reviewed.
Start with a Security Baseline Assessment — find out which of your policies stand up to scrutiny and which are creating a false sense of security.