GDPR for Australian companies

Who this is relevant to

This guide addresses Australian companies operating without a European legal entity. Once you set up an EU subsidiary or branch, additional obligations attach through that entity rather than through extraterritorial reach, and this guide is not the full picture for you.

• —SaaS businesses in the middle of closing their first contract with a European enterprise
• —Platforms whose end users happen to include people working or living in the EU
• —Vendors selling into government, utilities or other critical-infrastructure-adjacent buyers expanding into Europe
• —Consumer products and marketplaces that have picked up a European user base without planning for it
• —Teams who have just been handed a DPA or a transfer impact assessment by a prospect and are not sure what to do with it

Two very different ways this law finds an Australian company

Article 3(2) of the GDPR extends the law beyond the EU's borders in two specific circumstances: offering goods or services to people located in the EU, and monitoring what those people do while they are physically there. Neither requires a euro of EU revenue to bite.

“Offering” is judged on intent, not accessibility. A website hosted in Sydney that happens to load in Amsterdam proves nothing. Quoting in euros, running localised marketing for European markets, listing European reference customers or shipping product into EU countries all point the other way.

“Monitoring” is the limb Australian software teams underestimate, because it has nothing to do with sales targeting. If your product tracks in-app behaviour, scores users or feeds ad platforms while a person is sitting in Europe, that is monitoring, regardless of whether you ever pitched that market.

A separate, non-extraterritorial route exists as well: your customer is an EU entity bound by the GDPR, and it hands you its data to process. You have not targeted anyone (your customer has done that already), but you are now a processor, and the obligations reach you through the contract your customer is required by law to put in place.

Direct application vs customer flow-down

Knowing which situation you are in changes what enforcement actually looks like. A direct obligation sits with you permanently and can be pursued by a European supervisory authority no matter what happens to any one customer relationship. A flow-down obligation lives inside a contract: your customer enforces it, and the practical consequence of falling short is usually a stalled or lost deal rather than a regulatory investigation.

It is common for an Australian vendor to be both at once, for different pools of data: a controller over its own marketing site analytics aimed at European visitors, and a processor over the customer records sitting inside its product.

• —Direct (controller): you decide the purpose and means of processing, covering your marketing, your own analytics, your own user base
• —Flow-down (processor): you act on a European customer's documented instructions, under a contract carrying prescribed terms
• —Holding both roles simultaneously is ordinary, not a sign something has gone wrong. Just keep the paperwork for each role separate

What a European customer actually asks for

You will almost never be asked, in plain words, whether you are compliant. Instead you will be asked to hand over specific documents, and the deal proceeds only as fast as you can produce them.

• —A data processing agreement, either theirs to sign or yours to offer
• —A current list of subprocessors and a process for flagging changes to it
• —A plain statement of where the data sits and which countries can access it
• —Written technical and organisational security measures, not a verbal assurance
• —A committed breach notification window
• —A named person who can field privacy questions directly, without three internal handoffs
• —Your international transfer position, with the reasoning behind it, not just a conclusion
• —Proof that a data subject request routed through your customer can actually be executed in your systems

Common misconceptions

“We don't have an EU entity, so this doesn't touch us.”

Having a European legal entity is only one path into scope. Targeting people in the EU, or monitoring them there, puts a company with zero EU presence squarely inside the law.

“We're already compliant with the Privacy Act and the APPs, so we're most of the way there.”

That compliance is genuinely useful groundwork: you likely already hold a data inventory, have breach-handling habits from the Notifiable Data Breaches scheme, and have someone accountable for privacy. What it does not give you is the GDPR's specific scope test, its individual rights regime, its lawful-basis documentation, or the level of written evidence a European buyer's legal team expects to see. Treat it as a head start, not a finish line.

“We're a small business, so a privacy exemption covers us.”

The Privacy Act's small-business exemption is a domestic Australian carve-out. It has no equivalent in the GDPR and no bearing on it. A European buyer assessing your obligations will disregard it entirely, and citing it in a security questionnaire signals you have not looked closely at what is actually being asked.

“We only sell to other businesses, so personal data doesn't really come into it.”

Contact records for your buyer's staff, user accounts, support conversations, session logs and product analytics are all personal data the moment they relate to an identifiable person, whatever the label on the commercial relationship.

“Our cloud provider's certifications settle the transfer question for us.”

A provider's certification speaks to its own environment. The transfer position covering the data you personally receive and process is a separate exercise, and your customer will ask you for it by name.

Practical checklist

1. 01Work out, dataset by dataset, whether you sit as controller, processor, or both
2. 02Write down exactly which of your activities touch people located in the EU, and how you know
3. 03Map where EU personal data physically sits and which countries, including Australia, can access it
4. 04Draft a data processing agreement you can hand over first, rather than only ever reacting to a customer's version
5. 05Keep a subprocessor list ready to send exactly as it stands, with no last-minute tidying
6. 06Write your security measures down at the level of detail a security reviewer expects, not a marketing summary
7. 07Set a breach notification timeframe you can genuinely meet, and keep it separate from your Notifiable Data Breaches obligations to the OAIC, which are a different regime with different recipients
8. 08Assign a privacy owner, even part-time, so questions have a named destination
9. 09Settle your transfer mechanism before a deal forces the question, rather than guessing in a questionnaire
10. 10Check your cookie banner and SDKs against EU consent rules separately from your GDPR work

The Australian transfer question

Australia does not currently hold an EU adequacy decision. That single fact means every transfer of EU-origin personal data into your systems needs an actual assessment. There is no shortcut that lets you skip straight to a mechanism.

Standard Contractual Clauses may turn out to be the right answer once that assessment is done, but they are not guaranteed to be, and we will not tell you to sign them before you have looked at the data, the parties and the surrounding facts.

Reforms to the Privacy Act have been pushing Australian practice toward the kind of individual rights, breach-notification rigour and scrutiny of automated decisions that the GDPR already requires. That narrows the gap over time, but it has not closed it, and the two regimes still need to be tracked as separate obligations rather than assumed to converge.

Because Australia sits many time zones from Europe, expect European buyers to ask about support coverage and where your disaster-recovery site lives, on top of the legal transfer question. For Australian vendors, this question can arise when EU-related processing or transfer arrangements are involved.

Cookies sit under a different rulebook entirely

Consent obligations for cookies, SDKs and similar device storage come from the ePrivacy Directive as implemented in national law, not from the GDPR. An Australian company can have its data protection documentation in good order and still be running a non-compliant consent banner on the same product.

Official EU sources

Every conclusion on this page traces back to the primary legal text. We link only to official EU sources.

• Regulation (EU) 2016/679 — General Data Protection Regulation · Read on EUR-Lex (CELEX 32016R0679)Verified 2026-08-17

• Directive 2002/58/EC — ePrivacy Directive · Read on EUR-Lex (CELEX 32002L0058)Verified 2026-08-17