Fixing the Data Processing Agreement (DPA) process: seven years of lessons learned
- Rock Consultancy
- Sep 10, 2025
- 4 min read
10 September 2025
How to improve the DPA process
Introduction
While we are 7 years into DPAs being a requirement for both processors and controllers under the EU General Data Protection Regulation (GDPR), they are still causing bottlenecks and can impact the overall execution of master services agreements or contracts if not managed appropriately. This article seeks to look at some of the bottlenecks and how to overcome them.
Article 28 GDPR
As per Article 28 of the GDPR (Article 28), where a controller engages another party (processor) to process personal data on their behalf, that engagement shall be governed by a contract. These are generally called DPAs or data processing schedules.
While organisations will have different approaches to contracting processes, DPAs are usually an addendum to a master services agreement or contract.
The requirements of a DPA are very clearly set out in Article 28, particularly Article 28.3. Further, the European Commission in 2021 issued a template for Article 28 DPAs. However, this does not appear to be used widely, with many companies seeking to use their own templates.
What are the issues that cause frustration and delays in completing a DPA?
The following are causing delays in completing DPAs in a timely and resource efficient manner:
Conflict on data controller, data processor roles: while traditionally every supplier/vendor was considered a processor to the client/controller, that may not necessarily be the case. At the outset, consideration of the roles for the processing activity needs to be understood and agreed.
Including items that are not strictly for a DPA: this can occur where the DPA scope is widened to include items such as confidential data or non-personal data, intellectual property (IP), and cookie compliance.
Terms that cannot be complied with: for example including terms requesting that the processor comply with the controller's data privacy policy and/or including links to such privacy policies to incorporate them into the DPA.
Onerous timelines: including very tight timelines for notification of data breaches and/or escalations of data subject complaints or data subject rights requests.
Unnecessarily onerous or even impossible downstream obligations: this can occur where a clause requires the exact wording of the DPA to be flowed down to a sub-processor.
International transfers: a clause prohibiting international transfer of personal data when the contracting entity is one that operates on a global basis.
Best practice
It is important to have a process in place for DPAs, which includes: Template(s), FAQs, and Playbook(s).
This provides negotiators with fall back positions and rationale for the organisation’s position. This minimises the risk for the organisation and ensures consistency in terms of what is being agreed to. This also limits the need for escalations within the organisation, which helps with managing resources and limiting delays in reaching DPA agreement.
Having a central record of DPAs, including date of execution is vital as part of Art 28 compliance and processor due diligence, typically as part of a central contract inventory.
If there is an impasse in relation to a clause, refer back to the European Commission’s Article 28 template and consider agreement to adopt a clause from the Article 28 template.
Where the impasse relates to a timeline for breach notification, refer back to the legal requirement (‘processor shall notify the controller without undue delay after becoming aware of an incident’), what is practical and what is best for both parties. Many organisations will insist on a very short timeframe in which a processor must notify a data breach to them. This can backfire where the processer, to meet that timeline, is not able to provide sufficient information to the controller. The controller is then in a difficult position that it has insufficient information to make an assessment. We have seen this happen where a processor notified a breach within the tight timeline required by the controller but in fact it was not a breach at all. Having a reasonable amount of time to gather information is important for both parties.
Be careful what you ask for. Some DPAs have asked that processors be notified of ‘suspected data breaches’. The GDPR does not require processors to notify ‘suspected data breaches’. Controllers who require such notification should consider why they deem that necessary and the pros and cons of such notification.
Takeaways
Review your template (s) to ensure that they reflect what needs to be within an Article 28 template. Ensure that there is a standard process with agreed fallback positions. Consider what should not be in the DPA, for example items that are more appropriate in the body of the MSA. Review DPAs that were executed around the time GDPR become enforceable (May 2018). Some DPAs that were executed at that time may need to be updated due to maturing GDPR views and guidance from the European Data Protection Board.
Further reading
For any queries on this article or how Rock Consultancy can support your organisation, please contact us at info@rockconsultancy.ie
