Data processing addendums, a clause-by-clause guide for Australian businesses

When the DPA lands on your desk

You have just signed up to a new customer relationship tool, payroll provider or cloud storage service, and alongside the service agreement the vendor sends a separate document: a data processing addendum. Or the corporate client that wants to onboard you as a supplier sends their own addendum and asks you to sign it before the first invoice is raised. Either way, you are being asked to commit to terms about how personal information will be handled, often with little time to think about what they mean.

A data processing addendum (DPA) is a contract that sets out how personal information is handled when one party processes it on behalf of another. It does not stand alone. It supplements a broader agreement, such as a services contract, software subscription, supplier agreement or contractor arrangement, and it works alongside your privacy policy rather than replacing it. What it binds is the relationship between you and the party holding your customers' or your employees' data: what that party may do with the information, how it must protect it, what it must tell you when something goes wrong, and what happens to the data when the arrangement ends.

Why an Australian DPA starts with the Privacy Act

The Privacy Act 1988 (Cth) does not use the "controller" and "processor" labels found in overseas frameworks like the GDPR. Obligations fall on "APP entities", the organisations and agencies the Act covers, and they attach to whoever decides why and how personal information is collected and used. In the usual arrangement, that is your business. The cloud provider, payroll firm or marketing agency that handles the information on your instructions is not typically the party the Act regulates directly, which is why the DPA exists: it translates your statutory duties into obligations the other party will actually meet.

Two things follow, even before you look at a single clause.

First, outsourcing storage does not outsource responsibility. The Office of the Australian Information Commissioner's Guide to Securing Personal Information notes that an entity which outsources the storage of personal information to a third party but retains the right to deal with that information, including to access and amend it, still "holds" it. The security obligations in APP 11 keep applying to you, so the DPA is the mechanism for making the processor's practical duties match your legal ones.

Second, the small business exemption does not remove the commercial need for a DPA. Under s 6D of the Privacy Act 1988 (Cth), a business whose annual turnover for the previous financial year was $3,000,000 or less is generally exempt from the Australian Privacy Principles, subject to exceptions. The exemption remains in the current Act, although privacy reform proposals have flagged changes. But even a business outside the Act's reach can be asked to sign a DPA by a customer or supplier, and the document is a practical risk-management tool regardless of whether the Act applies to you.

The essential clauses in a data processing addendum

There is no standard form DPA, because the right terms depend on your business model, the sensitivity of the data and what the other party actually does with it. The clauses below are the ones that do the heavy lifting, whether you are reviewing a vendor's draft or preparing your own.

What is being processed, and why

The DPA should describe the categories of personal information involved (customer names and contact details, purchase history, IP addresses, employee records), the categories of individuals, the purposes of the processing (hosting, payroll, customer support, marketing) and how long it continues:

• What it does: fixes the boundary of what the processor is allowed to touch, so a later dispute turns on the written scope rather than recollection.
• The trap: a vague description such as "all data in the system" can be read as authorising uses you never intended, while a scope that is too narrow leaves routine support tasks outside the agreed terms.
• The variant the other side pushes for: a schedule of data they promise to "finalise later". If the schedule is blank at signing, the scope is effectively unfixed.

The drafting minimum is to cross-reference the services agreement and list the actual data flows in the DPA itself, rather than relying on a generic phrase.

What the processor may do with the data

A standard clause provides that the processor will only process personal information on your documented instructions, will not use the data for its own purposes, and will ensure its personnel are bound by confidentiality. It should also rule out selling, renting or otherwise exploiting the information:

• The trap: carve-outs for "de-identified" or "aggregated" data that let the processor retain and reuse customer information for its own analytics or model training. Information that can no longer identify an individual falls outside the Act's definition of personal information, so a broad carve-out can hand the processor a licence to keep data you thought was protected.

Check what the clause means by "de-identified" before you sign, and ask whether any retained data is genuinely stripped of identifiers or merely labelled as such.

The security standard the processor must maintain

Under APP 11.1, an APP entity that holds personal information must take reasonable steps to protect it from misuse, interference, loss, and unauthorised access, modification or disclosure. The DPA should pin the processor to at least that standard, and ideally name concrete measures: encryption in transit and at rest, access controls, staff training, backup and recovery processes, and an incident response capability:

• What the processor pushes for: "reasonable and appropriate security measures" with nothing concrete, which gives you no way to assess whether their controls match the sensitivity of your data.
• The drafting minimum: an obligation to maintain security measures at least equivalent to a standard set out in a schedule or a named framework, plus a duty to notify you of material changes.
• The trap: a security clause written once and never updated. Systems and threats change, so the clause should require the processor to keep its measures current.

How fast you find out about a breach

If you are covered by the Privacy Act, the Notifiable Data Breaches (NDB) scheme in Part IIIC of the Act applies. Where there is unauthorised access to, unauthorised disclosure of, or loss of, personal information that is likely to result in serious harm to affected individuals, s 26WK requires you to prepare a statement and give it to the Information Commissioner, and s 26WL requires you to notify the affected individuals. Both obligations run "as soon as practicable" after you become aware there are reasonable grounds to believe an eligible data breach has happened.

Your clock starts when you become aware, so the DPA's notification clause determines whether you can meet it:

• What the clause should say: the processor notifies you of any security incident, not just incidents it considers material, without delay and usually within a fixed window of 24 to 72 hours, with the facts: what happened, what data was involved, what has been done and what is planned.
• The trap: a clause that lets the processor decide what is reportable, or that allows 30 days to pass before you hear anything, can leave you scrambling to meet your own obligations.
• Assistance: the processor should also agree to help you assess whether an incident meets the "serious harm" test and to support any notification you are required to make.

