In 2016, the Westin Research Center published a series of articles identifying our analysis of the top 10 operational impacts of the European Union’s General Data Protection Regulation. Now, with the May 25, 2018, GDPR implementation deadline looming, the IAPP is releasing a companion 10-part series discussing the common practical organizational responses that our members report they are undertaking in anticipation of GDPR implementation.

Although the GDPR accommodates modern business practices of outsourcing data storage and analytics, as well as marketing communication and other functions, it requires that data controllers choose their data processors carefully and bind them with required contractual terms to GDPR’s risk-based standards. Thus, this ninth installment in the 10-part series discusses the necessary operational processes and legal terms needed for transferring personal data to data processors in compliance with the GDPR.

The previous installments of the series can be found here.

Operationalizing vendor management

The GDPR did not invent vendor management responsibilities. Organizations have long had procurement programs scrutinizing vendor selection on a variety of bases, from financial solvency, to service-level commitments, and beyond. Health-related privacy laws in the U.S., for instance, require business associate agreements for sending personal health information to third parties. And for information privacy and security personnel, the infamous Target data breach underscored the risk of giving third parties access credentials to secure systems housing personal data, raising risk awareness to the highest levels of management.

The GDPR takes vendor selection and agreements to a new level, however. To prepare for this, organizations should:

• Ensure that privacy professionals are notified and brought in to the discussion early for any new program or acquisition that involves sharing personal data with a third party.
• Determine whether the organization in any given transaction is serving as the controller, joint controller, or processor.
• Have the right agreements in place to comply with Articles 27 or 28 of the GDPR as appropriate, as well as Article 46 as necessary.

Get involved before the deal closes

It’s difficult to overstate the importance of having privacy and security professionals involved in vendor selection as early as possible. The best time to insist upon privacy by design in a new system, certain contractual privacy and security assurances, or favorable allocation of liability, is when considering whether to buy; after the purchase order and license agreements have been signed and payments made, the buyer has little leverage to seek technical or legal accommodations. Accordingly, privacy leaders must insist that no contracts be signed with vendors who will have access to personal data unless they have been consulted.

In many cases, the processor’s sales staff will not be equipped to provide all the privacy and security answers to the privacy team’s questions. Privacy professionals must, therefore, insist on tracking down and engaging with the vendor’s equivalent of their counterpart, if any. The vendor’s failure to have a privacy professional available — or a referral exclusively to the security team — might be a red flag that it isn’t prepared to safeguard personal data or meet other GDPR compliance concerns. 

Engaging a processor may require a risk assessment, perhaps even a data protection impact assessment, depending on the nature of the transaction and the personal data involved. These must be documented and added to any Article 30 records along with the appropriate contracts, as discussed below.

Because a crucial component of maintaining data privacy is security, the security team will also be involved in vetting potential vendors. In most situations, visiting the data processor’s facilities to conduct a personal security audit is impractical. Instead, the controller’s security professionals will need to confer with the processor’s appropriate counterparts. As well, many controllers and processors rely on security audits and certifications as proxy signals for “technical and organizational” safeguards. According to a 2017 IAPP study, the top security credentials privacy professionals seek from vendors is ISO 27001 certification, followed by SOC 2 Privacy, and PCI compliance.

Although these tools have yet to be fully developed, moreover, the codes of conduct and certifications defined and anticipated in GDPR Section 5 (Articles 40 and 42, specifically) may one day help also controllers in processor vetting and selection.

What role today: Controller or processor?

One of the most determinative distinctions under the GDPR is that between controllers and processors. Controllers bear the brunt of the regulatory burden, including having to legitimize data processing and respond to individual complaints, while processors have it easier. Organizations widely and routinely engage third parties for cloud-based data storage and processing solutions, to assist with shipping or billing processes efficiently, to enhance marketing efforts, and the like. The GDPR defines these third parties as “processors” in Article 4 as a “natural or legal person, public authority, or body, which processes personal data on behalf of the controller.” Amazon Web Services, for example, is a prototypical processor. So are, typically, the customer relations management company Salesforce, the human capital management firm Workday, and myriad other software-as-a-service (SaaS) companies supporting organizations globally. 

An organization is a “controller” if it “alone or jointly with others determines the purposes and means of the processing of personal data.” The GDPR places the bulk of responsibility and liability upon controllers. Nearly all companies — even classic processors — are controllers at some point, at least regarding their employees’ data.

Yet even controllers can sometimes serve as processors. Consider, for example, a university that produces an online course in leadership. When it offers the course itself to students, who enroll directly through the university, it is a data controller. But if the university allows businesses to “white label” the course and offer it internally to their executives, while the college continues hosting the course on its own servers, it may become a processor to the extent the system collects personal data. Depending on the circumstances — if, say, the university grants some form of certification or other acknowledgment to the companies’ executives — it may instead be a “joint controller.”

