Definition · Plain-language
Data processing agreement (DPA)
A data processing agreement is the contract, required by GDPR, that governs how a data processor handles personal data on behalf of a data controller.
The step most authors miss
Doing CRediT right? Don’t stop at the statement.
A CRediT statement credits you inside one paper. The recognition CRediT was built for happens when those roles are tied to you, persistently. Sign in with your ORCID — free — and claim your CRediT contributions on casrai.org, the home of the standard. They become a verified, portable part of your identity, not a line that disappears into one PDF.
Free: claim your contributions, then export a journal-ready CRediT statement, schema.org structured data, JATS XML, CSV or BibTeX — and preview your public profile. A membership publishes that profile publicly and verifies the journals you serve.
Why a DPA exists
When a controller uses a processor, GDPR Article 28 requires a binding written contract — commonly called a data processing agreement. Its purpose is to keep accountability intact when handling is outsourced, ensuring the processor cannot use the data for its own ends. The DPA documents that the processor acts only on the controller’s instructions and provides the controller with assurances and contractual remedies. It is the formal mechanism that ties the controller and processor relationship to GDPR’s expectations.
What it must contain
Article 28 specifies a set of terms a DPA must address. These include the subject-matter and duration of processing, its nature and purpose, the types of personal data and categories of data subject, and the obligations and rights of the controller. The processor must commit to confidentiality, appropriate security, assisting with data subject rights and breach duties, engaging sub-processors only under defined conditions, and returning or deleting the data at the end of the engagement. The aim is a clear, enforceable allocation of responsibilities.
DPAs in research collaborations
Research teams routinely engage external services — cloud platforms, transcription, analysis tools — that act as processors. Putting a DPA in place clarifies security expectations and who is responsible for what, which protects participants and supports trustworthy data sharing. Where data moves across institutions or borders, the DPA often sits alongside other safeguards. Treating these agreements as part of project setup, not an afterthought, keeps the chain of accountability for personal data clear from start to finish.
Key facts
At a glance
- Definition: contract governing a processor’s handling of personal data for a controller
- Source: GDPR Article 28(3)
- Trigger: required whenever a controller engages a processor
- Core term: processor acts only on documented instructions
- Must cover: security, sub-processors, breach support, data return/deletion
- Purpose: preserve accountability when processing is outsourced
Common misconceptions
What people often get wrong
Often heard: A standard service contract is enough; a separate DPA is optional.
Actually: GDPR Article 28 requires the specific data-processing terms to be in place whenever a processor is engaged. They may sit within a contract, but the required content is mandatory, not optional.
Often heard: A DPA shifts all responsibility for the data onto the processor.
Actually: The DPA allocates duties but the controller retains primary accountability for the processing. It binds the processor to instructions rather than absolving the controller.
Often heard: Once a DPA is signed, the processor can choose any sub-processor it likes.
Actually: A DPA must restrict sub-processing to defined conditions, typically requiring the controller’s authorisation and passing equivalent obligations down the chain.
Going deeper
