Outsourcing a system does not outsource the risk.

"We outsourced that system, so it is their problem now."

This is one of the most expensive assumptions in business. It comes up regularly in security conversations, and it is almost always wrong.

Outsourcing is a delivery model. It is not a risk transfer.

What happened with ManageMyHealth

In December 2025, ManageMyHealth, New Zealand's largest patient-facing health portal with over 1.8 million registered users, was breached. Sensitive medical documents relating to more than 120,000 patients were taken.

The platform was the vendor. GP practices and health providers across New Zealand had outsourced their patient data management to it. When the breach happened, those practices were the ones with the client relationships, the professional obligations, and the reputational consequences. The vendor managed the system. The health providers owned the risk.

This is not unique to the health sector. The same dynamic plays out whenever an organisation moves data or a critical process to a third party and assumes the risk goes with it.

Why this matters more than it used to

Most organisations have outsourced more than they realise. Cloud services. SaaS tools. Managed IT support. Third-party platforms. Each one is a dependency. Each dependency is a risk you are still carrying, whether you have mapped it or not.

The threat environment has also changed. In 2022, the average time between an attacker gaining access to a system and achieving full control was around 8 hours. By 2025, that had dropped to 22 seconds. Attackers are faster, more automated, and increasingly targeting vendors specifically because they provide access to many downstream clients at once.

A breach at a vendor is not just a vendor problem. It is an event that affects every organisation whose data that vendor holds.

The question you should be asking

The question most organisations ask about outsourced systems is: "who manages this?" The question they should be asking is: "what happens to us if this fails, and would we know about it fast enough to do something?"

If you cannot answer that, you do not have a risk transfer. You have a gap.

Specifically, you should be asking:

• What data does this vendor hold on behalf of our organisation?
• What are our contractual rights if they are breached?
• How quickly are they required to notify us of a security incident?
• Have we reviewed their security practices, or are we taking their word for it?
• Do we have an incident response plan that covers third-party breaches, not just internal ones?

What good looks like

Good third-party risk management does not mean auditing every vendor to enterprise standards. That is not practical for most NZ SMBs. It means having a clear view of which vendors hold what data, which ones represent meaningful risk if they fail, and having basic contractual protections in place for those relationships.

For the most critical vendors, it means asking questions about their security posture before you sign up, not after something goes wrong.

And it means including third-party breach scenarios in your incident response planning, so that if it does happen, your team knows what to do rather than finding out your vendor has been breached the same way your patients or clients do.