When and why do you need a DSA?
Introduction
You may be asking “what is a Data Processing Agreement (DPA), and how does it differ from a Data Sharing Agreement (DSA)?” Navigating data governance agreements can be complex but establishing clear parameters is essential for compliance. Under data protection legislation, formalising certain data governance relationships with a contract is a statutory requirement enforced by the Information Commission (IC), whereas for other arrangements it is regulatory best practice.
This article focuses primarily on the Data Processing Agreement (DPA), which governs the relationship between a data controller and processor. It then explores when and why you need a Data Sharing Agreement (DSA). Additionally, we will examine how overarching Data Sharing Frameworks (DSF) and Specifications (DSS) support complex research projects and large-scale collaborations.
What is a Data Processing Agreement (DPA)?
Remember!
Under Article 4(7) of the UK GDPR, a controller is the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.
Example: An NHS Trust is the data controller for patient clinical records created during hospital stays. The Trust determines that the purpose of processing is medical record management and that the means to do so is employing an electronic patient record (EPR) system.
On the other hand, under Article 4(8) of the UK GDPR, a processor is a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller.
Example: A third-party provider contracted by the NHS Trust to host the electronic patient record (EPR) system is a data processor.
Specifically, Article 28(3) of the UK GDPR establishes that “processing by a processor shall be governed by a contract or other legal act that is binding on the processor with regard to the controller.” This means every time a controller uses a processor to process personal data, there must be a written contract that legally binds the processor and controller in respect of the processing activities.
Crucially, Article 28(3) can be satisfied with a direct contract between the controller and processor, or by other legally binding contractual arrangements (for example, a set of contracts between multiple parties), provided the processor is ultimately bound to the controller regarding the specific processing.
The agreement must be in writing, which could be in an electronic form, as non-written agreements are not sufficient to meet Article 28(3) requirements. Additionally, to avoid difficulties in demonstrating compliance with data protection legislation, organisations should ensure that necessary signatures of the parties are included in the contract.
Importantly, the agreement should not merely restate the provisions of the UK GDPR. Rather, it should include specific, concrete information on how the requirements set out in the legislation will be met and which level of security is required for the personal data being processed.
What should be included in a DPA?
General terms
Article 28(3) sets out key mandatory requirements for all DPAs. To satisfy these legal standards, the agreement must include:
Subject matter and duration of the processing – what service is being provided and for how long?
Example: provision of an online digital triage platform for GP surgeries for a 3-year contract duration.
Nature and purpose of the processing – how will the processor handle the data and why?
Example: hosting patient-submitted online forms to allow GP practice clinical staff to evaluate patient symptoms remotely.
Type of personal data and categories of data subject – what data points are involved and who do they relate to?
Example: NHS Number, full name and explanation of symptoms of patients registered at GP practices within the region.
Controller’s obligations and rights (in line with data protection legislation).
Specific clauses
Additionally, to ensure compliance with data protection principles like accountability and transparency, Article 28(3) mandates that the DPA must incorporate specific clauses:
Processing only on the documented instructions of the controller
The processor must only process personal data upon documented instructions from the controller and outlined in the DPA. Crucially, if a processor acts beyond the controller’s instructions without specific approval, it ceases to act as a processor and legally becomes an independent controller. This is a direct violation of the DPA and of the processor’s data protection obligations.
Example: if an NHS Trust engages a vendor to send patients automated SMS text reminders about their appointments, using those patient numbers to advertise a private app without permission of the Trust breaches the agreement and renders the vendor an independent data controller.
Duty of confidence
The processor must ensure that any person processing personal data is subject to a duty of confidentiality.
Appropriate security measures
The processor must take all measures required, pursuant to Article 32 of the UK GDPR (security of processing), including implementing technical and organisational measures to protect personal data received from the controller.
For example, having the encryption of data in transit (TLS 1.3) and at rest (AES-256) and implementation of role-based access controls to ensure data access is strictly limited to authorised personnel on a need-to-know basis.
Using sub-processors
Article 28(4) states that where a processor engages another processor (a sub-processor) for carrying out specific processing activities on behalf of the controller, the same data protection obligations set out in the DPA between the controller and processor must be imposed on that sub-processor.
Importantly, the processor must obtain either specific or general written authorisation from the controller for any sub-processors prior to its engagement. Where general written authorisation is granted, the processor must inform the controller of any intended changes or substitutions, providing them with reasonable opportunity to object before the new sub-processor is appointed. The processor remains fully and directly liable to the controller for the sub-processor’s performance and compliance with data protection obligations.
The processor must take appropriate technical and organisational measures to help the controller respond to requests from individuals to exercise their rights under Chapter III of the UK GDPR.
In practice this can include assisting the controller with a Data Subject Access Request (DSAR) in locating all personal data associated with a specific individual across all its databases, backups, and logs.
Assisting the controller in compliance initiatives
The processor must actively assist the controller in ensuring compliance with core UK GDPR obligations. This includes ensuring security for processing activities (Article 32), managing and notifying the controller of data breaches (Articles 33 and 34), and assisting the controller in conducting Data Protection Impact Assessments (DPIAs) and prior consultations (Articles 35 and 36).
End-of-contract provisions
At the end of the data processing and on the controller’s instructions, the processor must delete or return all personal data to the controller, deleting existing copies unless domestic law demands retention.
Audits and inspections
The processor must make available to the controller all information necessary to demonstrate compliance with Article 28 of the UK GDPR and allows for and contributes to audits or inspections conducted by the controller or a third party on the controller’s behalf.
It shall be noted Article 28 sets out the terms and clauses that are statutorily required and must always be included in a DPA for it to be considered valid. Nevertheless, the controller and processor may choose to negotiate their own contract that goes beyond the compulsory elements.
How is a DPA generally drafted?
Putting a DPA in place usually consists of the following five steps:
Select the starting template: the IC outlines what terms a DPA must contain however it does not provide a standard template. Therefore, the parties involve usually use their own bespoke template which shall be in line with Article 28 of the UK GDPR requirements.
Confirm data protection roles: clarify who is the data controller and who is the data processor.
Fill in the schedules: for instance, what personal data is collected, who are the data subjects, why it is being processed, and how long it its kept.
Agree on key terms: both sides negotiate practical points like how sub-processors get approved (general or specific authorisation), and how audits are handled.
Execute with signatures: authorised representatives execute the DPA making the agreement legally binding.
How can Zolteria help?
Instead of drafting and managing DPAs across separate Word documents, emails and spreadsheets, Zolteria allows you to manage your agreements in one central platform. You can create and store agreements, track their approval and signing status, keep track of review dates and access the latest versions whenever needed.
This makes it easier to keep track of your DPAs, avoid missed reviews and ensure agreements are properly documented.
Want to see how Zolteria can simplify your DPA management?
What happens when a DPA is not in place?
The UK GDPR imposes a legal obligation on controllers and processors to formalise their working relationship with a DPA. Therefore, non-compliance can result in severe penalties and reputational damage. Specifically, the IC can impose severe administrative fines up to £8.7 million or 2% of total worldwide annual turnover (whichever is higher) for Article 28 violations. Additionally, violations of the UK GDPR can harm organisational standing and diminish customer trust.
Synonyms and Alternative Terminology
It is possible to encounter alternative terms used to refer to a DPA. However, it is important to note that, regardless of the naming convention, the statutory obligations under data protection law remain the same.
The terms ‘Data Processing Agreement’, ‘Data Processor Agreement’, and ‘Data Processing Contract’ are used interchangeably to refer to the agreement that governs the relationship between controller and processor.
In many commercial relationships, however, data processing provisions are integrated into a broader contractual framework rather than created as a standalone document. In these cases, it is possible to see a ‘Data Processing Addendum’, which is attached as a schedule to a primary agreement, such as a Master Services Agreement (MSA) or standard Terms of Service.
Finally, major technology corporations (such as Microsoft, Google, or AWS) frequently use the term ‘Data Processing Terms’. This phrasing typically denotes a standardised, non-negotiable set of data protection terms for users.
What is a Data Sharing Agreement (DSA)?
While a DPA is a legally binding contract between a controller and a processor, a Data Sharing Agreement (DSA) is used to govern the data sharing relationship between two or more controllers.
Importantly, establishing a DSA is not explicitly mandated by the UK GDPR. However, the IC Data Sharing Code of Practice identifies DSAs as standard good practice. The IC states that executing a DSA is one of the primary ways for controllers demonstrate compliance with the accountability principle (Article 5(2) UK GDPR).
The exact structure and content are not rigidly prescribed by statute, but a DSA should generally give all parties clarity on respective roles and responsibilities, set out the exact purpose of the data sharing, define common standards for security, confidentiality, and data handling. There is no standard format for a DSA; it can take a variety of forms depending on the scale and complexity of the data sharing.
Multi-Party sharing
For data sharing in large multi-actor projects, such as public sector collaborations and research involving multiple entities, it can be difficult to ascertain the data protection role of each party based on the complex DSAs. To effectively manage these complexities, it is possible to adopt different types of DSAs, to be tailored to the specific needs of each party.
Fictional Example: The North West Secure Data Environment (SDE) and the South West Secure Data Environment (SDE) want to collaborate for the purposes of metal health research. They decide to create a new bigger centralised platform (MindVault SDE) that will be able to link mental health records across the 10 participating Integrated Care Systems (ICSs). Given the number of actors involved, Britain SDE has completed the following agreements:
Data Sharing Framework (DSF)
A Data Sharing Framework (or Data Sharing Framework Contract) is an overarching agreement between two or more parties that establishes the general terms, principles, standards, and responsibilities for sharing personal data between member organisations.
Example: the MindVault SDE Data Sharing Framework underpins personal data sharing across the ten ICSs. The document sets parties responsibilities alongside common standards for privacy, confidentiality, and information security.
Data Sharing Specification (DSS)
Building on a Data Sharing Framework, a Data Sharing Specification (DSS) defines the specific operational details of individual data sharing activities carried out by the specific entities.
Each individual DSS outlines the specificities of a project requiring data sharing between multiple members belonging to the framework. The document specifies the exact datasets to be processed, processing purposes, lawful bases under UK GDPR, and conditions under which the project will be executed.
Example: each MindVault SDE Data Sharing Specification specifically addresses how data will be shared and processed by ICS.
Data Sharing Agreement (DSA)
Depending on the specificities defined in the DSS, it may be appropriate to complete a DSA to make the sharing of data effective.
Note that beyond data sharing, it is likely that a large-scale arrangement involves relationships between controllers and processors to carry out specific activities. In these cases, DPAs must be put in place to comply with the requirements provided by Article 28 of the UK GDPR.
Combining the general terms of the overarching Framework with the specific terms of the Specification with a DSA will ensure compliance with data protection legislation in line with the IC Code of Practice on Data Sharing.
The diagram below provides an overview of the relationships and differences between the various types of sharing and data processing agreements.
Conclusion
As discussed in this article, navigating data governance agreements requires a clear understanding of legal roles and operational relationships between the various parties. Whether engaging processors with a mandatory Data Processing Agreement (DPA) under Article 28 or establishing a Data Sharing Agreement (DSA) between controllers in line with the IC Code of Practice on Data Sharing, clear legal documentation ensures accountability and transparency.
Additionally, in complex multi-party projects, parties can simplify their data governance while upholding data protection law obligations by combining Data Sharing Frameworks (DSFs), project-specific Data Sharing Specifications (DSSs), Data Sharing Agreement (DSAs) and Data Processing Agreements (DPAs).
We hope this article has provided an initial outline for everything you need to know about Data Processing Agreements and data governance agreements more in general. If you don’t know where to start in drafting your agreements, visit Zolteria and check out our templates offer.
FAQs
-
No. A DPA (Data Processing Agreement) is a mandatory contract between a data controller and a data processor. A DSA (Data Sharing Agreement) is used when two or more controllers share data with each other for their own distinct purposes.
-
Common alternative terms for a DPA include:
Data Processor Agreement
Data Processing Contract
Data Processing Addendum (when attached to a Master Services Agreement or Terms of Service)
Data Processing Terms (often used by major platforms like Google, Microsoft, or AWS)
-
Yes. Under Article 28(3) of the UK GDPR, it is a legal statutory requirement to have a binding written contract in place whenever a data controller uses a processor to process personal data.
-
Failing to put a DPA in place violates Article 28 of the UK GDPR. Regulators (such as the IC) can issue administrative fines of up to £8.7 million or 2% of total worldwide annual turnover, alongside potential severe reputational damage.
-
A Data Sharing Framework (DSF) is an overarching agreement between multiple parties that establishes the general principles, responsibilities, and security standards for sharing personal data across organisations. A Data Sharing Specification (DSS) builds on that framework by defining the exact operational details for a specific project, such as the specific datasets involved, processing purposes, and UK GDPR lawful bases.