As healthcare organisations become increasingly reliant on third-party technology providers for clinical software, cloud infrastructure and data exchange, questions have been raised about how effectively the sector is managing cybersecurity risks across its digital supply chains – especially in light of the 2024 MediSecure data breach.
Paul Chua.
Paul Chua, Asia Pacific operations director at healthcare cybersecurity information-sharing organisation Health-ISAC, says Australian healthcare providers need to look beyond conventional supplier assessments and place greater emphasis on data protection, financial resilience and the ability to maintain clinical services when technology vendors fail.
In this Q+A with Pulse+IT, Mr Chua discusses the vulnerabilities in Australia’s digital health infrastructure, gaps in existing cybersecurity and privacy regulations, and the practical steps healthcare organisations and technology suppliers should take to strengthen resilience.
What does 2024’s MediSecure breach reveal about the systemic risks associated with healthcare organisations relying on third-party technology providers, particularly those handling large volumes of sensitive patient information?
MediSecure was not a hospital, a GP clinic or a pharmacy. It was a prescription exchange, one of two companies that moved electronic scripts between prescribers and dispensers in Australia. By the time its ransomware incident became public in May 2024, it had already lost the national Prescription Delivery Service contract to its competitor eRx and with it most of its revenue. The data it still held, roughly 6.5 terabytes covering scripts up to November 2023, was lifted anyway. MediSecure later said the number of people affected was likely to exceed 12.9 million. The stolen records included names, dates of birth, addresses, Medicare numbers and expiry dates, and the medications, dosages and reasons for prescribing.
The company asked the federal government for money to keep operating through the response. The request was declined. On 3 June 2024 MediSecure entered voluntary administration, and by July its operating subsidiary was in liquidation. In its 18 July 2024 statement the company said it could not identify which individuals were affected and was not in a financial position to pay for the work that would have told it. Nobody got a letter. In September 2024 the Office of the Australian Information Commissioner (OAIC) closed its inquiries without investigating, on the grounds that the remedies available would not be proportionate to the resources an investigation would need.
No prescription stopped flowing. The National Cyber Security Coordinator was able to say that the current national prescription delivery service was not affected, because the service had already moved to eRx. That is the uncomfortable part. The sector got lucky on continuity and unlucky on data, and the two outcomes came from the same fact: a supplier that had lost its contract but not its data.
So what did it reveal? Three things I keep coming back to. The data a supplier holds does not shrink when the contract ends. The capacity of a supplier to respond to a breach is a function of its balance sheet, and a balance sheet can go to zero in weeks. And when a supplier fails, the obligations to patients do not transfer to anyone in particular. Each of the questions below is really a version of one of those.
MediSecure entered voluntary administration following the cyberattack. What happens when a critical digital health supplier suffers a major breach but lacks the financial or technical resources to recover, and who is responsible for ensuring continuity of services and protecting patient data?
When a supplier goes into administration mid-incident, the incident does not stop. The response does. The National Office of Cyber Security’s own evaluation of the MediSecure response, published in December 2025, says administration restricted the use of company funds for incident management, forensics and scoping. It records that the request for government funding was denied and adds a line worth reading twice: “similar arrangements cannot be relied upon by government for future incidents.” The forensic work that did happen was done by eDiscovery specialists engaged through MediSecure’s lawyers because, outside law enforcement, no agency had both the legal authority and the technical capability to analyse the stolen dataset.
The evaluation also found there was no established process for how affected individuals should be notified by a company entering administration, and no defined government role in doing it. So the government built a public advice page instead, partly because MediSecure could not afford to fund support services for the people whose records it had lost. An administrator’s duty runs to creditors. Patients are not creditors.
Continuity was a different story, and the reason is instructive. By the time of the breach, the Department of Health and Aged Care had already moved the national Prescription Delivery Service to eRx (Fred IT won that contract in May 2023, with the new arrangements starting 1 July 2023). MediSecure had been contracted briefly to help transition its data and prescriptions across and then had no direct system connections. Continuity was protected by a procurement decision made for other reasons, which is not the same as designing for it.
So who is responsible? In law, several parties at once and therefore, in practice, nobody in particular. MediSecure was an APP entity under the Privacy Act and had notifiable data breach obligations, but it was not a critical infrastructure entity under the SOCI Act, so there was no 72-hour reporting duty to cyber.gov.au and no risk management program for a regulator to have checked. The practices and pharmacies whose patients’ data flowed through it had their own APP 11 obligations, but almost none of them chose MediSecure directly. It came bundled with their clinical software or with a government-funded service.
My view is that responsibility for continuity and for patient data should sit with whoever commissioned the data flow. For a national service, that is the Department. For a hospital’s pathology middleware or cloud host, it is the hospital. That party should contract for three things in advance: a funded response (cyber insurance or a retainer with a named incident response firm, so the money exists when the balance sheet does not), the return or certified destruction of data when the contract ends, and a step-in right that lets the commissioning party or its nominee take custody of the data and the notification process if the supplier becomes insolvent. The UK’s Synnovis incident in June 2024 shows the alternative. Synnovis stayed solvent, but it still took about 18 months to tell the hundreds of NHS organisations it served whether their patients were affected, and King’s College Hospital confirmed in June 2025 that the disruption contributed to a patient’s death. Solvency bought time, and even then it did not settle who owed what to whom.
Healthcare organisations increasingly depend on external vendors for clinical software, cloud infrastructure, interoperability and data exchange. How effectively are Australian healthcare providers assessing the cybersecurity risks associated with these suppliers?
Unevenly, and mostly at the wrong point in the chain. The large public health services have procurement security schedules, questionnaires and, in some states, a mandated policy baseline. The primary care end of the sector, where most of the MediSecure data originated, generally has none of that. A GP practice does not run a supplier assessment on its prescription exchange. It chooses a practice management system, and the exchange comes with it. The assessment, if one happened, was done by the software vendor or by the Department that funded the service. The practice inherits the risk without ever seeing the questionnaire.
The audit evidence on the hospital side is not flattering either. The Audit Office of NSW’s report on cyber security in Local Health Districts, made public on 19 December 2025, found that none of the four districts it examined (out of 15) had met the state’s minimum cyber security requirements since 2019, none had a fit-for-purpose incident response plan, and clinical staff regularly did not comply with controls because of a perceived tension between clinical urgency and policy. The report said eHealth NSW had not clearly defined its role relative to the districts. If roles are unclear inside one state health system, the odds that supplier risk is being assessed consistently across it are low. Victoria’s Auditor-General reached similar conclusions about hospital data security back in 2019, which tells you how fast this moves.
The national breach statistics point the same way. The OAIC recorded 1,205 notifiable data breaches in 2025, the highest number since the scheme began, and health service providers again reported the most of any sector at 225, or 19 per cent. The OAIC’s figures do not break out how many of those came through a supplier rather than the provider’s own systems, which is itself part of the problem. If a sector cannot see what share of its breaches arrive through vendors, it is not measuring vendor risk.
The December 2025 evaluation of the MediSecure response adds the observation I think matters most. One of its insights is that even small organisations can hold substantial volumes of sensitive data: MediSecure had a small staff and budget and held prescription data on 12.9 million people. Most supplier tiering models weight suppliers by spend. A low-spend supplier with a national dataset scores as low risk on a spreadsheet but becomes the biggest breach in Australian health on the news. The honest answer to this question is that Australian providers assess the suppliers they pay a lot of money to, at the moment of signing, using self-attestation. That covers the wrong suppliers, at the wrong time, with the wrong evidence.
What specific cybersecurity requirements should hospitals, primary care providers and government health agencies impose on technology vendors before entering into contracts, and how should compliance be monitored throughout the relationship?
For a hospital, a primary care network or a government health agency, I would put the following in every contract where the vendor touches patient data or a clinical workflow.
For security posture, require multifactor authentication on every remote access path the vendor operates, with no exceptions for legacy portals. Change Healthcare, the largest health breach in United States history at around 190 million people, started with a Citrix remote access service that had no MFA. Essential Eight maturity at a level the buyer names, with evidence rather than a tick box. Independent assurance (SOC 2 Type II or ISO 27001) with the scope statement attached, because a certificate that covers the vendor’s corporate office and not the platform holding your data is decoration.
For data, require a written statement of what the vendor holds, why, and for how long. A retention schedule tied to the clinical or legal purpose, not to the life of the company. Return or certified destruction within a fixed period after termination, with the right to verify. This is the MediSecure clause. The company had data back to March 2019 and had been out of the national service since 2023.
For incidents, require a contractual definition of a security incident, notice to the buyer within 24 hours of the vendor becoming aware (shorter for anything affecting availability of a clinical service), a root cause report within 30 days, cooperation with the buyer’s own notification obligations, and disclosure of any ransomware payment, which the vendor must now report to the government within 72 hours under the Cyber Security Act 2024 anyway. Flow-down of all of the above to subcontractors, and a current list of who those subcontractors are.
For viability, require evidence of cyber insurance or a funded incident response retainer, a right to be told about material changes in ownership, financial condition or loss of a major contract, and a step-in or data custody arrangement if the vendor becomes insolvent. A vendor that will not agree to this is telling you something about its balance sheet.
Monitoring is where most programs quietly fail. Signing a schedule and filing it is not monitoring. For the top tier of suppliers, I would expect an annual reassessment with fresh evidence, a quarterly look at a handful of indicators the vendor reports (patch latency, open findings, privileged accounts, incidents), external attack surface monitoring of the vendor’s public footprint, and a joint exercise at least once in the contract term with the vendor’s responders in the room. The HSCC’s supply chain guide for the health sector (HIC-SCRiM) treats a vendor’s refusal to take part in a tabletop as a risk in its own right. I agree. The one trigger I would add to every program, because it is the one MediSecure teaches, is a reassessment whenever a supplier loses a major contract or changes hands. Financial distress is a security event and should be handled as one.
How can healthcare organisations identify concentrations of risk where multiple clinical services, software platforms or providers depend on the same technology supplier? What practical steps can they take to reduce the potential impact of a single vendor failure?
Concentration hides because the inventory is organised by contract and the dependency is organised by function. Three different departments can buy three different products that all run on the same vendor’s cloud tenancy, or all route through the same integration engine, and nobody sees it until the engine stops. The first practical step is therefore boring: build one supplier inventory from accounts payable, the contracts register and the IT asset list, and then map it the other way, from clinical function to the systems it needs to the suppliers behind each system, including the suppliers’ own suppliers where you can find out. The map is the deliverable. It is where “same vendor, four products” and “same hosting provider under two competing vendors” become visible.
The second step is to score suppliers by what breaks if they fail, not by what you pay them. A useful test for each clinical function is to ask what the maximum tolerable outage is, what the manual fallback is, and how long the fallback can run before harm. CPS 230 calls these tolerance levels. Pathology, imaging, medication management, patient identification and bed management usually fall out as the functions with the shortest tolerances, and the suppliers behind them are your real tier one whether or not procurement has them there.
Some concentration sits above any single organisation and no hospital can map it alone. Australia now runs a single national Prescription Delivery Service through eRx. MediSecure’s failure did not touch it because MediSecure had already left. The next failure of an exchange will not have that luck, because there is no longer a second exchange. The same is true of a small number of practice management systems, pathology and radiology IT vendors, and the handful of remote access appliance brands the whole sector uses. The United States learned this at scale with Change Healthcare, which handled roughly 15 billion transactions a year and touched about one in three patient records; its parent company ended up advancing around $9 billion in interest-free loans to keep providers solvent while claims could not be processed. That is what a national single point of failure costs when the parent has a balance sheet. Australia’s digital health intermediaries mostly do not.
Reducing the impact is a mix of cheap and expensive measures – and the trick is to be honest about which is which. The cheap ones: keep a tested manual fallback for every short-tolerance function (paper prescriptions remained legal throughout the MediSecure incident, which is the main reason it was a data breach and not a clinical outage); hold a local copy or cache of the recent records you need to keep treating for 72 hours; make sure the vendor’s disaster recovery is tested and that you have seen the result; agree in advance who can authorise disconnecting a vendor and how fast. The expensive ones: a second supplier for a function where one exists, data escrow or a sovereign standby for a function where it does not, and, at sector level, treating the national services as critical infrastructure with the resilience obligations that come with the label. The independent review of the SOCI Act, delivered to the Minister on 2 February 2026, recommends reconsidering how the healthcare and medical sector is defined and which assets within it are critical. That is the right conversation to be having and the Prescription Delivery Service belongs in it.
When a major digital health supplier is compromised, what technical safeguards and contingency arrangements should be in place to prevent the incident from disrupting clinical systems, electronic prescribing, patient records or other essential healthcare services?
The design goal is that a compromised supplier can be cut off without cutting off care. That breaks into two problems: containing the supplier’s access into your environment, and keeping clinical work going while the supplier’s service is down.
On containment, every vendor connection should be a known, named, segmented path with the least privilege the integration actually needs, and it should be possible to disable it in minutes without a change board. That means vendor VPN and remote support accounts in their own groups, API access through a gateway you control rather than a shared service account, and credentials that can be rotated on demand. HIC-SCRiM lists suspending vendor remote access, rotating credentials and raising mail filtering as the standard first moves when a supplier reports an incident. If you cannot do those within an hour, the supplier’s incident becomes yours. Logging on those paths matters more than almost anywhere else in the estate, because when the vendor’s own forensics are slow (Synnovis took about 18 months to work out whose data it had lost and never established how the attackers got in), your own logs are the only timely evidence of what reached you.
On continuity, the arrangements that worked in the incidents we have seen are unglamorous. Paper and downtime procedures that staff have practised recently, not laminated once in 2019. For electronic prescribing specifically, the ability to fall back to paper or printed tokens and to keep dispensing from the information the pharmacy already holds. For records, a local read-only copy or cache of recent results and medication lists that clinicians can reach when the vendor platform is unavailable, refreshed often enough to matter and segregated enough not to inherit the vendor’s compromise. For pathology and imaging, a pre-agreed arrangement with an alternate provider and the referral and transport logistics to use it, which is the part Synnovis showed is hardest to improvise. Immutable, tested backups of anything the vendor hosts on your behalf, held somewhere the vendor cannot reach.
Two arrangements sit between the technical and the contractual and tend to get missed. The first is a pre-agreed decision right: who in the organisation can order the vendor disconnected, on what evidence, and who tells the clinical directors. In an incident the delay is rarely technical. The second is out-of-band communication with the vendor and with peer organisations, because the vendor’s own systems and mail may be down or untrusted. Sector sharing channels exist for exactly this moment, and the government’s MediSecure evaluation noted that informal networks between responders carried much of the useful information and should be formalised.
None of this stops the data loss. If the supplier already holds 6.5 terabytes of your patients’ records, segmentation on your side does nothing for the copy on theirs. That is why the data clauses in the previous section and the retention duty discussed in the next are the safeguards that would have changed the MediSecure outcome, and the technical measures here are what keep a future supplier compromise from also becoming a clinical one.
Are Australia’s existing cybersecurity, privacy and digital health regulatory frameworks sufficient to manage third-party supplier risk? What additional obligations, particularly around incident reporting, data protection and business continuity, should be considered?
Three regimes touch a digital health supplier in Australia – and each has a gap that MediSecure fell through.
The Privacy Act applies to the supplier directly, and the first tranche of reforms, in force from 11 December 2024, made APP 11 say what it should always have said: reasonable steps to secure personal information include technical and organisational measures. The statutory tort for serious invasions of privacy followed by 10 June 2025. What the Act still lacks is any teeth on retention. The second tranche, released as an exposure draft (the Privacy Amendment (Personal Data Protection) Bill 2026) on 31 August 2026, would require entities to identify what they hold, consider whether it is still needed and destroy or de-identify it, and would move breach notification to the OAIC to 72 hours from reasonable grounds. Consultation closed on 18 September 2026. Until it passes, the obligation that would have forced MediSecure to delete four years of prescriptions after it left the national service does not exist in enforceable form. The OAIC’s decision not to investigate MediSecure also showed the limit of a regulator whose main remedy is a penalty against a company with no money.
The SOCI Act does not apply to a prescription exchange at all. In the healthcare and medical sector it reaches critical hospitals with a general intensive care unit, and the risk management program obligation reaches only the designated hospitals listed in the rules. The government’s own evaluation records that MediSecure, as a non-SOCI entity, had no 72-hour incident reporting obligation. Hospitals that are covered must notify their data storage and processing providers, and supply chain is one of the four hazard domains in a risk management program, but the obligation sits on the hospital, not the supplier. The independent review of the Act delivered in February 2026 heard two models for supply chain, one placing legal responsibility on suppliers and one leaving it with operators, and suggested a middle path: minimum supplier security obligations under the Act plus consistent contract templates. It also recommended reconsidering how the health sector is defined. I do not know yet how the government has responded to those recommendations.
The Cyber Security Act 2024 added ransomware payment reporting from 30 May 2025 for businesses above $3 million turnover, with a limited use protection that makes it safer to talk to government. That helps the national picture. It does not help a hospital find out that its vendor was hit, because the report goes to ASD, not to the vendor’s customers.
What is missing, then, is a regime for the suppliers themselves. I would propose four additions. First, designate national digital health infrastructure (the Prescription Delivery Service, the systems connected to My Health Record, and the large clinical software, pathology and radiology platforms) as critical infrastructure, so the operators carry registration, incident reporting and risk management duties directly. Second, a health sector equivalent of CPS 230: material service provider registers, tolerance levels for critical clinical operations, 24-hour notification of disruptions and 72-hour notification of material incidents, and board accountability, applied to hospitals and large providers and flowed down by contract. Third, a retention duty for health intermediaries that is not optional, with a hard requirement to return or destroy data within a fixed period after a contract ends. Fourth, a policy for insolvent suppliers: who takes custody of the data, who funds the forensics and notification, and whether that is paid for by mandatory insurance, a levy or the Commonwealth. The evaluation report identifies this as an open question. Nearly two and a half years after the breach, it should be a settled one.
What are the most important lessons Australian healthcare organisations and digital health vendors should take from the MediSecure incident, and what practical changes should they prioritise over the next 12 months to strengthen resilience across the sector?
The lessons I would like readers to take away are short.
A contract ending is not the data ending. MediSecure left the national service in 2023 and was breached in 2024 holding records back to 2019. Every supplier exit should end with a destruction certificate, and every current supplier should be able to tell you today what they still hold from contracts that finished.
Supplier solvency is a security control. A vendor that cannot fund forensics, legal advice and notification will not do them, and the law as it stands will not make anyone else do them either. Ask about insurance and retainers the way you ask about MFA.
“Isolated” is a statement about systems, not about harm. The Coordinator was right that the incident did not spread to other systems. It still reached 12.9 million people, none of whom were told individually.
The sector was a bystander to its own breach. Practices, pharmacies and patients had no relationship with MediSecure they could act on. Whoever commissions a data flow on behalf of others has to own the response when it fails.
Paper worked. The clinical outage never happened because a fallback existed that nobody had to invent on the day. Keep it, and practise it.
For health providers, the next 12 months should go roughly like this. In the first quarter, build the single supplier inventory and the function-to-supplier map, and tier by clinical impact rather than spend. In the second, renegotiate or amend the top ten contracts for data retention and destruction, 24-hour incident notice, subcontractor disclosure, insurance evidence and step-in on insolvency, and verify MFA on every vendor remote access path while the lawyers work. In the third, set tolerance levels for the short-tolerance clinical functions and confirm a manual fallback exists for each, then run one supplier-failure exercise with the vendor’s responders present. In the fourth, stand up the monitoring: annual reassessment dates, quarterly indicators from tier one vendors, and a standing trigger to reassess any supplier that loses a major contract or changes owners.
For digital health vendors, the list is shorter and less comfortable. Delete what you no longer need, and be able to prove it. Fund your own response in advance, through insurance or a retainer, and tell your customers you have done so. Put MFA on everything that faces the internet, including the portal you forgot about. Write down what happens to the data if the company fails, and put it in the contract before a customer asks. Join the sector’s information sharing arrangements so that when something happens, you are not relying on a LinkedIn message to reach the hospitals that depend on you.
For government, the asks are the ones already on the table: respond to the SOCI review’s recommendation on the health sector, pass the retention and 72-hour notification provisions in the second privacy tranche, and settle the policy for insolvent suppliers that the December 2025 evaluation left open. MediSecure gave the country a near miss on continuity and a direct hit on data. The second of those is still unresolved for the people in the dataset, and the first was luck.
This article is based on answers provided by Paul Chua, Asia Pacific operations director at healthcare cybersecurity information-sharing organisation Health-ISAC, and reflects his analysis and views.
Add Comment