A proxy provider DPA (data processing agreement) is the contract that sets the terms on which a proxy vendor processes personal data on your behalf. At minimum it should state who is controller and who is processor for each kind of processing, list the data involved, incorporate a transfer mechanism such as the EU standard contractual clauses and the UK addendum, name the sub-processors with a notice period for changes, fix a retention period, and set out audit rights, breach notification and deletion at termination. This article walks through each of those as they apply to proxy traffic specifically. It is a practical guide, not legal advice, and your own counsel should review any agreement you sign.
Is the proxy provider a controller or a processor?
For the core service, the provider is normally your processor. You decide why requests are sent (price monitoring, ad verification, research) and to which destinations; the provider routes them on your instructions. Article 28 of the GDPR then requires a contract with specific contents, and that contract is the DPA.
The provider is also an independent controller for some processing, and a good DPA says so rather than leaving it implied. Billing, account security, fraud prevention, customer screening, and abuse handling are purposes the provider determines for itself. That processing is governed by the provider's privacy notice, not by the DPA. The split matters because it tells you which document to read when a question arises: whether your account holder's details are used for sanctions screening is a privacy notice question; how long your connection metadata is kept is a DPA question.
A third relationship sits outside your agreement entirely, and is covered in the next section.
What personal data does a proxy provider actually process?
It helps to separate three bodies of data, because they have different owners and different contracts.
Your account data. Names, email addresses and billing details of the people on your account. The provider processes this as a controller for its own purposes, under its privacy notice.
Traffic metadata. For each connection routed through the network, the provider typically records the source address, the exit address, timestamps, the destination hostname, byte counts, and the account responsible. This is the data the DPA is mainly about. It can be personal data: source addresses may identify your staff or systems, and destinations can reveal a great deal. Ask the provider to confirm in writing whether it ever inspects or stores the content of requests or responses. For HTTPS traffic through a tunnel it should not be able to, and a well-drafted DPA says it does not.
Peers' data. Residential and mobile networks route traffic through devices whose owners opted in through a partner app. The provider holds data about those people: their device's address, their consent record, and their compensation. That is a relationship between the provider, its partners and the peers, in which the provider is not acting for you. It does not belong in your DPA, but it does belong in your due diligence. Ask for the peer-facing privacy notice and the legal basis the provider relies on, because a network whose peers never gave informed consent is a legal problem that reaches its customers. The method for testing that is in how to verify a proxy provider's IP sourcing.
The data you collect at the destination (a page you scrape, say) is a further question again, about your own processing rather than the provider's. GDPR and web scraping through proxies covers it.
International transfers: SCCs and the UK addendum
Most proxy providers are established outside the EEA or UK, or use infrastructure that is. Transfers of personal data to them need a mechanism.
For EU data, the usual mechanism is the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914. The clauses come in four modules. Module Two (controller to processor) applies when you are the controller; Module Three (processor to processor) applies when you are yourself a processor acting for a client. Check that the DPA states which module applies, how the optional clauses are completed, the governing law and courts, and that the annexes (description of the transfer, security measures, sub-processors) are filled in rather than left as blanks. The clauses also expect a transfer impact assessment, which the provider should support with information about the laws that apply to it.
For UK data, the Information Commissioner issued two instruments: the International Data Transfer Agreement (IDTA) and the International Data Transfer Addendum, which amends the EU clauses for UK transfers. A provider already using the EU clauses will typically incorporate the Addendum. Swiss transfers generally use the EU clauses with Swiss-specific adjustments.
If a US provider relies on certification under the EU-U.S. Data Privacy Framework instead, ask for the certification and confirm it covers the relevant data; many providers incorporate the clauses as well.
Sub-processors and notice periods
A proxy provider's sub-processors include its hosting provider and, less obviously, the upstream network operators that carry traffic to exit addresses in the countries you target. Both should appear on the list.
Article 28(2) allows either specific prior authorization for each sub-processor or general written authorization with notice of changes and an opportunity to object. Almost every provider uses general authorization. What you should look for in a proxy provider DPA:
- A published, versioned list with each sub-processor's function and location.
- A stated notice period before a new sub-processor starts processing. Thirty days is common and workable.
- A right to object on reasonable data protection grounds, and a remedy if the objection is not resolved. For a pay-as-you-go service, that remedy is usually the right to stop using the service and recover any unused prepaid balance.
- Flow-down: each sub-processor bound by terms no less protective than the DPA, with the provider remaining liable for them.
Retention and deletion at termination
A proxy provider DPA should state the retention period for traffic metadata as a number of days, not "as long as necessary". Long enough to investigate abuse reports and resolve billing disputes; short enough that the metadata does not become an archive of your activity. Many providers settle on a window of around a month. Whatever the figure, it should match the figure in the security questionnaire and in the privacy notice.
At the end of the service, Article 28(3)(g) requires the processor to delete or return the personal data at your choice, unless law requires storage. For short-lived metadata, deletion is the practical choice. Check the DPA sets a deadline for it, allows you to request a copy first if you need one, and provides written confirmation on request.
Audit rights
Article 28(3)(h) requires the processor to make available the information needed to demonstrate compliance and to allow for audits, including inspections. In practice providers meet the first part with documents: an assurance report such as SOC 2 Type II or an ISO/IEC 27001 certificate, and for proxy networks, a sourcing attestation. The second part is usually limited by frequency, notice, confidentiality and cost.
Reasonable limits include one audit a year on reasonable notice, at your cost, by you or an independent auditor under confidentiality. Unreasonable ones are limits that remove the right altogether, such as "audits satisfied solely by the provider's certifications" with no fallback. Make sure the right widens after a breach or at a regulator's request. If the provider's assurance report is still in progress, the DPA should say what you receive in the meantime; the proxy vendor security questionnaire explains the difference between an issued report, an open observation window and a bridge letter.
Breach notification timelines
The GDPR's 72-hour deadline is often quoted in DPAs as if it applied to the processor. It does not. Article 33(1) requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach. Article 33(2) requires the processor to notify the controller without undue delay after becoming aware of it, and Article 28(3)(f) requires it to assist the controller with its obligations.
Because your 72 hours can start when the processor tells you, "without undue delay" alone leaves you exposed. Ask for a fixed maximum in hours, comfortably inside 72, and a list of what the first notice will contain: the nature of the breach, the categories and approximate numbers of data subjects and records, likely consequences, and measures taken. Further detail can follow in phases.
DPA review checklist
Use this table to review a proxy provider DPA clause by clause.
| Clause | What to look for |
|---|---|
| Roles | Processor for routing; independent controller for billing, security, screening and abuse, stated explicitly |
| Description of processing | Categories of data listed; content of requests and responses not inspected or stored |
| Instructions | Your configuration of the service counts as instructions; provider warns you if an instruction appears unlawful |
| Security measures | Specific measures in an annex, not "industry standard" |
| Transfers | SCC module identified, options completed, annexes filled; UK Addendum or IDTA; Swiss adjustments if relevant |
| Sub-processors | Published list, notice period, right to object, remedy, flow-down |
| Retention | A number of days for traffic metadata, enforced automatically |
| Breach notification | A maximum number of hours, and the contents of the first notice |
| Audit | Documents first, on-site or independent audit as fallback, widened after a breach |
| Deletion | Deadline after termination, copy on request, written confirmation |
| Precedence | SCCs prevail over the DPA, and the DPA over the main terms |
How ProxyForge's DPA is structured
Our data processing addendum is published and available to review before you sign, with the EU standard contractual clauses and the UK addendum incorporated. We publish a versioned sub-processor list and give 30 days' notice of any change, and traffic metadata is retained for 30 days. The addendum also separates the processing we do for you from the processing we do as an independent controller, such as billing and account security.
If your procurement process needs the DPA reviewed alongside our sourcing attestation, the sourcing and compliance page lists what is available and on what terms.