Offshore developers and Australian health data: APP 8 cross-border disclosure explained

Yes, offshore developers can work on software that holds Australian health information, but the APP 8 cross-border disclosure rules decide how. Before you disclose personal information to an overseas recipient, you must take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles (APPs), and under section 16C of the Privacy Act you are generally accountable if it does. The practical answer is to design your systems so offshore engineers rarely, if ever, need to see real health information.

We are writing this as an offshore team: Inventure's engineers are in Nepal, and we have no Australian office. Read it as the view of a vendor who has to answer these questions, not as a neutral legal opinion. This article is general information, not legal advice. For the wider picture, see our guide to healthcare software development in Australia.

What APP 8 cross-border disclosure requires#

The OAIC's APP 8 guidelines set out three ideas that matter for software projects.

• Reasonable steps before disclosure. Before you disclose personal information to an overseas recipient, you must take reasonable steps to ensure the recipient does not breach the APPs. The OAIC generally expects an enforceable contract requiring the recipient to handle the information in line with the APPs.
• Accountability under section 16C. If you disclose to an overseas recipient, you are generally accountable for any act or practice of that recipient that would breach the APPs. Their breach is treated as yours.
• Reasonableness depends on the data. What counts as reasonable depends on factors such as the sensitivity of the information, the potential harm and the safeguards already in place. Health information is sensitive information, so expect the bar to be high.

According to the OAIC, contracts typically cover the kinds of information and the purpose of disclosure, the requirement to follow the APPs (including for subcontractors), complaint handling, and data breach notification and response.

Use or disclosure? Why remote access matters#

APP 8 applies to disclosures, not every movement of data, so the line between "use" and "disclosure" matters.

The OAIC says an organisation discloses personal information when it makes it accessible to others outside the organisation and releases the subsequent handling of that information from its effective control. Some points from the guidelines:

• Routing is usually a use. Sending information through servers outside Australia while it is in transit would usually be considered a use. There is generally no disclosure until an overseas recipient is able to access or modify it.
• Cloud storage can be a use. Giving information to a cloud provider only to store and manage it may be a use where a binding contract limits the provider to those purposes, subcontractors must accept the same obligations, and you keep effective control, such as rights to access, retrieve and delete the data.
• Your own overseas office is not a disclosure; a related company is. Sending information to an overseas office of the same organisation does not engage APP 8, but sending it to a related body corporate overseas does.

Now apply that to a development team. Engineers who can query production databases, read support tickets that contain care notes, or restore backups to their own machines are doing much more than storing data for you. Unless the facts clearly show you keep effective control, plan as if APP 8 applies, and ask your lawyer to confirm how it applies to your arrangement.

The APP 8.2 exceptions, briefly#

APP 8.1 does not apply in some situations. At a high level, the exceptions cover disclosures where:

• the recipient is subject to a law or binding scheme substantially similar to the APPs, with mechanisms individuals can use to enforce it;
• the recipient is subject to the laws of a country, or takes part in a binding scheme, prescribed by regulations;
• the individual consents after being expressly told that APP 8.1 will not apply;
• the disclosure is required or authorised by an Australian law or a court or tribunal order;
• a "permitted general situation" exists, such as a serious threat to someone's life, health or safety;
• an agency discloses under an international agreement about information sharing, or an enforcement body carries out enforcement-related activities.

For an everyday software engagement, none of these is a comfortable foundation. Relying on "substantially similar" overseas law needs legal analysis of that country, and consent is hard to manage across a whole client base. Meeting APP 8.1 with contracts and controls is usually the sturdier path.

Hosting in Australia is not the whole answer#

Data residency and access residency are different things. Hosting in an Australian region keeps stored data onshore, which is a good start, but it does not stop information being disclosed overseas if people outside Australia can reach it.

Some regimes are stricter than APP 8. Section 77 of the My Health Records Act 2012 prohibits the System Operator, registered repository operators, registered portal operators and registered contracted service providers from holding or taking My Health Record records outside Australia, or processing or handling related information outside Australia, or causing or permitting another person to do so. If your system will act in one of those roles, offshore access to that information is not an option, whatever the contract says.

Transparency matters too. Your privacy policy must say whether you are likely to disclose personal information to overseas recipients and, where practicable, the countries. Your collection notices need to cover the same point. If you use a team in Nepal and they may access personal information, Nepal belongs in those documents.

Practical controls that keep offshore access rare and accountable#

The aim is simple: real health information stays in Australia, under your control, and offshore engineers work without it except in narrow, approved, logged cases.

Two of these deserve a closer look.

Just-in-time access. The Australian Signals Directorate's Essential Eight maturity model builds up privileged access controls by level: requests for privileged access are validated when first requested at Maturity Level One, privileged access is disabled after 12 months unless revalidated at Level Two, and just-in-time administration is used at Level Three. For offshore engineers working on health systems, time-limited access that must be approved for each task is the pattern to aim for, with MFA on every privileged login.

Synthetic and de-identified data. The OAIC's de-identification guidance says information is de-identified only when the risk of re-identification is very low in the relevant context, and the same data can be personal information in one setting and de-identified in another. It also notes that synthetic data lets systems be tested realistically with less risk of re-identification. For development and testing, generating synthetic records is usually safer than trying to strip identifiers from a copy of production.

How we approach this as an offshore team#

Here are the facts about us. Inventure's engineers are in Nepal. We have no Australian office, company, ABN or phone number. When data must stay in Australia, we host it in OVHcloud's Sydney region. If you prefer, you keep everything in your own cloud account (OVHcloud, AWS, Azure, Google Cloud or DigitalOcean) and we manage it there, so the data, the account and the audit trail stay yours.

OVHcloud states that its ISO/IEC 27001, 27017 and 27018 certifications cover services hosted in all its data centres except those in the US. Those are OVHcloud's certifications; Inventure itself holds no certification, and we do not claim that working with us satisfies APP 8 on your behalf. Accountability under section 16C stays with you, which is exactly why we recommend the controls above: they make any offshore access rare, visible to you and written into the contract. Our Australia page and trust page explain more about how we work.

A checklist before offshore developers touch health data#

• Map what health information the system holds and every place it flows, including support tools and backups.
• Decide where production runs and whose cloud account it lives in.
• Set the access model: no standing access, approvals, MFA, logging and regular reviews.
• Write a test data policy that keeps real records out of development and testing.
• Sign a contract that covers purpose, APP handling, subcontractors, breach notification and deletion.
• Update your privacy policy and collection notices with the countries involved.
• Agree how a suspected breach will be reported between you, using our data breach response plan guide.
• Put the whole arrangement through the vendor questions for health information and review it each year.

What to do next#

If you are considering an offshore team for a health product, read how we work with Australian clients on our Australia page, then talk to us about an access model that fits your obligations before any code is written.