Data Processing Agreements: Navigating the Essentials for Data Protection Compliance (Part 2)

In our second blog post about data processing agreements (DPA), we go further into detail and dive into practical scenarios and key provisions, building on our previous discussion about the essential elements under the EU General Data Protection Regulation (GDPR) and the Swiss Federal Act on Data Protection (FADP). This time, we will focus on practical tips and strategies from our LEXR best practices to help you avoid common pitfalls. 

Data ownership 

Defining data ownership can also be addressed in DPAs. Typically, these clauses simply aim to specify that the personal data remains the property of the controller, even while being processed by the processor. However, sometimes these clauses go beyond personal data and also address the potentially very valuable ‘ownership’ of non-personal data.  

In the legal landscape, the concept of ´data ownership´ is a difficult one since data (personal or otherwise), in itself, isn’t ‘owned’ in the traditional sense. However, the essence of data ownership clauses in DPAs lies in determining who has the right to make decisions regarding the personal data processed and exert control. In a DPA, the controller takes this role, while the processor is instructed to process the personal data on behalf of the controller within defined limits. 

While the DPA outlines specific data processing details, the broader rights and responsibilities related to the ownership of non-personal are often better placed in the base agreement connected to the DPA. This separation allows for a more comprehensive treatment of rights and responsibilities without cluttering the DPA, which is specifically focused on processing details and the necessary legal clauses from a data protection perspective. 

It is recommended, however, for DPAs to explicitly state that all data collected and processed belongs to the controller. This is due to the fact that under data protection rules, the controller is the responsible person for the data processing. The processor must operate strictly under the controller’s instructions, as well as either return or delete the data post-termination, as we have described in our earlier blog post, emphasizing the role of the processor as an entity acting solely under the controller’s directives. 

Thus, when drafting a DPA, it’s imperative to align with the roles and data ownership rights defined in the base agreement. An incongruity between the two documents can lead to complex legal implications. In scenarios where the base agreement grants a party certain ownership rights over personal data, but the DPA designates that party as a mere processor, challenges arise. Consider a newsletter service provider is allowed, under the base agreement, to send their own advertisements to their clients’ mailing lists. By including this in the base agreement, the parties automatically transform the processor into a controller for these advertising purposes. Thus, synchronizing roles becomes critical to avoid unintended legal consequences. 

Audit Rights 

Audit rights are necessary for ensuring compliance with data protection laws and fostering transparency in data processing relationships.  

According to GDPR, it is mandatory for DPAs to define that the processor must provide the controller with all necessary information to demonstrate compliance with GDPR obligations. This includes facilitating and contributing to audits and inspections, whether conducted by the controller or an auditor appointed by the controller.  

However, while doing so, it is essential for both controllers and processors to be aware that while they cannot remove the controller’s right to audit, they can make it further detailed by defining certain elements of this right: 

• Scope of audits: it is advisable to define the scope of audit rights within the DPA clearly. This includes determining whether on-premise audits are permissible or if audit rights are limited to accessing and inspecting the processor’s records, such as records of processing activities and registers of recipients of personal data.

• Costs: addressing the division of audit costs is crucial for practical implementation. Typically, the DPA designates the controller as responsible for covering the costs associated with audits, including those of an independent auditor. It is also important to bear in mind that however the costs are distributed, the parties shall not include clauses that imply disproportionate or excessive fees, thus dissuading the controller’s right to audit. So, when drafting these clauses, the parties need to ensure that the costs are not so high for the controller that, in practice, it would never exercise its right. 

• Limitation of information access: to protect the processor’s confidentiality, the DPA should outline the information accessible during audits. Access should be restricted to information necessary for the purposes of the DPA, safeguarding business secrets and other proprietary information of the processor. 

• Audit periodicity and notice: the DPA may establish the frequency of audits and the notice period required before conducting an audit. This provides predictability and allows the processor to prepare for the audit adequately. For example, the DPA could state that the controller may conduct up to a specified number of audits per year, and a notice period of a specific number of days shall be given before initiating an audit. 

Addressing liability, indemnity, and risk allocation

The allocation of risk between the data controller and data processor can be a critical aspect of the DPA. In this sense, there are typically two key clauses when dealing with risk allocation: 

• Liability clauses: liability clauses determine under which circumstances and to what extent one party has to cover the damages it causes to the other party. Typically, the parties agree already on a liability regime under the base agreement that also applies to the DPA. However, it is common that liability caps do not apply to breaches of data protection laws and, as such, liability is not often uncapped.  