Sub-processors: who else gets your data

Most processors use subcontractors to deliver parts of their service: hosting providers, support teams, analytics tools. The DPA should say whether sub-processing is allowed, require your written approval for new sub-processors (or at least notice plus a right to object), require equivalent obligations to be flowed down to them in writing, and keep the main processor responsible for what its sub-processors do:

• The trap: blanket consent to "any current or future sub-processors", with additions merely posted to a website you never visit.
• The drafting minimum: a current list of sub-processors attached to the DPA and a commitment to notify you of any additions so you can exercise your approval rights.

Where the data goes: cross-border transfers

Data that is stored or accessed outside Australia triggers APP 8. Before disclosing personal information to an overseas recipient, an APP entity must take such steps as are reasonable in the circumstances to ensure the recipient does not breach the Australian Privacy Principles, and under s 16C the acts of the overseas recipient are treated as your own for the purposes of the Act:

• What this means in practice: your "Australian" software vendor may host data in Singapore or the United States, or use overseas support staff. If it does, the accountability stays with you.
• The clause to look for: a location commitment naming the countries where data is stored and accessed, and a promise not to relocate without notice and your consent.

Return or deletion when the relationship ends

When the agreement ends, you will usually want the data returned or securely destroyed. The DPA should give you the choice, set timeframes for completion, require written certification of deletion, and deal with backups. APP 11.2 already requires an APP entity to destroy or de-identify personal information once it is no longer needed, so the clause should extend that discipline to the information the processor holds for you:

• The trap: a buried statement that "backups will be deleted within 12 months". A retention tail is sometimes legitimate, but it should be explicit, time-limited and justified, not something you discover when you ask for deletion.

Audit and assurance rights

On-site audit rights sound powerful, but many vendors will not accept them and a small business is unlikely to exercise them in practice. More workable alternatives include security certifications such as SOC 2 or ISO 27001, annual compliance reports, completed security questionnaires, and a duty on the processor to cooperate with reasonable requests for information:

• The trap: an elaborate audit clause that the processor ignores because it is unworkable, leaving you with less transparency than a simple reporting obligation would have provided.

Liability, caps and who pays

Finally, the DPA should allocate who bears the cost when something goes wrong. Processors commonly cap liability at the fees paid under the agreement and try to exclude data breach losses from that cap:

• What to push for: a carve-out from the cap for amounts arising from the processor's breach of its security or confidentiality obligations, or from processing outside your instructions, plus clear allocation of breach response costs such as forensic investigation and notification.
• The trap: a cap that swallows the whole DPA makes the rest of the document largely aspirational, because the processor has no meaningful exposure for failing to comply.

Clauses worth adding when the situation calls for them

The clauses above are the core. These additional ones are worth including when the circumstances justify them:

• Assistance with individual rights: if people will ask you to access or correct their information, the processor should help you locate and provide records within agreed timeframes, because under the APPs the request is made to you.
• Cyber insurance: require the processor to carry cyber cover with limits that match the sensitivity of the data, which matters most where health or financial information is involved.
• Security certification commitments: a promise to maintain named certifications and tell you if they lapse, which is increasingly a procurement requirement of larger clients.
• Records of processing: the processor keeps a written record of what it processes, where, and for how long, which is useful if a regulator asks you to explain your data flows.
• Marketing and consent obligations: if the processor runs email or lead generation campaigns for you, pin down consent records and unsubscribe compliance, because the marketing conduct remains yours.

How an Artificer Legal practitioner would review a DPA

When we review a DPA for a client, we start with the scope schedule and the security clause, because those set the floor for everything else. We then check the breach notification clause, the sub-processor provisions and the cross-border commitments, and we leave the liability provisions until last, because they are usually the hardest fought and you want the substance settled before the argument about money.

The clauses we would push back on include unilateral variation rights that let the processor change the DPA on notice with you deemed to accept, blanket consent to sub-processors, liability caps that swallow security breaches, and audit provisions drafted so they can never realistically be used. We would also check the DPA against your privacy policy, your client contracts and any security claims you make in marketing. Under s 18 of the Australian Consumer Law (Schedule 2 of the Competition and Consumer Act 2010 (Cth)), a person must not, in trade or commerce, engage in conduct that is misleading or deceptive, so a DPA that promises more than your marketing delivers is a problem from two directions at once.

The clause that decides how a breach plays out

If one clause separates a DPA that works from one that does not, it is the breach notification clause. Security measures and liability caps matter, but the notification clause decides whether you learn about a problem in time to act. Your NDB clock starts when you become aware there are reasonable grounds to believe an eligible data breach has happened, and "as soon as practicable" is a short window when the regulator is involved. A processor that can sit on an incident for weeks, or decide for itself what counts as reportable, can turn a contained problem into a notifiable one. A DPA that fixes a concrete escalation window, defines what the processor must report and requires it to support your assessment is the difference between running a breach response and being its passenger.

The rest of the picture is simpler than it looks. A DPA supplements your services agreement, it does not replace your privacy policy, and the Privacy Act's obligations stay with you even when a third party holds the data. The core clauses are the description of processing, instructions-only handling, security, breach notification, sub-processors, cross-border transfers, return or deletion and liability. Add the situational clauses where sensitive data is involved, keep the document consistent with what you tell customers and clients, and you have a DPA that does what it is supposed to do.