ManageMyHealth Hack: A failure of standards
The ManageMyHealth breach exposes a system-level failure in how Aotearoa governs health IT security — relying on self-attestation, weak procurement controls, and the absence of enforceable standards.
What happened?
Recently, ManageMyHealth experienced a significant data breach.
The breach allegedly includes:
- 108 GB of sensitive health data
- 400,000+ documents
- between 6 and 7% of ManageMyHealth’s 1.8 million users.
This is probably one of the most severe data breaches that has ever occurred in Aotearoa.
Flexing my ✨ predictive powers ✨ I claimed 6 months ago that ManageMyHealth was insecure:

The more I looked into this issue, the more I noticed how similar it is to the issue of digital accessibility for disabled people. The root cause of accessibility failure is basically the same as the root cause in this security incident.
In this post, I explain my perspective on this data breach, drawing on my experience in accessibility standards and government-wide monitoring systems.
What caused this?
ManageMyHealth’s CEO recently stated the cause of the hack: “They came in through the front door using a valid user password”.
It sounds likely that ManageMyHealth’s lack of mandatory multi-factor authentication is the most direct cause of this breach. I literally warned them of this 6 months ago by tagging them in my LinkedIn post, and they ignored me.
We can’t be 100% certain of this, however, until more details are released.
While the lack of multi-factor authentication is potentially the technical failure that allowed the breach to occur, I think these issues are generally caused by system-level policy failure.
System-level failure
Basically, across Aotearoa, we need to keep our health information system safe, and secure, so our private health information doesn’t end up published on the internet.
If health information ends up on the public internet, it puts us at significant risk of scams, fraud, extortion, mental health issues, the list goes on.
Generally, technical standards are used to provide assurance that systems are secure. Governments have a central role to play to ensure appropriate standards exist for important systems, and to ensure those standards are met.
So, I decided to take a look at what standards and frameworks might apply in this situation.
The main government framework: the HISF
HISO 10029:2022 Health Information Security Framework (HISF) appears to be the most relevant framework/standard in this situation.
Reading through the HISF, I notice some patterns:
- the HISF does not require any specific security-related technical standards
- the HISF does not require periodic third-party security audits at a specified frequency
- the HISF does not establish a centralised security certification system for health IT systems
- nobody appears to be checking if the HISF is being met by any organisation.
The HISF, as a framework, basically places the onus of data security on to the lowest level of health organisations, and there is no oversight by any government body to check that security requirements are being complied with.
This is the exact same compliance model previously used for digital accessibility across government. What is that model? The model, is no compliance checking at all — individual health organisations are expected to mark their own homework.
Side note: luckily, the government now performs quarterly automated accessibility testing across its public facing websites — a system I led the development of.
Procurement — outsourcing of guilt
So, many GPs and PHOs basically forced patients into signing up to ManageMyHealth, or else we’d receive dirty looks and degraded health care services.
When a general practice decides to sign up to an IT system that manages health data, the general practice is responsible under the above HISF for ensuring appropriate security controls and clauses are included in the procurement process.
Again, this is the exact same procurement-based compliance model used across government for digital accessibility, and that has failed spectacularly. Agencies are expected to put accessibility requirements into contracts and procurement processes with suppliers, then the supplier is on the hook for meeting accessibility requirements. I wonder how that turned out? (spoiler: not well).
This strategy requiring procurement clauses has three main problems:
- GPs and PHOs will forget to add security-related clauses in procurement documents and contracts, and nobody will detect this failure
- Buyers of health IT systems might ask for the right security evidence, but they can’t interpret it correctly, and make incorrect decisions as a result
- Health IT suppliers can theoretically make claims to potential clients that it’s secure, while actually being completely insecure under-the-hood. The only way to tell is with third-party audit data.
Basically, there are huge risks in expecting individual GPs and PHOs to know how to procure secure software and cloud services. Most of them probably never even considered data security when they signed up to ManageMyHealth. And secondly, there’s risks that consumers of health IT systems get bamboozled during the procurement process, unless clear, concrete third-party audit data is available to prove conformance to security standards.
But even where clear third-party audit data is available, will your average GP or PHO understand what it means? I doubt it.
ISO 27001
ISO 27001 is an information security standard — it has requirements that make organisations create, and maintain an information security management system.
ISO 27001 is one of the most widely-used formal information security standards, used by organisations that face high levels of risk due to the nature of information they hold. It’s used in situations where trust and assurance of safety really matters, like banks, insurance companies, etc.
To me, it seems reasonable to expect all large-scale digital health organisations to comply with this standard, and receive some sort of certification.
I don’t believe it’s practical for each individual GP to meet this standard — but, for large-scale Software-as-a-Service companies like ManageMyHealth, it seems like an obvious requirement to implement. If ManageMyHealth is breached, it impacts a significant portion of New Zealanders, so we should expect some kind of minimum standard to be met — that feels reasonable, right?
I performed a quick search of ManageMyHealth’s website, and its own security page does not mention any kind of ISO 27001 compliance, nor does it mention having an information security management system.
Instead, the ManageMyHealth website appears to brag about using a TLS certificate from GoDaddy, which… is an embarrassing thing to say out loud.
At the time of writing, the security page of ManageMyHealth is utterly scary. The security page provides no competent description of how data security is actually managed within the organisation, or its platforms.
If I were a GP looking to buy a patient portal, that security page would have sent me running for the hills. But instead, hundreds of GPs got their wallets out and paid for this service.
The HISF requires ISO 27001, right? …right?!
No. I’ve done extensive research (actually… a trusty Cmd + F search) and I only found ISO 27001 mentioned in the footnotes of the HISF.
The HISF’s associated guidance documents do make more direct mentions of ISO 27001 (among other standards/certifications), however it does not make such a standard a mandatory, clear requirement. It’s all just hand-wavy mentions, rather than strict compliance requirements.
The HISF doesn’t make any direct requirement for large-scale health IT suppliers, like ManageMyHealth, to comply with any specific security management standards.
Whoopsies.
The HISF is completely absurd: a health IT supplier could objectively fail every single aspect of the HISF and still be perfectly eligible to handle all of NZ’s health data. The HISF does not establish any enforceable minimum.
This is where government actually manages accessibility in a much better way: for accessibility, the government clearly specifies a mandatory technical standard to meet. But, for health security, the government has failed to specify any reasonable minimum technical security standard for health IT companies.
What is the result? Well, without the government clearly mandating minimum security standards, you’re left with a bunch of hand-wavy crap where it’s impossible to actually tell if a standard is being implemented or not — it’s all opinion.
What about the Health Information Privacy Code 2020?
So, the Office of the Privacy Commissioner publishes the Health Information Privacy Code (HIPC).
The HIPC claims to actually override the Information Privacy Principles (IPPs) in the Privacy Act 2020, which is an interesting factoid I did not know.
So, does the HIPC set a clear, measurable, objective standard for data security when procuring health software?
Rule 5(1) states…
A health agency that holds health information must ensure… that the information is protected, by such security safeguards as are reasonable in the circumstances to take.
Health Information Privacy Code 2020, Rule 5(1)(a)
So… an agency just has ensure that information is protected by reasonable safeguards.
Who determines what is reasonable?
Well, there’s your problem. Nobody seems to be clearly defining what is reasonable.
Accountability sinks
Basically, if basic minimum standards are not made clearly mandatory by the government, and instead we rely on fuzzy words like “reasonable”, we have no way to understand if any system is good enough. Then, when something fails, you blame the company associated with that IT product — then the cycle repeats itself in 3 months’ time.
This approach creates an “accountability sink” — a place where accountability disappears because the accountability line flows in the wrong direction. Accountability sinks are a common design element within bureaucracy.
One classic way to achieve an “accountability sink” is for a bureaucratic system to effectively play the UNO reverse card — ensure the system is designed to push responsibility and blame downwards towards the lowest levels of the system.
This means the media spends its time attacking GPs and ManageMyHealth, rather than coming to the realisation that the government’s health security framework has effectively no monitoring or assurance system.
The government can simply create blurry frameworks for security that vaguely use all the right buzzwords, while pushing all responsibility for implementing those frameworks downwards. Meanwhile, the government can make no attempt to centrally monitor compliance with that framework — because ignorance is bliss. There’s no crisis if you never look at it, right?
So when the shit hits the fan, the blame never lands in the right place. We punish the instance of the problem, not the cause.
It’s doomed to repeat.
Where does this leave us?
Well, in my view, it’s not right to blame the doctors, ManageMyHealth, or the hackers that caused this breach.
We should blame the system-level design flaws that allow these catastrophes to occur in the first place.
My view, is that security standards for health information in Aotearoa are not strong enough. And, any security framework that lacks a strong independent auditor is doomed to fail.
We should have:
- clearly-defined and enforced information security management standards for all health software
- a minimum set of specific technical security controls for all health IT software (i.e. multi-factor authentication)
- a centralised authority responsible for security accreditation and annual audits of all systems that hold health data, particularly cloud-based platforms.
The current approach under the HISF will not work — I’m confident of this, because I’ve seen this failure play out in the accessibility field over 2 decades.
Unless the government implements a strong, drastic change to health data protections, this ManageMyHealth data breach won’t be the last — it’ll just be the beginning.
— Callum