What a UK Data Processing Agreement is (and when you need one)
A UK Data Processing Agreement (DPA) is a contract that sets out how personal data will be handled when one organisation (the controller) hires another organisation (the processor) to process that data on its behalf. In plain terms, it documents the “rules of the road” for activities like storing customer records in a cloud platform, running payroll, sending marketing emails, providing customer support tools, or hosting a website database.
In the UK, DPAs are closely tied to the UK GDPR requirements for controller–processor relationships. A good UK data processing agreement template typically covers: what data is processed and why; how long processing lasts; confidentiality; security measures; use of sub-processors; help with data subject requests; breach notification expectations; audit/assurance rights; and what happens to data at the end of the service (return or deletion). It should also clarify roles so both parties know who decides the purpose and means of processing (controller) and who acts only on instructions (processor).
You usually need a DPA whenever a supplier processes personal data for you, even if the service feels routine. Common triggers include using SaaS tools (CRM, email marketing, analytics tied to identifiable users), outsourcing IT support with system access, or engaging an agency to manage customer lists. If two organisations jointly decide how and why data is used, that’s more likely joint controllership and needs a different type of arrangement. If a supplier uses data for its own independent purposes, it may be a separate controller relationship rather than processing.
What to include in a UK DPA template: the essential clauses checklist
A UK data processing agreement (DPA) template should clearly set out how a processor will handle personal data on behalf of a controller, in line with UK GDPR expectations. Use this checklist to confirm the essentials are covered.
- Parties and roles: Identify the controller and processor (and any sub-processors) and define key terms used in the agreement.
- Subject matter and duration: Describe the service being provided and how long processing will last (including what happens at termination).
- Nature and purpose of processing: Explain what processing activities will occur (e.g., hosting, support, analytics) and why.
- Categories of data and data subjects: List the types of personal data (e.g., contact details, account data) and whose data it is (customers, employees, website users).
- Documented instructions: State that the processor acts only on the controller’s written instructions, including around international transfers.
- Confidentiality: Require authorised staff to be bound by confidentiality obligations and limit access on a need-to-know basis.
- Security measures: Specify appropriate technical and organisational measures (e.g., access controls, encryption, backups), and how they’re reviewed.
- Sub-processing: Set rules for appointing sub-processors, including prior authorisation, flow-down terms, and notification of changes.
- Assistance duties: Cover help with data subject requests, DPIAs, and consultations with the ICO where relevant.
- Personal data breaches: Define breach notification timelines, required information, and cooperation steps.
- Audits and records: Provide audit/inspection rights (proportionate and scheduled) and require records of processing activities.
- Return/deletion: Set options for returning or securely deleting data at the end of services, plus retention exceptions where required.
How to complete and use a DPA when onboarding a SaaS supplier (step-by-step)
Step 1: Confirm the roles. In your DPA, name your organisation as the controller (usually) and the SaaS supplier as the processor. If the supplier uses sub-processors (e.g., hosting, email delivery), note that chain early.
Step 2: Fill in the processing “schedule”. Complete the table/annex with: categories of data subjects (customers, staff), types of personal data (contact details, usage logs), special category data (if any), processing purpose (providing the service, support), and duration (contract term + deletion period).
Step 3: Add security expectations. List practical measures you expect: access controls, encryption in transit, backups, vulnerability management, and incident response. If the supplier provides a security addendum or SOC 2/ISO 27001 summary, reference it in the DPA rather than rewriting it.
Step 4: Sub-processor controls. Choose whether you require specific approval (named sub-processors) or general authorisation with notice. Ensure you have a right to object within a defined window.
Step 5: International transfers. If data leaves the UK, record the transfer mechanism the supplier uses (e.g., UK IDTA or UK Addendum to EU SCCs) and where data is hosted.
Step 6: Breach and support clauses. Set notification timeframes, cooperation on investigations, and support for data subject requests (access, deletion) with clear response times.
Step 7: Sign, store, and operationalise. Get signatures (or e-sign), store the DPA with the master services agreement, and align onboarding tasks: user access setup, retention settings, and an exit/deletion checklist.
UK DPA vs GDPR Article 28 requirements: mapping your template to compliance needs
For a UK data processing agreement (DPA) template, the core compliance “checklist” is driven by UK GDPR Article 28 (mirroring EU GDPR), while the Data Protection Act 2018 (DPA 2018) provides the UK’s wider framework (including enforcement, exemptions, and public-sector rules). In practice, your template should map each Article 28(3) requirement to a clear clause, then add UK-specific references only where they change how you operate.
- Subject matter, duration, nature, purpose: include a short “Processing Details” schedule; keep it editable per project.
- Types of personal data & categories of data subjects: add tick-box lists (e.g., customer contact data; employee HR data) to avoid vague wording.
- Controller instructions: state processing occurs only on documented instructions, with a process for updating instructions.
- Confidentiality: require personnel confidentiality commitments and role-based access.
- Security: reference “appropriate technical and organisational measures” and attach a security appendix (encryption, backups, access logging) rather than hard-coding tools.
- Sub-processors: choose “specific” or “general” authorisation; include notice periods and an objection workflow.
- Data subject rights support: define response times, responsibilities, and what information the processor must provide.
- Personal data breaches: set notification timelines and minimum incident details.
- Deletion/return at end of services: specify formats, deadlines, and retention exceptions.
- Audits & compliance evidence: offer audits or third-party reports (e.g., ISO/SOC-style summaries) with reasonable limits.
UK DPA 2018 rarely requires extra contract clauses for standard commercial processing, but if you handle law-enforcement or public authority data, you may need additional terms aligned to those regimes.
DPA FAQs for UK SMEs: sub-processors, international transfers, security, and audits
Can our supplier use sub-processors?
Yes, but your DPA should require prior written authorisation (specific or general) and an up-to-date list of sub-processors. Include a clear notice period for changes and a right to object on reasonable grounds. The supplier should remain fully responsible for sub-processor performance.
How do international transfers work under a UK DPA?
If personal data leaves the UK (including remote access), the DPA should set out the transfer mechanism used, typically the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs. Ask for a brief transfer risk summary and the practical safeguards applied (encryption, access controls, data minimisation).
What security measures should be in a DPA?
Look for a schedule describing “appropriate technical and organisational measures” (TOMs): encryption in transit/at rest, MFA, least-privilege access, logging/monitoring, secure development, vulnerability management, backups, and incident response. Avoid vague wording like “industry standard” without specifics.
Do we need audit rights?
Most UK SME-friendly DPAs allow audits via (a) third-party reports (ISO 27001, SOC 2) and (b) on-site audits only when necessary, with reasonable notice and confidentiality. Ensure you can request evidence of controls, and that audit costs/limits are defined.
What about breach notification times?
Your DPA should require the processor to notify you “without undue delay” after becoming aware, with enough detail to assess impact, plus ongoing updates as facts emerge.