Lawyer
Expert in international corporate, IT, and crypto law. Has extensive experience in business setup and support in the USA, EU, LATAM, and the Middle East. Specializes in corporate structuring, compliance, KYC/AML, IP, GDPR, as well as regulation of crypto and fintech projects.
Data Processing Agreement (DPA) for GDPR
DPA (Data Processing Agreement) is not a “legal accessory” to a contract with a contractor. It is a document that makes the processing of personal data manageable: who has entrusted what to whom, what data is processed, how it is protected, to whom it is transferred, how it is returned/deleted and who is responsible if something goes wrong.
GDPR requires that there is a contract (or other legal act) between the controller and the processor with clearly defined processing conditions and control of the chain of subcontractors. This is not “good practice”, it is basic compliance hygiene.
DPA in simple words: who with whom and about what?
There are two key roles in the GDPR:
- Controller (owner/the one who determines the purposes and means) — decides “why” and “how” the data is processed.
- Processor (processor) — processes data on behalf of the controller and only according to documented instructions.
A DPA is needed when you, as a controller, engage a contractor who has access to personal data: CRM, call center, email marketing, accounting, HR services, hosting, analytics, support service, dev team, etc.
When is a DPA almost always needed (and when is it not)?
A DPA is almost always needed if:
- the contractor has access to your customer/user base;
- the contractor hosts services/backend/logs;
- the contractor provides support and sees profiles/history of requests;
- the contractor provides mailings/targeting/behavioral analytics;
- the contractor processes employee data (HR, payroll, recruiting).
A DPA may not be needed if:
- the contractor is a separate controller, because it determines the purposes/means of processing itself;
- you have a controller-to-controller model (there is a different logic of obligations and responsibilities).
The most common problem is incorrect qualification of roles. One paragraph “processor/controller” in the contract does not cure the actual reality.
Mandatory conditions of DPA: what should be inside (checklist)?
Minimum “must-have” set (in essence, the requirements of Art. 28 GDPR):
- Subject matter and boundaries of processing: what is processed, for which services, in which systems.
- Duration, nature and purposes of processing.
- Data categories and categories of subjects.
- Documented instructions of the controller (how are they issued, who approves).
- Technical and organizational security measures (TOMs) (logic of Art. 32 GDPR).
- Subprocessors: procedure for involvement, register, notification of changes, objection mechanism, “flow-down” obligations.
- Controller assistance: requests from subjects (DSR), DPIA, interaction with the regulator, incidents/leaks.
- Return/deletion of data after completion of services (including backup policy).
- Audits/inspections and provision of information to demonstrate compliance.
- Processor personnel confidentiality (NDA, role-based access, training).
Cheat sheet: DPA structure “without hysteria”
| DPA block | What do we record? | Why do you need it? |
| Description of processing | subject/objectives/duration/systems | removes “fuzziness” and disputes about boundaries |
| Data and subjects | data types, categories of persons | correct TOMs, DPIA, transfers |
| Instructions | how they are issued, who approves, SLA | proof of “documented instructions” |
| Security (TOMs) | encryption, access, logging, reserves, SDLC | reduces the risk of incidents and claims |
| Subprocessors | list + update + right to object | supply chain control |
| DSR/breaches/DPIA | terms, channels, responsible | so that you don’t “burn” in the regulator’s deadlines |
| Audit | format (SOC2/ISO/online), frequency, NDA | balance of control and realism |
| Termination | delete/return, backups, confirmation | “clean exit” without tails |
Subprocessors: where do companies lose the most?
Almost every processor has a chain of subprocessors (cloud, logging, support, analytics). Practical minimum that should be in a DPA:
- Subprocessor List;
- Change Notice procedure;
- Objection workflow and what to do next;
- Flow-down: the same security/privacy requirements “down the chain”.
In short: if you don’t control the subprocessors, you don’t control the risk.
And what if there are international transfers? (SCC and “single architecture”)
If the data goes outside the EEA/UK (or there are non-EEA in the chain), a single DPA may not be enough – a transfer mechanism (often an SCC) and an agreed set of applications/measures are needed.
A healthy approach: do not produce documents “for the sake of checking off”, but assemble one logical structure: main agreement + DPA/Annex + transfer conditions (if necessary).
Typical mistakes (and why they are more expensive than a lawyer)
- “Universal DPA on 2 pages” without a description of the actual processing.
- TOMs as marketing (“we are very safe”), without specifics.
- No mechanics of subprocessors and change notifications.
- Audit: either “forbidden” or “come every week” (both options are bad).
- Termination without delete/return and without logic for backups.
- No SLA for DSR/incidents — and then it’s your fault, because the deadlines are yours.
How do we usually do a DPA “turnkey” (process)?
- Qualify roles: controller/processor/joint controllers.
- Describe processing (Annex): systems, flows, data categories, accesses.
- Fix TOMs for service and risk profile, not “copy-paste”.
- Subprocessors: registry + governance + flow-down.
- Transfers: SCC/additional measures — if necessary.
- Negotiate with vendor: bring DPA to a realistic but protective standard.
5 “yes/no” questions for self-check
- Does the contract with the contractor describe the subject/purposes/term of processing and data types?
- Is there a TOMs/Annex that corresponds to your service, not a template?
- Is there a registry of subprocessors and a notification/objection procedure?
- Are the deadlines and procedure for DSR/incidents/DPIA prescribed?
- Is there an “exit plan”: delete/return + backups + confirmation?
If the answer to at least two questions is “no” — your DPA is probably decorative.
What can we do for the client (briefly, in essence)?
- Preparation of DPA (Article 28) with annexes for a specific service.
- Redline of the vendor’s DPA + risk matrix (what is critical, what is traded).
- Governance of subprocessors and the transfer part (if non-EEA).
- Due diligence package: description of TOMs, responses to partners/clients, audit logic.
DPA is like an umbrella: when you have it, rain seems like a small thing; when you don’t have it, suddenly the regulator appears and it turns out that you got wet, and the contractor is somehow to blame.
Calculate the cost of services
1 question
Do you need a consultation on GDPR?
2 question
Are you interested in developing a Data Processing Agreement for your company?
3 question
Do you need full fintech compliance for your business?
You may also need:
Opening corporate accounts in Ukraine for non-residents
Read more
Mediation of corporate disputes
Read more
Assessment of corporate rights of the enterprise
Read more
Pledge of corporate rights
Read more
Assessment of corporate rights
Read more
Introduction of corporate rights to the authorized capital
Read morecall back
during the day
Telegram
Viber
WhatsApp
Facebook
Instagram