Marketplace Data Processing Addendum: What To Include

Are you clear on who can use your marketplace data, who needs to protect it, and what happens if something goes wrong?

If the honest answer is "not completely", you're not alone. Marketplace privacy can get messy because you're often handling buyer details, vendor details, payment information, messages, reviews, delivery addresses and support records across several parties.

The good news is that a data processing addendum doesn't have to be complicated. For an Australian marketplace or platform, it should clearly document each party's role, what data can be used for, security standards, subcontractors, offshore disclosures and breach notification steps.

Let's make that practical.

What Is A Marketplace Data Processing Addendum?

A marketplace data processing addendum is a contract add-on that sets out how personal information is handled between your platform, your vendors and any service providers who touch that data.

You might attach it to your vendor agreement, service agreement, platform terms or supplier agreement. The point is to make sure everyone knows what they can and can't do with customer and vendor data.

For example, say you run an online marketplace where customers book local cleaners. Your platform collects the customer's name, address, phone number, booking notes and payment status. The cleaner needs some of that information to complete the job, but they don't need to upload the customer's details into their own unrelated marketing list.

A data processing addendum helps draw that line.

In Australia, the main privacy law to think about is the Privacy Act 1988 and the Australian Privacy Principles, often called the APPs. The Office of the Australian Information Commissioner, or OAIC, regulates privacy at the federal level.

Your marketplace may need to comply with the Privacy Act if, for example, your annual turnover is more than $3 million, you provide certain health services, you trade in personal information, or you fall into another covered category. Even if you're under the threshold, vendors, enterprise customers, payment providers and investors may still expect you to have proper privacy documents in place.

Do Australian Marketplaces Need A DPA?

It depends, but if your marketplace shares personal information with vendors, service providers or related platforms, a DPA is usually a smart document to have.

Australian privacy law doesn't use the exact same "controller" and "processor" language as the GDPR. Still, many Australian businesses use a data processing addendum because it gives practical structure to privacy obligations and helps meet commercial expectations.

You should seriously consider a DPA if your marketplace:

• passes customer details to vendors so they can fulfil orders, bookings or services
• lets vendors upload their own customer lists or leads into your platform
• uses cloud hosting, analytics, customer support, email marketing or identity verification tools
• shares data with delivery, payment, fraud prevention or insurance providers
• has overseas contractors, support teams or software providers accessing data
• works with larger customers who ask for a privacy addendum template or data sharing agreement

A DPA also supports your online marketplace privacy terms. Your public privacy policy tells users what you do with their information. Your DPA tells the businesses behind the scenes what they must do with that information.

Without a written agreement, you may struggle to stop a vendor misusing customer data, prove who caused a privacy incident, or get a subcontractor to cooperate when you need answers quickly.

Who Is Responsible For Customer And Vendor Data?

It depends on how your marketplace works, because different parties may be responsible for different parts of the data journey.

A simple way to think about it's this: who decides why the information is collected, who decides how it's used, and who only handles it because someone else asked them to?

For many marketplaces, your platform decides key things like account creation, booking flows, messaging, payments, reviews, fraud checks and marketing. That means you're likely to have your own privacy obligations for that data.

Your vendors may also have their own obligations once they receive customer information. For example, a florist who receives a delivery address through your platform may use it to deliver flowers. If they then save that customer to their own CRM for unrelated promotions, they're making their own decision about how to use the data.

Example: A Home Services Marketplace

Imagine Priya runs a home services marketplace in Melbourne. Her platform has 500 cleaners and handles 12,000 customer bookings a year.

For each booking, Priya's platform collects the customer's name, mobile number, suburb, exact address, preferred time, access notes and payment status. The cleaner receives the job details through an app.

Priya's DPA says the cleaner can use the information only to accept, complete, reschedule, invoice or resolve a dispute about that booking. The cleaner can't export the customer's phone number into a separate marketing database, sell the list, or contact the customer for services outside the marketplace unless the marketplace terms allow it.

That kind of detail matters. It turns a vague privacy promise into a practical rule your vendors can follow.

What Should Your Data Processing Addendum Include?

Your DPA should include the rules that let data move through your marketplace safely and predictably.

A template can be a useful starting point, but marketplace data flows are rarely identical. A lawyer should tailor the document before you use it, especially if you handle sensitive information, health information, children's information, payments, identity checks or overseas data access.

A Practical Fill-In Outline

1. Parties And Agreement: identify whether the DPA sits under your vendor agreement, customer agreement, supplier agreement or platform terms.
2. Data Types: list the personal information involved, such as names, contact details, addresses, order history, messages, reviews, IDs, payment status and support records.
3. Data Subjects: describe who the information relates to, such as customers, vendors, vendor staff, delivery recipients, support contacts and platform users.
4. Permitted Use: explain the exact purposes for which each party can use the data, such as fulfilment, customer support, fraud checks, compliance and account management.
5. Prohibited Use: ban uses that don't fit your model, such as selling customer lists, unrelated marketing, scraping, profiling outside the platform or re-identifying anonymised data.
6. Security Measures: set practical minimum standards for access controls, passwords, encryption, staff training, device security, audit logs and secure deletion.
7. Subcontractors: say when vendors or suppliers can use subcontractors and what privacy obligations those subcontractors must accept, including in any subprocessor addendum.
8. Offshore Disclosure: name the countries or categories of overseas recipients where possible, and explain what approvals or protections are needed.
9. Breach Notification: set clear timeframes for notice, investigation, cooperation and user communications.
10. Return Or Deletion: explain what happens to data when the relationship ends, including backup retention and legal record-keeping exceptions.
11. Audit And Evidence: state what information you can request to confirm compliance, such as security summaries, an information security policy or incident reports.
12. Liability And Indemnities: allocate responsibility if a party misuses data, ignores the DPA or causes loss through a privacy incident.

