This is the monthly edition of ‘Ask the DPO’. Our head of DPO Services, Guy Bakshi, looks at frequent questions that the DPO is asked. This time, we look at Data Processing Addendums (DPAs).
Privacy laws in Israel and abroad require data controllers to enter into data processing addendums with their processors whenever those processors are given access to the controller’s personal data.
In Israel, the obligation is based on Regulation 15 of the Protection of Privacy (Data Security) Regulations (and on the Privacy Protection Authority’s guidance on the use of outsourcing services for processing personal data). In Europe and the UK, the GDPR imposes the obligation under Article 28; in California, it is anchored in Section 1798.140 (the definitions section) and baked into the definition of a “Service Provider.”
A Data Processing Addendum (DPA) is intended first and foremost to govern how the processor handles personal data and to define the boundaries: the permitted processing activities, the types of data to be processed, the categories of data subjects, and more.
The title, form, and certain nuances of the DPA may vary depending on the applicable law or regulation. That said, there are points worth paying attention to in any kind of DPA between a controller and a processor. Here are a few important ones to keep in mind.
Processing details. Every DPA should include a specification of the personal data, the processing (its nature and purposes), and the relevant categories of data subjects. This is the factual framework to which the DPA applies. Whether you are on the processor’s side or the controller’s side, make sure to define the details clearly to eliminate any doubt about what is covered under the DPA (and what is not), but without getting drawn into excessive specificity. A good DPA is one that sets clear boundaries and is capable of covering and accommodating foreseeable developments, even if they are not yet applicable or relevant at the time of signing. That way, you will not have to update the DPA following every small change in practice, and no small change in practice will amount to a breach of it. For example, define the types of data processed broadly enough, but not in a way that extends to types of data not needed to provide the service. Be precise about the purposes of the service so that you do not need to specify the data details at an overly granular level. At the same time, beware of over-generality that blurs the line between what is permitted and what is not, while still protecting your interests.
Inconsistencies. Are you reviewing a DPA you received from a processor? Make sure to check the service agreement or terms of service as well (for self-serve online services), and look for anything related to privacy, data use and anonymization, protection of personal data, data security, and anything else that may be relevant. Make sure the DPA also includes a document specifying the technical and organizational measures (TOMs) for securing and protecting the data, whether as an attached schedule or as a reference to a digital document on the processor’s website. This is an integral part of the DPA. You may be surprised to find inconsistencies between the provisions of the DPA and the security documentation (for example, regarding notification of data security incidents). Insist on coherence between the definitions and obligations in the DPA and other binding documents.
Data transfers. Data transfer clauses appear in almost every DPA. This is one of the most sensitive issues for controllers, particularly European controllers or those who process sensitive data. As a controller, make sure the data transfer clause covers you properly. Not only with respect to the transfer between you and the processor, but also with respect to onward transfers down the supply chain. As a processor, be careful not to commit to things that will be operationally difficult for you down the road. Processors dealing with large clients do not always have the bargaining power or the willingness to raise too many comments on the DPA to avoid friction and delays. Even so, certain clauses are worth the delay and the data transfer clause is one of them. For instance, if you have committed to several clients not to transfer data outside the U.S., and your operations as a processor have expanded globally, with offices and staff in other territories as well, then those employees’ access to the data is prohibited, because access to data equals processing of data and constitutes a data transfer. Found a localization clause? Pause. Make sure it does not constrain you in the future. Instead of a general prohibition on transfers, require that adequate and reasonable safeguards be in place – ones you can commit to.
Anonymization and service/product improvement. Anonymizing personal data equals processing personal data. The act of anonymization is itself a processing activity performed on personal data, and processors may process personal data only in accordance with the documented instructions they receive from the controller. One plus one equals two: if you want to anonymize your customers’ personal data and use the outcome to improve your service and product, you must obtain a written instruction from the controller within the DPA. Make sure to include a provision in the DPA that allows you to do so in a reasonable and proper manner. The need is clear; how you present it and persuade the controller is key. Make sure the controller permits this subject to acceptable safeguards and limitations. Are you a controller? Watch out for anonymization clauses that are not in the DPA you received from the processor. Some processors tend to “hide” the anonymization clause in other documents, such as the terms of service or the service agreement itself. Whether you are a processor or a controller, improving the service and product is a necessary and legitimate need. Address it properly in advance to prevent problems later on. That said, be aware that addressing anonymization in the DPA is not the end of the story. The GDPR, for example, imposes additional obligations on organizations that carry out anonymization – obligations that are external and unrelated to the DPA.
Be reasonable and rational. This is a general comment. Whether you are drafting the DPA template you will use as a controller, or drafting the customer DPA template you will use as a processor, be reasonable and fair without giving up your must-haves. For example, a personal data breach notification clause requiring a processor to notify the controller within 24 hours will probably face pushback from the processor to extend the reporting window to 48 hours (except, of course, in cases where reporting within 24 hours is a must-have). A draconian restriction on transferring data out of Europe, while ignoring the fact that the GDPR permits transfers to non-adequate countries (such as the U.S.) under certain conditions, is not necessarily essential or beneficial and may even cause unnecessary difficulties or delays. Understand the market you operate in, learn the industry standard, and remember your goal: to keep doing business while safeguarding and protecting personal data.
