Buried in the reporting on the ZenTech ransomware attack is a sentence that deserves more attention than the breach itself. The Ministry of Justice confirmed that Coroners Court information was captured in the attack on the Dunedin IT firm — and said it is working with Health New Zealand and police to determine how the information came to be held by ZenTech, and what it contains.
Read that again. Months after the attack, the organisations responsible for some of the most sensitive records in the country are still reconstructing which of their data a supplier held, and why.
Before any schadenfreude: this is not a government-incompetence story. It is the single most common finding in supplier breaches everywhere, and if a breach hit one of your suppliers tomorrow, there is a very good chance you would be in the same position. The honest name for it is data sprawl.
How data sprawl happens — innocently, every time
Nobody decides to lose track of their data. It happens through perfectly reasonable steps:
- A supplier needs a dataset for a legitimate project; the project ends; the dataset stays
- A one-off export becomes a recurring feed because it was easier than asking again
- A subcontractor gets access through the main contractor, invisibly to you
- A migration leaves a copy in the old system "just in case"
- Staff email spreadsheets to a vendor because the official channel was slow
Each step is defensible. The sum is an organisation whose sensitive data lives in places no current staff member can enumerate — which means its breach-notification duties under the Privacy Act 2020 cannot be met accurately, its supplier security questions are aimed at the wrong vendors, and its incident response starts with archaeology instead of action. We watched the same dynamic in September's supplier-claim incident: the painful step was never the response itself, it was discovering what the supplier held.
The test: can you answer these three questions in an hour?
- Which external parties hold personal information you are responsible for? Not your contract list — your DATA list. Include the supplier's subcontractors if you can (you usually cannot, which is itself a finding).
- For your three most sensitive data categories, where does every copy live? Health information, financial details, children's data, anything coronial-adjacent: these deserve copy-level tracking.
- If a named supplier was breached tonight, could you tell affected people what was exposed — specifically? "We believe some information may have been affected" is what organisations say when the answer is no. The families in the ZenTech case are living downstream of that sentence.
If any answer is no, the fix is not software. It is an afternoon with a spreadsheet: data category, where it lives, who holds it, why, since when, and when it should be deleted. Privacy people call it a records-of-processing register; call it a data map and it gets done faster.
Deletion is the forgotten security control
The cheapest data to protect is data that no longer exists. Most supplier-held data in breaches turns out to be stale — old projects, former clients, expired retention purposes. A standing clause in supplier contracts (return or destroy on project end, certified) plus an annual "what do you still hold of ours?" email would have shrunk many of NZ's worst breaches, including the pattern we traced in lessons from recent NZ breaches.
The people layer, as always
A data map goes stale the day staff resume emailing exports to vendors. The durable version is cultural: staff who understand that every copy they create is a copy someone must protect, and that "where data goes" is a security decision, not an admin one. That awareness is trainable — it is module-one material in Privacy Act staff training.
Map what you hold. Delete what you should. Train the people who move the data daily. SecureAZ handles the third one for NZ and Australian teams — free for 45 days.