Your startup is Australian, but your data almost certainly isn’t. Your customer records sit in a US-headquartered CRM, your support tickets flow through a Californian helpdesk, your product runs on cloud infrastructure operated from Seattle, and since last year your team has been piping customer conversations into an overseas AI API for summarisation. Each of those arrangements can be a cross-border disclosure of personal information — and under Australian privacy law, the legal risk of what happens to that data offshore does not leave with it. If your startup is covered by the Privacy Act 1988 (Cth) — broadly, once annual turnover tops $3 million, or earlier if you trade in personal information, provide a health service or opt in — Australian Privacy Principle 8 and section 16C can leave you accountable for what your overseas providers do with the personal information you send them, as if you had mishandled it yourself. And if you are still under the small business threshold, banking on the exemption is a short-term strategy: its removal is squarely on the agenda for the next tranche of privacy reform, and investors and enterprise customers already expect APP-level practices in due diligence regardless.
Australia has no equivalent of the GDPR’s standard contractual clauses regime and, so far, no operative “adequacy” list. What it has instead is an accountability model — and for startups assembling a stack of overseas SaaS, cloud and AI vendors, that model has sharp edges. Here is how it works.
The Core Rule: Reasonable Steps, Then Accountability
APP 8.1 says that before an APP entity discloses personal information to an overseas recipient, it must take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles (other than APP 1) in relation to that information. In practice, the OAIC’s guidance is blunt about what “reasonable steps” usually means: an enforceable contract requiring the recipient to handle the information consistently with the APPs — covering permitted purposes, security, subcontractors, complaint handling and breach notification.
The teeth are in section 16C. If APP 8.1 applied to your disclosure and the overseas recipient does something with the information that would breach the APPs, that act is taken to be a breach by you. It does not matter that you took reasonable steps, that the breach was a subcontractor’s fault, or that it was inadvertent — accountability follows the disclosure. With the top-tier civil penalty for serious interferences with privacy now the greater of $50 million, three times the benefit obtained or — where the court cannot determine that benefit — 30% of adjusted turnover, and a statutory tort giving individuals their own cause of action for intentional or reckless serious invasions of privacy, “our vendor lost it” is not the safe harbour founders often assume.
Disclosure or Use? Where Cloud Providers Sit
APP 8 governs disclosures — releasing information from your effective control — not uses. The OAIC accepts that some overseas arrangements are properly characterised as a use by you rather than a disclosure to the provider. Routing data through overseas servers in transit is typically a use. So, in the OAIC’s view, can be storage with an overseas cloud provider — if a binding contract limits the provider to storing and accessing the information only for the limited purpose of providing the service to you, restricts subcontracting, and lets you retrieve the data.
Founders should read that narrowly rather than optimistically. The “use” characterisation fits infrastructure-style hosting where the provider is a passive custodian. It fits far less comfortably where the vendor analyses, enriches or trains on your data, uses it for its own product improvement, or shares it with its own ecosystem. And even where the characterisation holds, it is no free pass: you still hold the information, so APP 11’s security obligations, the Notifiable Data Breaches scheme, and liability for mishandling in the provider’s hands all still sit with you.
The Exceptions — Narrower Than They Look
APP 8.1 does not apply where an exception in APP 8.2 does. The ones that matter for startups:
- Substantially similar law. You may disclose without the reasonable-steps obligation (and without s 16C accountability) if you reasonably believe the recipient is subject to a law or binding scheme substantially similar to the APPs, and the individual can actually access enforcement mechanisms under it. You carry the burden of that belief — a legal assessment of a foreign regime, not a vibe about the GDPR.
- Prescribed countries. The Privacy and Other Legislation Amendment Act 2024 created a long-awaited “whitelist” mechanism: regulations can prescribe countries and binding schemes whose laws provide substantially similar protection, making disclosures to them safe without a case-by-case assessment. The catch, as at mid-2026: no countries have yet been prescribed, so the mechanism remains empty and the ordinary rules apply.
- Informed consent. You can disclose if, after being expressly informed that APP 8.1 will not apply and that the overseas recipient may not be bound by anything like the APPs, the individual consents. This is a genuine opt-in to reduced protection, not a line buried in your privacy policy — and the OAIC treats bundled or assumed consent sceptically. It is a poor foundation for routine vendor flows.
- Required or authorised by Australian law — an Australian statute or court order, not a foreign one.
Note what is not on the list: there is no exception for “the vendor is huge and reputable,” and none for “everyone uses them.”
AI Providers Are the New Pressure Point
Sending personal information to an overseas AI API raises exactly the same questions, with less comfortable answers. The OAIC’s guidance on commercially available AI products warns that entering personal information into AI tools can itself be a disclosure — to the developer or third parties — and recommends against putting personal information, especially sensitive information, into publicly available generative AI tools at all. For startups building on AI, the practical checklist is: use enterprise or API tiers with contractual commitments that your inputs are not used to train the provider’s models; switch off features that share prompts with third parties; prefer offerings with Australian data residency or zero-retention options where available; strip or de-identify personal information from prompts where the use case allows; and make sure your privacy policy and collection notices actually describe the flow. Your APP 5 notices and APP 1 privacy policy must disclose whether you are likely to send personal information overseas and, where practicable, to which countries — a detail startups routinely get wrong after adding a new AI vendor mid-year.
The Bottom Line
APP 8 runs on accountability, not adequacy: with no prescribed-country whitelist yet in force, the default position is that you take reasonable contractual steps and remain on the hook under s 16C for your overseas providers’ conduct anyway. So treat vendor onboarding as a privacy decision. Map where personal information actually goes, sign data processing terms that hold providers to APP-equivalent standards, choose Australian regions and no-training AI tiers where you can, keep your privacy policy’s overseas disclosure section current, and reserve the informed-consent exception for the rare cases that justify it. None of this is exotic — but it is exactly what investors’ due diligence and the OAIC’s enforcement posture now expect a data-driven startup to have done.
This article is general information only, not legal advice — how APP 8 applies always depends on the particular data flow and contractual arrangements. Viridian Lawyers advises Australian startups on privacy compliance — vendor and AI contracting, privacy policies and collection notices, cross-border data mapping, and data breach response. If your stack has grown faster than your privacy documentation, get in touch.
