CoC for Cloud Service Providers is now underway

It’s been announced last week that the EU Data Protection Code of Conduct (CoC) for Cloud Service Providers is now underway.

Designed as a safeguard for the international data transfers under the GDPR Article 46(2) in a post-‘Schrems II’ world, the CoC might become an interesting one by itself. At the same time, it still leaves us with the same question like SCC upheld by the CJEU: how a formal legal mechanism can remediate inadequate privacy practices in a third country?

After the Privacy Shield (PS) invalidation, a suggestion to migrate to the SCC to continue EU-US data transfers looks weird because a formal change of an underlying legal mechanism actually change nothing in defective privacy practices of the US intelligence. If we replace USA with another random third country with similar practices and/or take CoC instead of SCC – the conclusion will remain the same.

To that end, it is highly questionable that a CoC is able to become a ‘window’ to America (as currently expected). At the same time, let us see how this will work in real life. Indeed, if SCC can factually be deemed as a proper safeguard instead of PS (despite the conflict with common sense), why CoC cannot?

Do new Guidelines 07/2020 ‘on the concepts of controller and processor in the GDPR’ (‘Guidelines’) really help to identify joint controllership?

Allocating roles within a group of different actors might often become very difficult, in particular when drawing a line between joint decisions and separate ones gets tricky.

Say that a parent company offers its subsidiaries to use a new uniform online platform for the processing of orders placed by customers entering into a supply contract with a subsidiary. There are at least two actors here, so how to properly allocate roles here?

‘Guidelines’ intend to provide for some new tips helping to spot a joint controllerships in paragraphs 3.2.2.1, 3.2.2.2, but all of them still revolve around what has always been clear from Article 26: finding out how means and purposes of processing are defined requires careful case-by-case assessment. To that end, ‘Guidelines’ are more likely to be expected to outline a clear methodology of how this assessment should be performed.

Referring to the question above, e.g., it might revolve around questions like: does the parent company make it mandatory for the subsidiary to use the online platform (and thus it solely defines means and purposes)?; or can the platform only be used in case of a common decision of the parent company and the subsidiary to do so?

Instead of the methodology, we can (not only but mostly) see examples. Examples are always good but they are rarely helpful when factual picture in practice differs (even slightly) from that described in the example. In other words, examples contain an analysis of very specific facts alone, while a privacy pro needs an understanding (method, checklist, etc.) of how to properly approach every possible set of facts.

Good job, EDPB, but could you please try again?

GDPR Considerations in European – American University Research Contracts

Negotiating R&D contracts with European partners over the past 20 years has always been my favorite type of transaction work. You have the cultural differences, the time zone issue, language issues, IPR issues, liability and indemnification issues, currency issues, and other issues that add complexity to the negotiation (and ultimately management) of such transatlantic research contracts.

Since May 25, 2018, the date that the GDPR came into force, the exporting of European personal data to America via research contracts has assumed more importance in the international contracts realm. In this brief post I want to point out several of the large buckets that university contract negotiators need to consider in negotiating and managing such contracts (and ultimately the relationship between the parties).

The scenario covered by this article is a European sponsor (government, foundation, private company, etc.) who wants to provide money to an American university for specific research work, such work often involving the private information of European data subjects and requiring its exporting to the U.S. partner. For example, such a scenario could involve funding from the European Commission to Harvard University. Now onto the buckets.

Bucket 1: Ascertaining Important Data Protection / Privacy Information Parameters at the Beginning

This bucket includes the information that should be ascertained at the beginning: the pre – award / proposal development / Scope of Work (SOW) stage of the research partnership. Here are some questions that should arise from the American side: Is there a European address? Where is the corporate headquarters? Why does your partner want to include GDPR terms in the contract?

At this stage, it is also important to determine what type of data is being transferred and if the data meets one of the three standards for GDPR application to U.S. – based organizations: 1) physically present in the EEA; 2) offering goods / services in the EEA; or 3) monitoring behavior in the EEA. These questions – and their follow on ones – really are part of the partnership building process at the beginning. This should happen well before the issuance of a research contract for negotiation and signature.

Bucket 2: Who is the Controller? Who is the Processor?

This is Privacy 101, but these questions are foundational. Who determines the purposes and means of the processing of European personal data of data subjects? (Controller) Who acts on behalf of the Controller pursuant to a data processing agreement? (Processor) These roles need to be determined as the project is conceptualized and developed.

Once again, it is useful to look at the Scope of Work (SOW) to determine what role is best suited for each party given the proposed research activities.

While for most European – American projects it would be the European Sponsor / Funder of research activities as the controller and the American university as the processor, it is still theoretically possible that either contracting party could be either a controller, processor, or joint controller. Once again, it depends on project scope and what each party is doing during the project.

Conclusion

This relatively short post is meant as an introduction to the GDPR dimensions of transatlantic university research contracts. Data protection / GDPR considerations have joined a multitude of programmatic and contractual issues for these international contracts. A future post will focus on contract negotiation. Please feel free to leave comments below.