What the Manage My Health findings mean for anyone holding sensitive data
The Privacy Commissioner found both the portal operator and Health NZ fell short. The lessons apply well beyond health, to any organisation that relies on a supplier or holds information people would hate to see leaked.
- Published
- Written by
- Faraday
- Sources
- 4 cited
In December 2025, attackers stole health information from the Manage My Health patient portal, used by general practices across the country. Manage My Health notified the Privacy Commissioner on 1 January 2026. Media reported that the records of nearly 100,000 patients were taken, making it one of the most damaging health data breaches in New Zealand’s history.
The Commissioner opened a formal inquiry in January and released the findings of its first phase in late May 2026. Phase one looked at what caused the breach and who was accountable. Phase two, still under way, looks at the impact, including the quality of communications and whether the breach affected some groups disproportionately, particularly Northland Māori.
What the Commissioner found
- The breach wasn’t the result of a single failure. The Commissioner found Manage My Health failed to have reasonable security safeguards in place, breaching rule 5 of the Health Information Privacy Code (the health equivalent of IPP 5), and said it intends to issue a compliance notice.
- Health NZ also breached rule 5. The Commissioner found serious problems with the quality of privacy risk assessments in Health NZ’s involvement, while noting things improved in later stages and the findings are largely historic. It also intends to issue Health NZ with a compliance notice.
- Warnings went unheeded. Reporting on the findings said Manage My Health had been warned about security flaws that contributed to the breach.
- Notifications fell short. Patient notifications were described as often confused, overly optimistic and inaccurate.
Five lessons for everyone else
1. Treat security findings as debts with due dates. If a penetration test, audit or staff member tells you about a weakness, record it, give it an owner and a deadline, and report progress to leadership until it’s fixed. A list of known, unfixed issues is the worst document to have in your files after a breach.
2. Expect layered failures. Breaches rarely come from one mistake. They come from several small gaps lining up, such as an unpatched system, weak monitoring and one account without multi-factor authentication. Defence in depth means any single gap shouldn’t be enough.
3. Commissioning a supplier doesn’t hand over your responsibility. Health NZ wasn’t running the portal, and it was still found in breach because of the quality of its own risk assessment. If you contract out a system that holds sensitive information, the regulator will look at what you assessed, what you required in the contract, and how you checked. Our supplier questionnaire is a starting point.
4. Write breach notices people can act on. Say exactly what was taken, what you know and don’t know, and what people should do. Don’t promise there’s no risk. Don’t say there’s “no evidence of misuse” unless you’ve looked properly. People forgive bad news far more readily than spin that turns out to be wrong. Our breach response plan includes a notice checklist.
5. Think about who is hit hardest. The Commissioner is examining whether one community bore more of the harm. When you assess a breach, ask how it lands for the most vulnerable people affected, and whether a particular community needs a different response.
The wider signal
This was the Commissioner using its inquiry and compliance notice powers on a high-profile breach, and finding fault with a large public body as well as a private supplier. Organisations that hold sensitive information should expect the same scrutiny of their own security and supplier arrangements.
A good first step is our privacy self-check, which covers security, breach readiness and risk assessment against the Commissioner’s own Poupou Matatapu.
Sources
Something wrong or out of date? Tell us or edit this page on GitHub. General information, not legal advice.