A GDPR data processing agreement should match the real controller-processor relationship and the service that will process personal data. Start with the operating facts, then test the contract against Article 28; a template label cannot establish the parties' roles or make an inaccurate processing description true.
GDPR Article 28 requires the contract or other binding legal act to state the subject matter and duration, nature and purpose, types of personal data, categories of data subjects, and the controller's obligations and rights. The requirements below explain what the business and its qualified advisers need to connect to the actual service.
1. Confirm the parties, roles and processing description
Record the exact contracting entities, service modules, customers and users. Describe who determines the purposes and essential means for each activity, and flag any activity that does not fit the proposed controller-processor allocation.
The processing schedule should identify:
- subject matter, nature, purpose and duration;
- categories of people and personal data;
- documented instructions and permitted use;
- storage, support and administrator locations; and
- return or deletion behavior during and after the service.
Compare the schedule with the order form, product settings, architecture and privacy notice.
2. Reconcile documented instructions and confidentiality
Check how the customer gives and changes instructions, how the processor records them, and what happens if an instruction appears unlawful. Identify the people authorized to process the data and the confidentiality commitments that cover them.
Do not promise that every customer request can be implemented instantly. Record the actual intake route, product limits, escalation owner and any separately scoped work.
3. Build the subprocessor record from production reality
List every cloud, database, observability, support, communications and AI provider that can process customer personal data. For each one, record the legal provider, service, purpose, location, contract and current production status.
Then compare the DPA's authorization, notification and objection process with the team's real vendor-change workflow. A subprocessor page is useful only if someone owns its accuracy and the notice route works.
4. Test security and incident promises against evidence
Map access control, encryption, logging, vulnerability management, recovery, personnel controls and incident response clauses to current evidence. Confirm the entity, service and period covered by certifications or audit reports.
For incident notice, record what starts the contractual clock, who receives the alert, who investigates, who approves customer communications and what facts can realistically be supplied at each stage.
5. Verify assistance, audits, return and deletion
Article 28 addresses assistance with data-subject rights and specified controller obligations, access to compliance information, audits, and return or deletion after the service. Test each promise as an operating workflow:
- Who receives and verifies a rights request?
- Can the relevant systems and subprocessors locate the data?
- What evidence can be supplied for an audit or assessment?
- Which export formats and timelines are available?
- What remains in backups, logs or required retention after termination?
Record exceptions and manual dependencies rather than hiding them behind a broad promise.
6. Keep international transfers as a separate workstream
Identify where personal data is stored and where personnel, affiliates and subprocessors can access it. If standard contractual clauses or another transfer mechanism may be used, collect the correct parties, module, annex facts and assessment evidence. Transfer wording should follow the mapped flow, not replace it.
7. Prepare a negotiation matrix
For each requested change, record the clause, customer objective, current capability, operational owner, evidence, proposed position, fallback and question requiring legal interpretation. This keeps legal wording connected to delivery and exposes promises the product cannot yet support.
Use the data processing agreement checklist to create the first action map, or review JurisLane's data and AI compliance preparation scope. The tool organizes user-supplied facts; it does not approve a DPA or determine GDPR compliance.
Source review
The EUR-Lex GDPR text and European Commission SCC page above were checked on 2 September 2026. Confirm the current law, guidance and contract facts with qualified advisers before execution.
Sources
Editorial note: This guide supports issue preparation and qualified review. Applicable requirements depend on the facts, entities, markets and current law.