Privacy professionals have been involving themselves in their organizations’ vendor management programs for a few years now. Indeed, according to the 2016 IAPP-EY Privacy Governance Survey, 70 percent of respondents (up from 63 percent in 2015) were involved in a formal vendor management program — and the numbers are just as strong in this year’s upcoming report.

So why am I — as the IAPP’s new data protection officer — suddenly seeing so many new (and, let’s face it, onerous) privacy and security provisions in otherwise standard contracts?

We all know the answer: the GDPR.

Article 28 has everyone excited

The EU General Data Protection Regulation, set to come into force in May 2018, uses the important terms “controller” and “processor” to describe two general categories of organizations that process personal data.

We have discussed these roles in depth in our Top Ten Operational Impacts of the GDPR series, but I’ll review them briefly again.

A controller is the person (natural or legal) who “determines the purposes and means of the processing of personal data,” whereas a processor is the person who processes personal data on the controller’s behalf. When one visits the dentist for a cleaning, for example, the dentist collects personal information to provide the services, and thus the dentist is a controller. Any entity that processes the personal information for the dentist — the billing company that sends the final invoice, or the imaging company that develops the X-rays — is a processor.

These distinctions are important for several reasons. For one, the controller bears more responsibility — and liability — for managing the personal data. Controllers are obliged to perform data impact assessments, respect data subjects’ individual rights under the GDPR, and notify supervisory authorities in the event of a data breach.

Controllers are also responsible for selecting and monitoring reliable processors. Specifically, controllers may use only those processors that provide “sufficient guarantees” that they have or will “implement appropriate technical and organizational measures” to meet the GDPR’s requirements and ensure data subject rights are protected. These guarantees are typically provided in a contract, and Article 28(3) of the GDPR spells out what the contract must stipulate:

• Processing will occur only as consistent with the controller’s documented instructions.
• The processor’s employees are committed to confidentiality.
• The processor will implement appropriate technical and organizational security measures under Article 32 and cooperate with the controller in the event of a data breach.
• No sub-processors are allowed without the controller’s written authorization.
• The processor will assist the controller with respecting data subjects’ individual privacy rights, as well as with DPIAs as necessary.
• The processor will follow the controller’s instructions to delete or return personal data when the relationship concludes.

The processor also must agree to “make available to the controller all information necessary to demonstrate compliance with the obligations” of Article 28, which may include contributing to audits and being available for inspections. What is more, Article 28 also requires the processor to “immediately inform the controller if, in its opinion,” the controller’s instruction infringes the GDPR or any other member state or EU data protection law. Look carefully for these provisions in processor-drafted data protection agreements; they may be hard to find.

Contracts versus the law

Violating a law exposes an organization to enforcement actions by government regulators and potentially to litigation by data subjects or their public advocate representatives.

Violating a contract exposes an organization to liability vis-à-vis their business partner. It is therefore important to understand when a contractual obligation is merely a restatement of what the law already requires, and when it goes beyond what the law requires and imposes an additional obligation between the parties.

Some of what I am seeing as the IAPP’s DPO are controller-controller relationships, rather than controller-processor relationships. This may be the case, for example, in business-to-business situations where a company purchases services for its employees from another company.

Article 26 governs joint controller situations. It obliges the parties “by means of an arrangement between them” to determine their respective responsibilities for GDPR compliance, reflecting the parties’ respective roles and relationships vis-à-vis the data subjects involved. These arrangements may involve a formal contract containing provisions similar to those spelled out in controller-processor arrangements under Article 28, but, if so, that will be a choice the parties make in entering a private contract rather than an obligation required under the law.

Controllers who agree to processor-style arrangements may be undertaking duties in contract that are not imposed by law.

Where does the DPO stand?

Each organization will select a DPO with the skill set and background to fit its needs, and some may be more involved in contract negotiation than others. I happen to believe it’s possible to help your organization avoid accepting more contractual duties than legally necessary and still look out for the rights of data subjects.

The key to this approach is risk management, including an assessment of the data subjects’ risks. In a controller-controller situation, both parties have legal duties to data subjects under the GDPR. Adding duties to each other under contract may enhance the risks of contract breach without enhancing the rights and freedoms of data subjects.