Try to avoid copying a generic overseas privacy addendum without checking it against Australian law and your actual platform flow. A document that sounds impressive but doesn't match how your product works can create more confusion, not less.

How Should You Handle Security, Subcontractors And Offshore Disclosure?

You should be specific, because broad promises like "keep data secure" are usually not enough when something goes wrong.

APP 11 under the Privacy Act requires covered organisations to take reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification and disclosure. What is "reasonable" depends on the nature of the information, the size of your business, the risk of harm and the practical security options available.

Your DPA should turn that principle into clear business rules.

Security Measures To Consider

• unique user accounts instead of shared logins
• multi-factor authentication for admin accounts and sensitive data access
• role-based access so vendors only see the data they need
• secure password and device requirements for vendor staff
• encryption for data in transit and, where appropriate, at rest
• logs showing who accessed or exported customer data
• staff training for anyone handling marketplace information
• secure deletion or de-identification when data is no longer needed

Subcontractors And Service Providers

If your vendors can use subcontractors, be clear about the process. Do they need your written approval first? Can they use approved categories, like delivery contractors or bookkeepers? Do they need to flow the same privacy obligations down to those subcontractors?

The same idea applies to your own providers, such as cloud hosting, helpdesk tools, payment processors, email systems and analytics platforms. Your DPA shouldn't pretend you do everything in-house if you don't.

Offshore Disclosure

APP 8 deals with cross-border disclosure of personal information. If personal information is disclosed overseas, you may need to take reasonable steps to make sure the overseas recipient doesn't breach the APPs, unless an exception applies.

For a marketplace, offshore access can happen in ordinary ways, such as overseas cloud servers, offshore support staff, international vendors, global fraud tools or contractors logging in from another country. Your DPA should require parties to disclose offshore access and get approval before adding new overseas recipients where that risk matters.

What Happens If There Is A Data Breach?

If there's a data breach, your DPA should tell each party what to do first, who must be told, and how quickly they need to act.

Under Australia's Notifiable Data Breaches scheme, an APP entity must notify affected individuals and the OAIC if there's an eligible data breach. In broad terms, that means unauthorised access, unauthorised disclosure or loss of personal information that's likely to result in serious harm, and remedial action hasn't prevented that risk.

If you suspect an eligible data breach, you must carry out a reasonable and expeditious assessment. The Privacy Act says you must take all reasonable steps to complete that assessment within 30 days after becoming aware of the grounds for suspicion.

Your DPA should require much faster notice between the parties. For example, you might require a vendor to notify you within 24 or 48 hours of becoming aware of any actual or suspected incident involving marketplace data. That gives you time to investigate, contain the issue and decide whether OAIC or user notifications are needed.

What To Do First

1. Contain The Incident: suspend affected accounts, reset passwords, disable exports or revoke API keys where needed.
2. Preserve Evidence: keep logs, emails, support tickets, screenshots, device details and vendor communications.
3. Work Out The Data Involved: identify what information was accessed, how many users were affected and whether any sensitive information was included.
4. Assess Serious Harm: consider risks like identity fraud, financial loss, safety risks, embarrassment, discrimination or misuse of contact details.
5. Coordinate Communications: agree who will contact users, regulators, insurers, payment providers or vendors so messages are accurate and consistent.

A clear breach clause can save you precious time. Without one, you may be stuck arguing with a vendor about whether they need to hand over logs while the 30-day assessment clock is already running.

How Does A DPA Fit With Your Other Marketplace Documents?

A DPA should work together with your privacy policy, marketplace terms and vendor agreement, rather than saying something different in each document.

Your public documents and your business-to-business contracts usually cover different angles.

• Privacy Policy: tells users what personal information you collect, why you collect it, who you disclose it to, including payment providers where relevant, and how they can contact you about privacy.
• Marketplace Terms: set user-facing rules for accounts, bookings, payments, reviews, acceptable use and platform access.
• Vendor Agreement: covers the commercial relationship with vendors, including fees, service standards, refunds, compliance and termination.
• Data Processing Addendum: gives detailed data handling rules between you and vendors or service providers.
• Data Sharing Agreement: may be better where both parties independently decide how they use shared information, rather than one party simply handling data for another.

For example, your privacy policy might say customer information is shared with vendors to complete bookings. Your vendor agreement might say vendors must comply with your policies.

Your DPA then gives the detail: vendors can use the customer's mobile number to coordinate the booking, must delete exported job sheets after 30 days, and must report suspected unauthorised access within 24 hours.

Make sure the documents don't conflict. If your public privacy policy says data is shared only for fulfilment, but your vendor terms let vendors use it for their own promotions, that gap can create privacy and customer trust issues.

Privacy law in Australia is also changing over time, so it's worth reviewing your documents as your platform grows, adds new tools or enters new markets.

Key Takeaways

• A marketplace DPA sets the practical rules for how customer and vendor data is used, protected, shared and deleted.
• Australian privacy law doesn't use the same controller and processor language as the GDPR, but a DPA is still very useful for allocating responsibilities.
• Your DPA should cover permitted use, prohibited use, security, subcontractors, offshore disclosure, breach notification, deletion and liability.
• Under the Notifiable Data Breaches scheme, suspected eligible breaches should be assessed promptly, with reasonable steps taken to complete the assessment within 30 days.
• Your DPA should line up with your privacy policy, online marketplace privacy terms, vendor agreement and any data sharing agreement you use.
• Templates can miss the way your marketplace actually operates, so it's worth getting the document tailored before you rely on it.

If you'd like help with your marketplace privacy terms, vendor data rules, data processing addendum or breach response process, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.