Five Gaps That Keep Showing Up
The short version: The same five security gaps keep showing up in NZ businesses — and none of them are technology problems. These governance gaps are where breaches, claim denials, and regulatory findings originate, but the highest-risk ones are usually addressable within the first quarter of a structured programme. Book a free consultation to find out which gaps apply to your business. Read on for the full breakdown.
Across small and mid-sized New Zealand businesses, the same weaknesses tend to show up repeatedly. Different sectors, different technology stacks, and different commercial pressures still lead back to the same underlying gaps in documentation, process, and oversight.
The pattern is consistent enough to be useful. The same five gaps show up often enough that they are worth treating as a practical starting checklist.
What makes this pattern worth examining is what these gaps have in common. None of them are technology problems. Every one is a governance problem — a gap in documentation, process, or oversight that no firewall, endpoint agent, or cloud security tool will fix on its own.
This matters because New Zealand businesses are under real pressure. 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). The threat environment is not theoretical. It is affecting more than half of the businesses operating in this country.
The five gaps we describe below determine whether an organisation can respond effectively when something goes wrong — or whether they are left scrambling.
Gap One: No Formal Information Asset Register
Why It Exists
Most businesses know, in a general sense, what systems they use. The operations manager can list the key platforms. The IT person or managed service provider has a rough picture of the network. But when someone asks for a formal register — a documented inventory of information assets, who owns them, what data they hold, and how critical they are — the answer is often the same: it does not exist.
Building an asset register is not urgent work. No client is asking for it. No deadline forces it. It sits in the category of important-but-not-urgent, which means it perpetually loses to the next support ticket, the next project, the next quarter.
Why It Matters
You cannot protect what you cannot see. Without a formal asset register, security decisions are made on assumptions. Patch management is incomplete because no one has a definitive list of what needs patching. Access reviews cannot happen because no one has documented who has access to what. Business continuity planning is guesswork because no one has classified which systems are critical and which are not.
When an incident occurs, the first question every responder asks is: what assets are affected? If the answer requires a scavenger hunt through the memories of three different people, the response is already behind.
What a Fix Looks Like
An information asset register does not need to be complicated. A structured spreadsheet is a perfectly valid starting point. What it needs to include is: the name of each asset, the type (application, database, device, service), the owner, the data classification, the criticality rating, and when it was last reviewed.
The key is not perfection. The key is that it exists, that someone owns it, and that it is reviewed at least annually. A living document that is eighty percent complete is infinitely more useful than a perfect register that no one has started.
Gap Two: No Personal Data Inventory
Why It Exists
Even among organisations that have some form of asset register, very few have mapped the personal information flowing through their systems. They know they use a CRM, a payroll platform, and a cloud file store. What they have not documented is what personal data each system holds, where that data is stored geographically, who it is shared with, and under what legal basis.
The Privacy Act 2020, until now, has not demanded this level of specificity. Many organisations have treated privacy compliance as a matter of having a privacy policy on their website and responding to complaints. Proactive data mapping has not been on the radar.
Why It Matters
Information Privacy Principle 3A (IPP 3A), introduced by the Privacy Amendment Act 2025, takes effect on 1 May 2026. It imposes specific obligations on how New Zealand organisations handle the indirect collection of personal information — that is, when you collect someone's data from a third party rather than from the individual directly. Compliance requires organisations to know, in documented detail, what personal data they collect indirectly, from which sources, and whether affected individuals have been notified.
You cannot meet indirect collection notification obligations if you do not know what personal data you hold or where it comes from. A personal data inventory is no longer a best-practice recommendation. It is becoming a regulatory prerequisite.
Beyond compliance, the commercial reality is pressing. Kordia's 2025 report found that 16% of incidents resulted in the compromise of personally identifiable information (Kordia, 2025). If your organisation cannot demonstrate that it knew what personal data it held and took reasonable steps to protect it, the consequences of a breach are significantly worse.
What a Fix Looks Like
A personal data inventory maps each system that collects, stores, or processes personal information. For each system, it documents the categories of personal data involved, the storage location (including whether data crosses borders), the retention period, the legal basis for processing, and any third parties with whom data is shared.
This exercise is time-consuming the first time. But once the inventory exists, maintaining it is straightforward — it becomes part of the process when any new system or vendor is onboarded.
Gap Three: Incident Response Plans That Have Never Been Tested
Why It Exists
Many businesses do have an incident response plan. It was written during an initial compliance effort, or it was included as part of a managed service provider's documentation package, or it was created in response to a client questionnaire. It exists as a document.
The problem is that no one has ever tested it. No practice run. No simulation. No walkthrough where the people named in the plan actually sit in a room and work through a scenario together.
Why It Matters
An untested incident response plan is a hypothesis. It assumes that the contact details are current, that the notification paths make sense, that the people assigned to roles understand their responsibilities, and that the plan accounts for the types of incidents that are actually likely to occur.
Kordia's 2025 findings indicate that approximately 50% of New Zealand organisations have never tested their response plan (Kordia, 2025). This means half the businesses that believe they are prepared have never verified that belief.
When a real incident occurs — a ransomware deployment at 2am, a data breach discovered on a Friday afternoon — the plan either works or it does not. Testing is the only way to find out before the stakes are real.
The organisations that respond well to incidents are not the ones with the longest plans. They are the ones that have practised. They know who calls whom, where the documentation is, and what to do first without reading a thirty-page document under pressure.
What a Fix Looks Like
A practice run exercise does not need to be elaborate. Gather the people named in the incident response plan. Present a realistic scenario. Walk through the plan step by step. Ask: do you know your role? Are the contact details correct? What happens if the primary contact is unavailable?
Document what you learn. Update the plan. Schedule the next exercise. Twice a year is a reasonable cadence. The first exercise will almost certainly reveal gaps — that is the point. Each subsequent exercise closes them.
Gap Four: No Vendor or Third-Party Risk Assessment
Why It Exists
New Zealand businesses are deeply reliant on third-party vendors and cloud services. Payroll, accounting, CRM, email, file storage, project management — the average small and mid-sized business uses dozens of SaaS platforms, each with some degree of access to business data or personal information.
Despite this reliance, many businesses still have no formal process for evaluating vendor security status. The procurement decision is typically driven by features, price, and recommendations. Security is rarely part of the evaluation criteria, and ongoing monitoring of vendor risk is even rarer.
Why It Matters
Kordia's 2025 report found that 19% of cyber incidents in New Zealand were related to a third-party breach (Kordia, 2025). Nearly one in five incidents did not originate inside the affected organisation. They came through a supplier, a service provider, or a platform partner.
This is not a theoretical risk. In November 2022, Wellington-based managed service provider Mercury IT was hit by a LockBit ransomware attack. Because Mercury IT managed infrastructure for government agencies and private businesses, the attack cascaded across dozens of organisations — including the Ministry of Justice, Te Whatu Ora (Health NZ), and health insurer Accuro. Over 14,500 coroners' files and 4,000 post-mortem reports were compromised through a single vendor relationship (SecurityWeek, 2022). None of the affected organisations were attacked directly. Their exposure came entirely through an unassessed third-party risk.
When a payroll provider is breached, your employee data is exposed. When a cloud storage vendor is compromised, your client documents are at risk. The security of your vendors is, in very practical terms, your security.
Without a vendor risk assessment process, organisations cannot make informed decisions about which vendors to trust with sensitive data, what contractual protections to require, or how to respond when a vendor discloses a breach.
What a Fix Looks Like
Vendor risk assessment starts with a register of all third-party vendors that have access to your data or systems. For each vendor, document what data they access, where they store it, and what security commitments they have made (contractually or through published certifications).
For critical vendors — those handling personal data, financial information, or core business systems — conduct a more detailed assessment. Review their security certifications, data processing agreements, incident notification commitments, and breach history. A structured questionnaire and a risk-rated vendor register are enough for most small and mid-sized businesses.
The critical shift is from passive trust to active oversight. You do not need to audit every vendor annually. You do need to know which vendors matter most, what you have agreed to, and what happens when something goes wrong on their end.
Gap Five: Policies That Were Written Once and Never Reviewed
Why It Exists
Many businesses have some policies on file. An acceptable use policy. An information security policy. Perhaps a password policy or a data classification policy. In most cases, these were written at a specific point in time — during a certification effort, to satisfy a client requirement, or as part of an initial security engagement.
The problem is not that the policies are bad. The problem is that they have not been reviewed since they were created. Some reference technology the business no longer uses. Others name people who left years ago. Many do not reflect current regulatory requirements or the business's actual operating practices.
Why It Matters
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 (ASI/NZ research). Having a policy at all is still uncommon, and having one that is current, reviewed, and genuinely used is rarer again.
Policies that do not reflect reality serve no practical purpose. Staff cannot follow a policy that describes systems they do not use or processes that do not exist. Auditors and clients can see when a policy document is stale. And when an incident occurs, a policy that has not been maintained will not support the organisation's response — it may actually undermine it by creating a documented gap between what was supposed to happen and what actually happened.
Kordia's 2025 report also found that 25% of New Zealand organisations cite employee awareness as their top cybersecurity challenge (Kordia, 2025). Policies are the foundation of awareness. If the policies are outdated, the training built on them is outdated.
Additionally, approximately 33% of New Zealand organisations do no board-level reporting on cybersecurity (Kordia, 2025). Without regular policy review and reporting, governance oversight is absent — and security becomes an operational afterthought rather than a strategic responsibility.
What a Fix Looks Like
Every policy should have an owner and a review date. That is the minimum. The owner is the person accountable for ensuring the policy remains current. The review date is the deadline by which the policy must be re-examined and either confirmed as current or updated.
For most small and mid-sized businesses, an annual review cycle is appropriate. The review does not need to be a full rewrite. It needs to confirm that the policy still reflects the technology in use, the people in relevant roles, the regulatory environment, and the organisation's actual practices. Where there are gaps, update the policy. Where a policy is no longer relevant, retire it.
Build the review cycle into your governance calendar. A policy that is reviewed annually and kept to two pages is more valuable than a detailed policy suite that sits in a shared drive collecting dust.
The Common Thread: Governance, Not Technology
A common reaction to this list is surprise — not at the gaps themselves, but at the fact that none of them are about technology. Business leaders expect to hear that they need a better firewall or a new endpoint detection platform. Those tools have their place. But they are not what is missing.
What is missing is governance. Documentation. Process. Oversight. The organisational habits that turn security from a set of products into a set of practices.
An information asset register is governance. A personal data inventory is governance. Testing your incident response plan is governance. Assessing your vendors is governance. Reviewing your policies is governance.
These are not glamorous activities. They do not generate dashboards or produce real-time alerts. But they are the foundation on which every effective security programme is built. Without them, the technology you invest in cannot do its job properly, because no one has defined what it is protecting or who is responsible when it matters.
The organisations with the strongest security positions are not always the ones that spend the most on technology. They are the ones that have built governance habits — small, repeatable processes so that the right people know what the organisation has, how it is protected, and what to do when something goes wrong.
Close the Gaps Before Someone Else Finds Them
These five gaps are common across NZ small and mid-sized businesses. They are the same gaps that lead to breaches, claim denials, and regulatory findings. Closing them does not need to be a six-month project — the highest-risk gaps are usually addressable within the first quarter of a structured programme.
Book a free consultation — find out which of these gaps apply to your business and what it takes to close them.