• Indemnity clauses: indemnity clauses are broader in scope than liability clauses and typically allocate the risks of third-party claims such as claims by data subjects or fines by regulators against one party. Under the statutory regime of Art. 82 GDPR, both the controller and the processor can be liable towards the data subjects directly. However, if e.g, the processor paid the damage to the data subject in full even though it acted in accordance with the instructions of the controller, the processor can claim back the damage from the controller. The internal risk allocation of Art. 82 GDPR can be expanded, e.g., to not only indemnity for the damages, but also for the legal costs incurred. 

When including these clauses in your DPA, it is important to bear in mind that it is not possible to relieve either party of their responsibilities under the GDPR. Art. 82 GDPR establishes minimum standards for liability for damages. In a few recent decisions, the European Court of Justice (ECJ) has clarified some aspects of these norms. Regarding DPAs, the ECJ, for example, decided that a controller is not liable if a processor processes personal data for its own purposes, if it acts in a way that is incompatible with the arrangement between the parties, or if it is reasonable to conclude that the controller did not agree to the processing. If this occurs, then the processor is treated as a controller and liable for its own actions. 

Clear and well-defined liability and indemnity clauses protect the interests of both parties involved in data processing and provide a framework for addressing accountability in the event of data breaches or compliance issues. However, these clauses should be well drafted in accordance with data protection laws as well as national civil law aspects that are applicable and may differ from country to country. 

Timeframes

While the GDPR enshrines specific timelines for certain actions, such as reporting data breaches within 72 hours to supervisory authorities if they pose risks for data subjects, many aspects are left to be determined on a case-by-case basis. With that in mind, there are certain elements that the parties need to consider as best practices when defining the appropriate timeframes within their DPAs: 

• Timeframes for deletion/return of personal data after the termination of the agreement: parties may agree that data should be returned immediately after contract termination or within a specified timeframe, such as one week or one month. It’s also important to understand that processors might need to retain data for extended periods to comply with other legal obligations; 

• Informing controllers about data breaches: swift response to data breaches is paramount. While controllers must inform supervisory authorities within 72 hours under GDPR rules, processors should notify controllers promptly when they become aware of a data breach. Including a specific timeframe in the DPA (usually between 24 and 48 hours) for processors to inform controllers enhances transparency and ensures timely response to possible data breaches; 

• Period to object/authorise new sub-processor: In cases where controllers grant general authorization for the usage of defined sub-processors, any alterations should be communicated promptly. Establishing a specific period for notification, allowing controllers time to object, is crucial. While the appropriate period may vary from situation to situation, a recommended starting point is giving the controller a 30-day notice before the processor engages a new sub-processor. If the controller does not object within that timeframe, then the processor may proceed with the new sub-processor. This gives controllers a reasonable window to assess and object to the proposed changes. Furthermore, as the consequences of objection is not expressly regulated in the GDPR, it is also important to include them in the DPA. This can include, for example, the possibility for the controller to terminate the main agreement if the processor is unable to use another sub-processor. The same applies for cases where the controller gives a specific prior authorisation to the processor, instead of a general one within the DPA. The main difference is that the notice given is not for objection, but for authorisation. In practice, this means that if, after the defined period, the controller does not authorise the processor to use a certain sub-processor, then it shall refrain from doing so. 

Conclusion

Keeping DPAs lean but at the same time legally sound and practically effective can be a challenge. In addition to the clauses mandatory by data protection laws (which we discussed in part one of this series), DPAs should also address the following topics: 

• Data ownership: emphasize that the controller keeps the right to make decisions regarding the personal data, despite processing by the processor. Although details on the question of “ownership” and usage rights are better negotiated in the base agreement, it’s imperative to align the roles and rights defined in these two documents (DPA and the base agreement) to avoid incongruity and complex legal problems; 

• Audit rights: Even though audit rights of the controller cannot be waived in a DPA, defining details such as scope, cost, information access, and periodicity of audits can enhance transparency and avoid lengthy discussions in case of the exercise of this right by the controller; 

• Addressing liability: Including detailed indemnity and liability clauses bring extra clarity to both parties in data processing agreements. These clauses delineate responsibilities and potential financial repercussions for non-compliance; 

• Timeframes: You should set specific timeframes for data deletion/return, data breach notifications, and sub-processor authorization processes. These timeframes are essential for operational clarity and should reflect the actual business capabilities of both parties.