These distinctions matter because they govern the type of agreements — if any — that may need to be in place, and the terms GDPR requires in those agreements. 

Data protection agreements

Article 29 explicitly prevents processors from processing personal data except on the controller’s instructions. Article 28 provides details on documenting these instructions by written agreement.

Indeed, Article 28 has become such a significant compliance responsibility — forcing itself into daily business transactions — that if it is not printed out and taped to the wall of most privacy professionals, or marked with a dog-eared page, it probably should be.

Specifically, Article 28 requires that controllers “shall use only processors providing sufficient guarantees to implement appropriate technical and organizational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.” Processors are also restricted by Article 28 from engaging subprocessors without the controller’s “prior specific or general written authorization.” In the case of general written authorization, the controller must have notice of and an opportunity to object to additional or replacement subprocessors. 

Article 28 also requires controllers to enter into a “contract or other legal act under Union or Member State law that is binding on the processor with regard to the controller.” The contract must contain the following elements: 

• The subject matter, duration, nature, and purposes of the processing.
• The controller’s documented instructions governing the processing.
• The type of personal data processed along with categories of data subjects.
• The controller’s rights and obligations, and the processor’s promises to assist with ensuring the controller’s compliance (in particular regarding information security and breach response, as well as respecting and responding to data subject rights).
• Processor obligations to implement technical and organization security measures, to commit employees and contractors to confidentiality, to delete or return all personal data to the controller at the relationship’s conclusion, to submit to audits and otherwise provide information necessary to demonstrate compliance with Article 28, and to bind all subprocessor to the GDPR requirements as well.

Already, agreements embodying these terms are flying between controllers and processors, some of them entered — as is ideal — at the beginning of the relationships, but many following on as addenda to earlier-entered agreements. These data protection agreements or addenda contain some commonalities, but also reflect the different bargaining power of the respective parties. For example, Salesforce has produced and published on its website a pre-signed data protection addendum for its customers to download, sign, and store in their record keeping systems. These agreements, for most Salesforce enterprise customers, are not negotiable.

Smaller SaaS providers — particularly if just catching up to GDPR’s processor obligations, and especially if approached during the sales cycle rather than after the deal is signed — may yet be open to negotiating the terms of a data protection agreement and to allowing controllers more favorable treatment. Consider, for instance, the controller’s right to restrict the use of subprocessors. Under Article 28(2), controllers may require prior specific written authorization for each proposed subprocessor. Processors with leverage, however, may require controllers to agree to prior general written authorization, updating them with any newly engaged subprocessors only by adding names to a list on a website, and perhaps allowing the controller to opt-in to an automated updating email.

Article 28(7) and (8) provide that the European Commission and supervisory authorities may adopt standard contractual clauses for controller-processor and processor-subprocessor agreements. 

Data transfers outside the EU 

Article 28 agreements must also address any transfers of personal data outside of the EU. Although the Regulation does not discourage businesses from seeking the most effective and efficient solutions to their information management needs, regardless of geography, it does require that care be taken to safeguard the personal data internationally. 

In general, personal data can be transferred to a third country only if certain conductions are met by both the controller and processor. These conditions include that the third country has achieved an “adequacy” designation under Article 45, or that the controller or processor has taken upon themselves to provide “appropriate safeguards” under Article 46.

Among the appropriate safeguards are binding corporate rules (further described in Article 47), approved codes of conduct or certification mechanisms, or “standard data protection clauses” adopted by the Commission or by a supervisory authority (and approved by the Commission). Contractual clauses between controllers and processors may also suffice, under Article 46(3), subject to the authorization from the competent supervisory authority. One example is the AWS data protection addendum, which has Article 29 Working party approval.

While awaiting standard data protection clauses under the GDPR, controllers and processors continue to use the model clauses published by the European Commission pursuant to the Data Protection Directive, even as the adequacy of this mechanism is challenged in European courts. Accordingly, appended to many data protection agreements or addenda are additional contractual terms often named “Standard Contractual Clauses” with annexes setting describing the data exporter and importer, the particular data processing activities involved, and the appropriate security measures employed to safeguard the data.

Conclusion

Each of the top 10 operational responses to the GDPR build upon each other. Data mapping and inventory, as well as record keeping, require knowledge of what personal data is being processed as well as to whom it is transferred. Controllers must be keenly aware of where data lives and with which third parties, and must disclose this information to data subjects as part of their transparency obligations. Data processors must be obligated by contract to employ appropriate security measures and promptly notify controllers of data breaches happening on their watch. As part of their governance systems, privacy leaders train staff to engage the privacy team early in the vendor review process — before the vendor is finally selected and before any deals are signed. In many cases, a risk assessment will be required — if not a DPIA — as part of vendor evaluation. This will facilitate selecting GDPR-aware vendors who will work cooperatively with controllers in fulfilling their mutual obligations.

Photo credit: ThoroughlyReviewed Legal Contract via photopin (license)