A data processing agreement between a law firm and an outsourced provider is not a formality. It is the document that defines exactly how client data is handled outside the firm’s own systems.
It is the first thing a Compliance Officer for Legal Practice should ask to see before any file moves.
What is a data processing agreement, and why does a firm need one?
A data processing agreement, or DPA, is the contract that governs how a processor handles personal data on behalf of a controller. Where a law firm instructs an outsourced paralegal provider, the firm is the controller and the provider is the processor.
Under Article 28 of the UK GDPR, this relationship must be governed by a written contract setting out the scope, purpose, and safeguards for that processing, as confirmed in guidance published by the Information Commissioner’s Office.
Without this in place, a firm is exposed regardless of how carefully the underlying work is actually handled. Our DPA basics article covers the foundational principles behind this requirement.
What should the agreement cover?
The scope of data being processed, security and access controls, sub-processor arrangements if any exist, breach notification timescales, and the deletion process once a task or engagement ends.
It should also set out audit rights, so the instructing firm can verify compliance rather than relying on assurance alone, and clear provisions covering what happens to any data if the engagement itself ends.
A properly drafted DPA leaves no ambiguity about who is responsible for what, at every stage of the relationship.
Why does the international transfer mechanism need its own attention?
Where data is processed outside the UK, which is the case for any firm using an offshore-delivered outsourced team, the agreement needs to address the transfer mechanism properly.
This typically means the UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses, supported by a documented transfer risk assessment specific to that arrangement.
This is not a box-ticking exercise. The risk assessment should reflect the actual destination country’s legal framework, the specific safeguards in place, and the categories of data genuinely at risk.
Our article on international data transfers covers this mechanism in more depth, including how the ICO’s international transfer guide frames the risk assessment process.
What security and access provisions should a firm expect to see?
Matter-limited access is the standard a well-drafted DPA should set: the processor’s staff can access only the specific file or task they are working on, not the firm’s wider systems or client base.
The agreement should also specify technical safeguards, encryption in transit and at rest where relevant, password and device hygiene requirements, and a clear breach reporting timescale, typically within a matter of hours rather than days.
These provisions should not be vague commitments. They should be specific enough that a firm’s own IT or compliance function could verify them.
What happens to data once a task or engagement ends?
A proper DPA specifies a defined deletion timeline once a task is complete, and a separate process for the return or deletion of all data if the engagement itself ends.
This should not be left to informal agreement. A firm should be able to point to the exact clause governing this.
The firm should also confirm the timescale is one it is comfortable defending to a client or regulator if ever asked, a standard closely related to our article on what a confidentiality agreement should cover.
What about liability if something goes wrong?
A properly drafted DPA should set out clearly what happens if the processor fails to meet its obligations, including a defined liability position and, where appropriate, an indemnity in the firm’s favour.
This is not about assuming the worst will happen. It is about knowing, in advance, exactly where responsibility sits if it does, rather than working that out for the first time during a live incident.
A firm reviewing this clause should check that it is specific rather than generic, and that it actually reflects the risk the arrangement carries.
Why does this sit in the contract, not the marketing copy?
The mechanism is a legal instrument between the parties, not a claim to make on a website. A firm should expect to see it addressed properly in the data processing agreement itself, not asserted informally in a sales conversation or a page of promotional text.
Any provider unwilling to share the actual document, in full, before a firm commits to anything, is not a provider a regulated firm should be instructing, a point also covered in our article on what to ask before instructing a provider.
How does this fit with the SRA’s expectations of supervision?
A DPA does not replace supervision, it sits alongside it. The SRA Code of Conduct for Firms expects a firm to retain proper oversight of any outsourced arrangement, and a well-drafted DPA is one of the pieces of evidence that oversight was genuinely in place.
Our How It Works page sets out how supervision and data handling work together in practice, rather than as two separate concerns.
What should a firm do with this document?
Read it in full, not summarise it, and confirm every point above is addressed before any client data is shared.
This is part of the checklist in our article on what to ask before instructing a provider, and the same checklist a firm’s COLP should apply before signing off any new arrangement.
A firm’s own compliance function, or an external adviser if needed, should be comfortable that the agreement would stand up to scrutiny, because ultimately the instructing firm carries the regulatory responsibility for the data it controls.
What role does a data processing agreement play in a wider due diligence process?
It sits alongside, not instead of, the other checks a firm should run before instructing any outsourced provider.
Conflicts checks, confidentiality terms, and supervision arrangements all need to be in place too, covered together in our article on what to ask before instructing a provider.
A strong DPA on its own does not make an arrangement sound if these other pieces are missing. It is one part of a complete picture, not a substitute for the rest of it.
How often should a DPA be reviewed once it is in place?
Regularly, not just at the outset. Data protection obligations, the nature of the work, and even the provider’s own infrastructure can change over time.
A firm that reviews its DPA only once, at the start of an engagement, risks relying on terms that no longer reflect how the arrangement actually operates months or years later.
Want the actual DPA before you commit to anything?
We’ll send over our Article 28 terms and transfer risk assessment so your review has something real to check, not a summary.
Confidential · No obligation · Typically a 20-minute call
Frequently Asked Questions
Is a Data Processing Agreement legally required, or just good practice?
It’s a legal requirement under Article 28 of the UK GDPR whenever a firm hands personal data to a processor. There’s no way round this for an outsourced arrangement, whatever the sales pitch says.
What happens if a DPA doesn’t address international transfers properly?
Then the transfer itself may have no valid legal basis. This is one of the most common gaps we see in poorly drafted agreements, and it’s worth checking before anything else.
Can a firm request changes to a provider’s standard DPA?
Yes, and a properly run provider should welcome it. Asking to clarify or strengthen specific terms is normal due diligence, not an unusual demand.
Who is responsible if the agreement is inadequate and a breach occurs?
As data controller, the instructing firm carries primary regulatory responsibility. That’s exactly why reading the agreement properly, before any data moves, matters as much as it does.
Does a DPA need to name the specific staff who will access our data?
Not necessarily by name, but it should specify how access is limited and controlled, matter by matter, so the principle of matter-limited access is enforceable, not just stated.


