A Data Processing Agreement (DPA) is the contract between a controller and a processor that satisfies [GDPR art. 28]. miniterms generates a DPA on the paid tier. This page covers when you need one, what the generated document contains, and how to actually sign it with a processor.
When you legally need a DPA
You need a DPA whenever you (the controller) entrust personal data to a third party (the processor) who handles it on your behalf. Typical scenarios:
- A cloud hosting provider that stores your customer data (AWS, Hetzner, OVH)
- An email sending provider (Resend, Mailgun)
- An analytics provider that handles user identifiers
- A support tool that ingests customer messages
- A sub-contracted developer with production access
You do not need a DPA for:
- Pure software vendors you self-host (e.g. a static site generator that never sees user data)
- Tools that handle only your company's internal data (e.g. your accountant for your own books — they are themselves a controller, not your processor)
When in doubt, the question is: "Does the third party process personal data on my behalf, under my instructions?" If yes, a DPA is required.
What miniterms generates
The miniterms DPA is structured to satisfy [GDPR art. 28(3)] paragraph by paragraph. It includes:
- Subject matter and duration of the processing, derived from your profile
- Nature and purpose of the processing
- Type of personal data and categories of data subjects
- Obligations and rights of the controller (you)
- Processor's obligations — Art. 28(3) (a) through (h), each as its own clause:
- Process only on documented instructions
- Ensure persons authorized to process commit to confidentiality
- Take all measures required by Art. 32 (security of processing)
- Conditions for engaging another processor (sub-processor approval)
- Assist the controller with data subject rights
- Assist with Art. 32–36 obligations (breach notification, DPIA)
- Delete or return personal data after end of services
- Make available information necessary to demonstrate compliance + allow audits
- Sub-processor list — initial list with right to object to changes
- Schedule of technical and organizational measures (TOMs)
- International transfer mechanism — SCCs (Standard Contractual Clauses) where the processor is outside the EEA
How to actually sign it
A DPA only protects you when it is signed. The practical workflow:
- Generate the DPA in miniterms with your details pre-filled as the controller
- Identify the processor's existing DPA. Most large processors (AWS, Stripe, Resend, etc.) publish their own DPA you must sign on their portal. In that case, you do not use the miniterms DPA for that vendor — you accept theirs.
- For vendors without a published DPA (smaller contractors, niche tools), export the miniterms DPA, fill in the processor's details, and send it for signature. We do not include e-signature today; use any e-signature tool (DocuSign, Signaturit, or even a manually-signed PDF).
- Store the signed DPA somewhere you can produce on demand. The AEPD can request it during an inspection.
When the processor proposes their own DPA
Big vendors will usually push their own DPA on you. Read it before signing. Things to check:
- Sub-processor list is published somewhere stable and they commit to notifying you of changes
- Audit rights exist (even if exercised through a third-party auditor's report)
- Security measures are listed with specifics, not just "industry standard"
- International transfer mechanism is current — pre-Schrems-II language is a red flag
If their DPA is solid, sign it. The goal is not to use the miniterms-generated DPA everywhere — the goal is to have a signed DPA on file with every processor.
This page describes the workflow; it is not legal advice on whether a specific contract is sufficient for your case. Have counsel review your DPA register if you process special category data or process at scale.