- The controller and the processor: who's who
- When does an Australian business need a data processing agreement?
- What a data processing agreement must cover
- A data processing agreement in practice
- The Australian position: the Privacy Act and overseas disclosure
- Common misconceptions about data processing agreements
- When professional help is needed
- Know your role before you sign
A data processing agreement (a DPA) is a written contract that sets out what one business may do with personal data when it handles that data on another business's instructions. Under the European Union's General Data Protection Regulation (EU) 2016/679 (the GDPR), this contract is not a nice-to-have: Article 28 of the GDPR requires that whenever a processor handles personal data on behalf of a controller, the two must be bound by a written agreement that meets a set of mandatory requirements.
Australian businesses come across DPAs in two ways. First, the GDPR can apply to businesses that have never set foot in Europe. Secondly, even where it does not, overseas clients and platforms routinely ask Australian suppliers to sign their DPA as a condition of doing business. And if neither of those applies, Australia's own Privacy Act 1988 (Cth) still creates real exposure when personal information is sent overseas, and a contract is the standard tool for managing it.
This article explains the roles of controller and processor, when you need a DPA, what it must contain, how the Australian privacy regime fits alongside it, and the misconceptions that catch businesses out.
The controller and the processor: who's who
The GDPR divides the businesses that handle personal data into two roles. Personal data is any information relating to an identified or identifiable individual, such as a name, an email address, a phone number or a medical record. A controller is the business that decides why and how personal data will be processed. A processor is the business that processes personal data on the controller's behalf. These definitions sit in Article 4 of the GDPR.
The same business can wear both hats. An Australian recruitment agency that uses a cloud-based applicant tracking system is a controller in relation to the candidates whose data it collects, but a processor in relation to any client that hands it employee data under an outsourcing arrangement. Working out which role applies to each data flow is the first step, because the DPA only makes sense once you know who is directing the processing and who is carrying it out.
The distinction also matters because both roles carry their own obligations. A processor is not just the controller's helper: it has direct statutory duties under Article 28 itself, and it can be fined in its own right for breaching them.
When does an Australian business need a data processing agreement?
There are two routes into needing a DPA: the law requires it, or a client requires it.
The law requires it when the GDPR applies to your processing. Under Article 3 of the GDPR, the regulation applies to businesses outside the EU where their processing relates to offering goods or services to individuals in the EU, whether payment is required or not, or to monitoring the behaviour of individuals in the EU. An Australian software company with a dozen German subscribers is processing personal data of EU data subjects and is caught, even though it has no European office. If it acts as a processor in that arrangement, Article 28 mandates the DPA.
The client route is more common. A controller that is itself subject to the GDPR may only use processors that provide sufficient guarantees of appropriate technical and organisational measures. In practice, that means EU and UK businesses run security and privacy reviews of their Australian suppliers and require them to sign a DPA before any data flows. The same pattern is spreading beyond Europe, as larger corporate and government buyers adopt data protection clauses in their standard procurement terms.
The consequences of getting this wrong are serious. For serious infringements, such as breaches of data subjects' rights or unlawful transfers of data out of the EU, Article 83 of the GDPR allows fines of up to €20 million or 4 per cent of total worldwide annual turnover, whichever is higher. Lesser infringements, including breaches of the processor obligations in Article 28, carry fines of up to €10 million or 2 per cent of turnover. Separately, under Article 82, controllers and processors can be liable to compensate individuals for damage, and where more than one party is responsible, each can be held liable for the entire damage.
What a data processing agreement must cover
Article 28(3) sets out the backbone of the contract. The agreement must state the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data involved, the categories of data subjects, and the obligations and rights of the controller. In short, the document has to describe the job accurately enough that a third party could see exactly what data is being processed, why, and for how long.
On top of that description, the agreement must bind the processor to a set of specific obligations:
- Instructions only: process the personal data only on the controller's documented instructions, including any transfers of data to a third country, and tell the controller if an instruction appears to breach the GDPR.
- Confidentiality: ensure that everyone authorised to process the data has committed to confidentiality.
- Security: implement the technical and organisational measures required by Article 32, such as encryption, so the data is protected against unauthorised access.
- Sub-processors: not engage another processor without the controller's prior specific or general written authorisation, and pass the same obligations down the chain. Under Article 28(4), the initial processor remains fully liable to the controller for the sub-processor's performance.
- Data subject rights: help the controller respond to individuals exercising their rights, such as access, correction and erasure.
- Breach and assessment support: assist the controller with its obligations around security breaches, data breach notification and data protection impact assessments.
- Deletion or return: delete or return all the personal data when the services end, and delete existing copies unless the law requires otherwise.
- Audit and transparency: make available the information needed to show compliance, and allow the controller to audit and inspect the processing.
A DPA does not have to be a standalone document. It is common to see it as a schedule or addendum to a larger services agreement, sometimes called a data processing addendum or schedule. What matters is that the substance required by Article 28(3) is there.
A data processing agreement in practice
To see how this works, take a Sydney payroll software business, PayWell, that provides its platform to Nordic Coffee, a chain with staff across Europe. PayWell processes employee names, bank details and salary information for Nordic Coffee's European workforce. Nordic Coffee is the controller: it decides that payroll data will be processed and how. PayWell is the processor: it carries out the processing on Nordic Coffee's instructions.
The two sign a DPA that identifies the subject-matter as payroll administration, sets the duration as the term of the services agreement, describes the purpose as calculating and paying wages, lists the types of personal data and identifies the affected employees as the categories of data subjects. The DPA also includes the processor obligations from Article 28(3).
Later, PayWell wants to move its hosting to a data centre in Singapore. Under the DPA and Article 28(2), it cannot simply do this: it needs Nordic Coffee's prior written authorisation, because the Singapore data centre is a sub-processor and because moving the data engages the GDPR's rules on transfers of personal data outside the EU. When a stolen backup containing salary data is later accessed, the DPA's breach support clause requires PayWell to assist Nordic Coffee with its notification obligations. PayWell also faces potential liability of its own under Article 82 if it failed to meet its processor obligations, because the DPA allocates responsibility between the parties but does not give the controller a free pass.
The Australian position: the Privacy Act and overseas disclosure
Australia does not yet have a GDPR-style requirement to sign a data processing agreement. The Privacy Act 1988 (Cth) does not use the language of controllers and processors, and no provision obliges an Australian business to enter into a DPA as such. But the Act regulates the same underlying activity: sending personal information overseas.
Australian Privacy Principle 8.1 (APP 8.1) requires an APP entity, before disclosing personal information to an overseas recipient, to take such steps as are reasonable in the circumstances to ensure that the recipient does not breach the Australian Privacy Principles in relation to the information. The Office of the Australian Information Commissioner (OAIC) makes clear that handing personal information to an overseas contractor to perform services is generally a disclosure, so APP 8 applies. Contractual terms that bind the overseas recipient to privacy standards are a recognised way of taking reasonable steps, alongside due diligence and checking the destination's legal protections. Exceptions apply in limited cases, such as where the individual consents or the recipient is subject to laws substantially similar to the APPs.
What makes this bite is section 16C of the Privacy Act: if the overseas recipient mishandles the information in a way that would breach the APPs, the APP entity is treated as having done the act itself. A poorly contracted overseas contractor can therefore become your breach. The notifiable data breaches scheme in Part IIIC adds to this, because personal information held by an overseas recipient is treated as held by the APP entity. If there are reasonable grounds to believe an eligible data breach has occurred, the entity must notify affected individuals and the OAIC.
Reform is coming in stages. The Privacy and Other Legislation Amendment Act 2024 (Cth) received royal assent in December 2024 as the first tranche of reform, and the government has flagged further changes, including a possible move toward a direct obligations model more like the GDPR. For now, though, Australian businesses should treat well-drafted data processing terms as the practical backbone of APP 8 compliance rather than as a statutory formality.
Common misconceptions about data processing agreements
Four misconceptions tend to recur when Australian businesses first confront DPAs:
- A DPA is the same as a privacy policy: It is not. A privacy policy is the public-facing document that tells individuals what information you collect and why. A DPA is a behind-the-scenes contract between two businesses that allocates obligations for a specific processing arrangement. You can have both, but they do different jobs.
- Signing a DPA transfers all the liability to the processor: Under Article 82, a controller involved in processing remains liable for damage caused by processing that infringes the GDPR, and each responsible party can be held liable for the entire damage. The DPA manages and allocates risk between the parties, but it does not insulate the controller from its own regulatory exposure. The same logic applies in Australia, where section 16C keeps the APP entity accountable for the overseas recipient's conduct regardless of what the contract says.
- DPAs only matter for European businesses: The GDPR reaches Australian businesses that target EU customers or monitor EU residents, and EU and UK clients demand DPAs as a matter of course. Even a purely domestic business with an overseas contractor faces APP 8 and its deemed-breach rule.
- Any template will do: A DPA has to match your actual processing: the data types, the purposes, the sub-processors, the countries data flows to. A template that describes processing you do not do, or misses a transfer you do make, creates false comfort and can leave a sub-processor engaged without the authorisation the GDPR requires.
When professional help is needed
The point at which most Australian businesses need a lawyer is when they are asked to sign someone else's DPA, or asked to produce their own. These documents are increasingly negotiated, not just signed: liability caps, audit rights, the sub-processor list, indemnities and the mechanisms for lawful cross-border transfers are all points where a standard form drafted by the other side can quietly shift risk onto you.
A privacy lawyer will map your data flows so you know which role you occupy for each arrangement, review and negotiate the DPAs you are handed, draft processor schedules that match what you actually do, and check the whole picture against both the GDPR and the Privacy Act, including APP 8 and the notifiable data breaches scheme. That work also smooths operations, because a DPA that reflects your real practices is one you can actually perform, and one that will get you through a client's security review instead of holding it up.
Know your role before you sign
Before you put a signature on any DPA, answer two questions about each data flow: which role are you signing in, and can you actually do everything the document says you will do? The agreement will bind you to delete data on request, to keep audit access ready, to get authorisation before adding a sub-processor and to support breach notifications. Businesses that sign without checking whether their systems can deliver those promises discover the gap only when a client exercises the right, or a regulator comes calling. If you cannot map the data and the role, that is the moment to get the document reviewed rather than to sign it.