“Processing by a processor shall be governed by a contract or other legal act…” (Article 28, GDPR)

Commonly referred to as a “data processing agreement” this type of contract governs the relationship between a controller, a processor, and the data being processed.

These contracts can come in many forms, but the EU General Data Protection Regulation now in effect, more and more organizations will be updating their vendor contracts to include a data processing agreement, or a data processing addendum.

The IAPP recently put up a draft data processing agreement as part of the upcoming book “Negotiating Data Processing Agreements.” For the next month, comments on this draft are being accepted to continue to approve this agreement. This article addresses what data processing agreements are, why they are necessary, and some key provisions they must contain.

The data processing agreement 

Data processing agreements have been around since well before the GDPR was drafted, and some companies working in data-driven fields may already have examples of these agreements in place. The Data Protection Directive, Directive 95/46/EC, had a much slimmer set of requirements for processors, and liability for ensuring compliance rested in the hands of the controller. Under the GDPR, both controllers and processors can be found liable for violations, and may face hefty fines and penalties for non-compliance. These documents will need to be updated to comply with the GDPR.

Other names for such contracts include controller-processor agreements, controller-controller agreements, or joint-controller agreements. In any situation, or under any title, these agreements lay out the ground rules for any handling of data done by a processor on behalf of a controller and are essential in preparation for the GDPR.

Why they matter

Generally, any organization that processes the personal data of data subjects in the European Union should be concerned about having updated data processing agreements in place with vendors and partners with whom they share the data.

Indeed, such agreements are required under Article 28 of the GDPR. Article 28(1) requires that a controller only use processors that provide sufficient guarantees that processing will meet the requirements of the GDPR, and this puts pressure on controllers to put a more selective, and skeptical focus when selecting processors. Having up-to-date data processing agreements in place can also protect an organization from liability in the future, and avoid the potential heavy fines and penalties possible under the GDPR.

Under Article 83, administrative fines of “up to 10,000,000 EUR, or in the case of an undertaking, up to 2 percent of the total worldwide annual turnover of the preceding financial year, whichever is higher,” may be applied for infringements of the obligations laid out in Article 28, as well as in other articles that may be implicated in a data processing agreement. Therefore, the failure of a controller to obtain these guarantees as described in Article 28 could result the application of these fines, putting a heavy responsibility on the controller’s shoulders to ensure compliance.

First steps to drafting a data processing agreement 

A pressing first question in constructing a data processing agreement is whether the organization is functioning as a controller or a processor. The IAPP has previously written in detail on the controller vs. processor determination, but in brief terms, a controller is the entity who “determines the purposes and means of the processing of personal data,” while a processor processes that personal data on the controller’s behalf. Under the GDPR, personal data is any information related to an identified or identifiable natural person. Processing is performing any operation or set of operations on personal data. The text of the GDPR obviously goes into more detail on these definitions.

In drafting data processing agreements, which category each party falls into should be clearly and precisely defined from the very beginning. This is easier said than done, of course, since one organization may play either a controller or processor role depending on the circumstances, and many times both parties are controllers.

While all of the GDPR should be reviewed in constructing a data processing agreement, the article that provides the clearest guidelines is Article 28, which dictates the requirements of a binding contract governing processing done by a processor, and the requirements of what that contract contains.

Key terms of a data processing agreement 

The exact terms of a data processing agreement will vary from organization to organization and will depend on the specifics of what processing is being done. However, Article 28 paints a precise picture of the minimum a contract should set out. These basics are: (1) the subject matter and duration of the processing, (2) the nature and purpose of the processing, (3) the type of personal data, (4) the categories of data subjects, and (5) the obligations and rights of the controller.

With this framework for the contract set, Article 28(3) lays down further stipulations that will most likely appear as specific provisions in a data processing agreement. These include:

• Processor will only process personal data on documented instructions from the controller.
• Processor’s employees are committed to confidentiality.
• Processor will take all measures required pursuant to Article 32 — which deals specifically with security of processing.
• Processor will only engage sub-processors with the controller’s written specific or general authorization.
• Processor may delete or return all personal data at the choice of the controller at the end of services related to processing.

These provisions can appear in different sections of a data processing agreement, and an organization drafting a data processing agreement will likely want to further expand on the details of each of these. For example, Article 28(3)(c), which puts in place requirements for security, may appear in a section of the contract devoted to the security measures agreed upon by a processor, and may contain additional information, such as the availability of auditing.

Other topics that may appear in data processing agreements include more detailed provisions regarding the use of sub-processors, breach notification and response, data transfers, and potentially clauses regarding indemnity.

This is not an exhaustive list of what should be in a data processing agreement, and each contract should be crafted to fit what data is being processed and, if a contract is already in place, the existing service agreement.

The field of data processing agreements is still very much uncharted territory, in these early days of GDPR, and there are plenty of concerns from organizations as to how actual compliance will work moving forward. Larger organizations may have lists of processors that they are utilizing in the hundreds, and keeping this list updated, as well as notifying consumers of changes in the list can be an incredibly daunting task.

One method to coordinating the madness is Microsoft’s running list of subcontractors with access to customer data. The list comprises well over 100 entities, and is published with the promise that the names of any new subcontractors will be published at least six months in advance of their authorization to perform services involving customer data. For smaller organizations, with much smaller lists of processors, the procedure for adding new sub-processors may be a more individualized process of notification, especially considering not many organizations will have the ability to delay service on customer for data for up to six months.

Audit requirements can prove to be burdensome to both the controller and the processor as well, especially from a financial perspective. However, proper auditing procedures laid out in agreements could save companies not only from potential fines from the GDPR, but could help avoid international attention as well. One of the lessons from Facebook’s experience with Cambridge Analytica is that contractual assurances may not be enough; in some cases, a full audit may be necessary to confirm that processors are complying with security obligation, including access restrictions, or deleting data as required.

photo credit: Stephenie Schukraft via photopin