APP 8 (Australian Privacy Principle 8) governs the cross-border disclosure of personal information. Before personal information goes to anyone overseas, including an offshore software team, you must take reasonable steps so they don't breach the Australian Privacy Principles (APPs).
Under section 16C of the Privacy Act, you also answer for them if they do.
So the Act doesn't ban offshore teams. It turns on one question: can your developers reach personal information? This guide covers whether the Act applies to you, what counts as a disclosure, the contract, building without customer data, and breaches at the vendor.
What APP 8 cross-border disclosure requires
APP 8 works with a second rule in the Act. First, before any disclosure to an overseas recipient, you must take reasonable steps so the recipient "does not breach the Australian Privacy Principles" (Privacy Act 1988, Schedule 1, APP 8.1). Second, after you disclose it, section 16C can treat the recipient's acts as your own, and as your breach.
An overseas recipient is anyone outside Australia who isn't you and isn't the person the information is about. Sending or showing them personal information is what the Act treats as overseas disclosure. A development company in Kathmandu or a freelancer in Manila both count. Personal information is information about an identified or reasonably identifiable person: a customer's name, email, order history or support chat.
For a buyer, the work comes down to four steps:
- Check whether the Privacy Act applies to your business.
- Decide whether the offshore team needs any personal information. Most development work doesn't.
- Put an APP 8 contract in place for the access that remains.
- Plan for a breach of your data at the vendor, because it will count as yours.
The regulator, the Office of the Australian Information Commissioner (OAIC), explains APP 8 in Chapter 8 of its APP Guidelines (version 1.3, 3 October 2025). This guide cites it by paragraph. Three numbers frame the rest:
Does the Privacy Act apply to small business?
Usually not. A business with annual turnover of $3,000,000 or less in the previous financial year is generally a "small business operator", outside the APPs (Privacy Act, s 6D).
Some activities and histories bring a small business back in (s 6D). You're covered if, among other things, you:
- provide a health service and hold health information
- trade in personal information, or pay to collect it
- are a contracted service provider under a Commonwealth contract
- have had turnover above $3 million in any financial year since starting
- are related to a company that runs a business turning over more than $3 million (s 6D(9))
The government's latest reform draft keeps the $3 million test (Attorney-General's Department, 31 August 2026). Even if you're exempt, check your customer contracts. Larger customers can demand APP-level handling of their data either way.
Use vs disclosure for offshore developers
The OAIC says that with an overseas contractor, "in most circumstances, the provision of personal information to that contractor is a disclosure" (APP Guidelines, para 8.12).
Access counts, not just sending files. One OAIC example is an Australian organization giving its overseas parent company "access to its Australian customer database" for technical and billing support (para 8.13). In that example, providing access is what makes it a disclosure. So Sydney hosting doesn't take you outside APP 8 if the team can query the data.
The alternative is a use. A use means handling information inside your own effective control (para 8.10). Giving a contractor information can be a use only "in limited circumstances" (para 8.14). The contract must confine it to narrow purposes such as storage, bind its subcontractors, and leave you in control. That fits a storage provider, not engineers who read and change your data.
Your own office overseas is a different case. APP 8 doesn't apply to it, because it's the same entity. A related company overseas is a separate entity, so APP 8 does apply (para 8.6).
In development work, that looks like this:
Usually not a disclosure
- A repository and build pipeline with no customer data
- A staging environment seeded with synthetic data
- Tickets and logs scrubbed of personal information
A disclosure
- Read access to the production database or admin panel
- A staging copy made from production
- Support tickets or logs that show customer details
If you also serve European customers, the GDPR version of this question lands in the same place: remote access from abroad counts.
California's CCPA asks a different question: it has no rule about where your developers sit, only about what the service provider contract must say.
Section 16C and vendor accountability
Section 16C makes you answerable for the vendor. Say you disclosed information under APP 8.1 and the vendor then does something that would breach the APPs if they applied to it. The Act treats that act as yours, and as your breach (Privacy Act, s 16C(2)).
Reasonable steps don't switch this off. The OAIC says you may be liable "even where" you took reasonable steps (para 8.62). The exceptions are narrow: a disclosure under an APP 8.2 exception, or to a recipient the Act already covers through an "Australian link" (para 8.63).
The practical point: a contract lowers the odds of a breach and gives you a claim against the vendor. It doesn't change whom the regulator holds responsible. The reliable way to shrink that exposure is to disclose less.
APP 8 reasonable steps: the contract
Reasonable steps usually mean a contract. The OAIC "generally" expects an enforceable contract requiring the recipient to handle the information in line with the APPs (para 8.16). Its suggested terms cover:
- the types of personal information and the purpose of the disclosure
- compliance with the APPs, from collection through to destruction
- a process for privacy complaints
- a breach response plan that tells you about suspected breaches
How far "reasonable" goes depends on sensitivity, your relationship with the recipient, the possible harm, existing safeguards, and practicability, including time and cost (para 8.17).
A development engagement needs more than that list. These terms are recommended standards, not legal requirements:
- Named access. Only named engineers reach systems holding personal information, each with their own login and multi-factor authentication.
- No copies. No production data on laptops, in development databases or in staging.
- Notice in hours. Notification within 24 hours of suspecting a breach, not "promptly".
- Subcontractor approval. Your sign-off before the vendor adds a service that could receive your data, such as a hosted error tracker.
- Exit and audit. Deletion or return at the end, confirmed in writing, plus access logs and a right to check compliance.
These terms sit next to the IP assignment clause in the same agreement. One contract then settles who owns the code and who may see the data.
APP 8.2 exceptions and their limits
APP 8.2 lists cases where APP 8.1 doesn't apply. For a company hiring developers, three matter on paper, but only two are usable today, and both are weaker than they look. The rest cover disclosures required or authorized by Australian law or a court order, "permitted general situations" such as a serious threat to someone's safety, and agency-only cases.
Substantially similar law (APP 8.2(a)). You must reasonably believe the recipient is bound by a law or binding scheme that is, overall, at least "substantially similar" to the APPs. Individuals must also have a way to enforce it. The OAIC says the belief needs a reasonable basis, for example independent legal advice, and you must be able to justify it (para 8.21).
Consent (APP 8.2(b)). You must tell each person that if they consent, APP 8.1 won't apply, and they must then agree. The OAIC adds that the statement should explain you won't be accountable and they can't seek redress under the Act (para 8.32). For an existing customer base, that rarely works.
Prescribed countries (APP 8.2(aa) and 8.3). The Privacy and Other Legislation Amendment Act 2024 lets the government list countries and schemes in regulations, taking disclosures to them outside APP 8.1. As of 30 September 2026, the list is empty. The Privacy Regulations 2025, in force since 1 April 2026, prescribe none. The August 2026 reform draft leaves APP 8 unchanged.
In practice, plan on APP 8.1 applying to any offshore team that can reach personal information.
Offshore development without personal information
The simplest way to meet APP 8 is to keep personal information out of the work. If the team can't receive or reach it, there's no disclosure, so APP 8.1 and section 16C never come into play.
Most development work doesn't need real customer records. Features, tests, build pipelines and staging need data that behaves like real data, not data about real people. The exceptions are narrow: a production-only bug, a data migration, or a support escalation.
Five steps get you there:
Map where personal information lives
Production database, backups, logs, analytics, error reports and support tools all go on the list.
Build on synthetic data
Commit scripts that generate fake but realistic records, so every environment can be seeded without a production copy. De-identified production copies are riskier: if they can be re-identified, they're still personal information.
Turn production access off by default
For an incident, give one named engineer time-limited, logged access. Then remove it.
Scrub before sharing
Strip names, emails and payment details from logs, tickets and screenshots.
Keep the off switch
Host on infrastructure you control and route vendor logins through your own identity provider, so ending access is one change.
These steps also fit APP 11. Your reasonable steps to protect personal information "include technical and organisational measures", a phrase the 2024 amendments added (APP 11.3).
For illustration, say you run a Melbourne SaaS company with a five-person team in Kathmandu. Four engineers build against synthetic data and have no production access. One on-call engineer can request four hours of logged access during an incident. Your disclosure then involves one person for a few hours, not five people every day.
If you'd like help working out which parts of your roadmap can run on synthetic data, that's what our free 30-minute scoping call covers.
Notifiable data breaches and offshore teams
A breach of data you gave your offshore vendor counts as yours. If the vendor holds personal information you disclosed under APP 8.1, the Notifiable Data Breaches (NDB) scheme treats it as held by you (Privacy Act, s 26WC).
Today there are two clocks. If you suspect an eligible breach, you must assess it and take all reasonable steps to finish within 30 days (s 26WH(2)). Once you have reasonable grounds to believe one occurred, you must notify the OAIC and the people affected "as soon as practicable" (ss 26WK and 26WL).
The second clock may get a number. The Attorney-General's Department released an exposure draft bill on 31 August 2026. It would require a statement to the Commissioner "within 72 hours" of having reasonable grounds to believe a breach occurred (draft s 26WK(2)). That runs from belief, not first suspicion. It's a draft, not law, but it belongs in vendor contracts now.
Breaches are common enough to plan for. The OAIC received 1,205 notifications in 2025, the most since the scheme began (OAIC, 6 July 2026). From July to December 2025, malicious or criminal attacks caused 405 of 670 notifications, or 60% (OAIC NDB dataset).
Detection is the slow part. Of 373 malicious or criminal attacks with usable dates, 113 (30%) took more than 30 days to identify. A vendor with weak monitoring only adds to that delay.
The OAIC has already described vendor risk. In one case study, "a software developer ran a script on the website, without authorisation from the agency", exposing documents marked private. Its lesson: organizations are responsible for their third-party providers when they outsource personal information handling (OAIC, 4 November 2025).
Breach clock: Kathmandu to Sydney
Here's an illustration with real calendar arithmetic. A vendor engineer in Kathmandu (UTC+5:45) finds an exposed staging copy of production data at 4:30 pm on Friday 6 November 2026. Sydney is on daylight saving time (UTC+11), 5 hours 15 minutes ahead, so it's 9:45 pm there.
| Vendor contract says | You hear by (Sydney time) | 30-day assessment ends |
|---|---|---|
| Notify within 24 hours | 9:45 pm Saturday 7 November | Monday 7 December |
| Notify within 72 hours | 9:45 pm Monday 9 November | Wednesday 9 December |
The 30 days start when you're aware, so a slow clause doesn't cut your assessment time. It costs response time instead: two extra days before you can confirm the exposure is contained, assess it or warn customers.
Now say that, with 24-hour notice, your assessment gives you reasonable grounds to believe at 10:00 am Monday 9 November. Under today's law, your statement is then due "as soon as practicable". Under the proposed rule, it would be due by 10:00 am Thursday 12 November. With 72-hour notice, you'd only hear about the breach that Monday night, so the regulator and your customers hear days later. For the time-zone detail, see working with a Nepal team from Australia.
Privacy Act penalties and enforcement
The penalties are large, and courts have started to use them. For a company, a serious interference with privacy can cost up to $50 million or three times the benefit obtained, whichever is greater. If the benefit can't be measured, the comparison is with 30% of adjusted turnover instead (Privacy Act, s 13G; OAIC, Guide to privacy regulatory action, para 7.17). The 2024 amendments also added a penalty for interferences that aren't serious (s 13H).
The first civil penalties came in October 2025. The Federal Court ordered Australian Clinical Labs to pay $5.8 million over a 2022 breach affecting more than 223,000 people. That included $800,000 each for failing to assess the breach and failing to notify it (OAIC, 9 October 2025). It wasn't an APP 8 case, but assessment and notification failures have now drawn penalties of their own.
When offshore is the wrong choice
Offshore development is the wrong call when the work can't be separated from sensitive personal information. Four cases stand out:
- The data is the work. If engineers must read health records every day, say to debug clinical workflows on real patient data, you can't design the access away.
- Commonwealth contracts. A contracted service provider isn't a small business operator (s 6D(4)(e)), and the agency must bind it to the APPs by contract (s 95B). Read that contract before any offshore access.
- Customer contracts that forbid it. Some enterprise agreements restrict offshore access to the customer's data, whatever the Act says.
- No clean environment yet. If every environment runs on a production copy, fix that first, or you're disclosing from day one.
None of this rules out offshore software development for the rest of the product. It rules out the parts that run on personal information.
APP 8 checklist for offshore teams
Work through this before the team gets its first login:
- To do: Confirm whether the Act applies to you (s 6D), and check customer contracts either way.
- To do: Map where personal information lives.
- To do: Decide which roles need any access. Default to none.
- To do: Seed every non-production environment with synthetic data.
- To do: Turn off standing production access; log time-limited incident access.
- To do: Sign a contract with the OAIC's para 8.16 terms plus the development terms above.
- To do: Say in your privacy policy whether you're likely to disclose overseas, and to which countries where practicable (APP 1.4(f) and (g)).
- To do: Rehearse a vendor breach against the 30-day assessment and the proposed 72-hour statement.
- To do: Remove access the day an engineer leaves.
Before you sign, work through vetting an offshore development partner and add these privacy items to your questions.
This is general information, not legal advice.