Data Retention Guidance from DPN

Hi world!

Came across a very good #Data Retention Guidance from Data Protection Network Associates issued in July, 2020 (LINK).

Being based on the #UK and #EU laws, it outlines starting tips for conducting data retention review process (it all, however, begins with data mapping exercise), provides advice on how to decide on retention periods, advises on creation of data retention policy and schedule, and much more.

Attention: the Guidance refers to #anonymization as an acceptable way of handling data when retention period comes to an end. It should be noted here that ‘true’ anonymization is very hard (if possible) to achieve, especially given that there is no industry standard on strict sequence of steps to be taken to render the data anonymized. In addition, amid the constant development of #bigdata and #AI algorithms, data we consider truly anonymized today may not have the same status tomorrow.

Virtualshadows blog is back!

This blog has got a resurrection. It was closed down in November last year because of non-compliance concerning the amount of cookies that the blog was using (WordPress was a cloud service based in US), and Schrems II ruling and that all cookie consent banners were too expensive, after all this is a private blog, its just there were quite a few visitors each month. I guess if this blog had been about my dog, or anything else, maybe I wouldn’t have bothered with all the GDPR stuff, but even so I am professionally a ‘privacy guy’, so the blog had to go.

So what happened to my blog was something I call ‘GDPR paralysis’, everything comes to a stop, and GDPR is the cause. I remember when my business (Privasee) which I founded in 2015 came into a state of GDPR paralysis in 2017, the privacy purists versus myself as CEO, in that ‘business has to function’. There needs to be a compromise, otherwise Privasee would cease to exist, making money for the business is necessary for survival, and for my business to achieve what it set out to do, i.e. ‘make privacy compliance accessible’.

One could claim that a blog comes under ‘household exemption’, which was how I was thinking, maybe misguided, but you know how we can be, human beings, believing in what is easiest, and anyhow what harm can it do to the ‘rights and freedoms of the natural person’? It’s just all those cookies made it a privacy risk to visitors, and today something popped up in my LinkedIn feed that the Danish Data protection authority have passed a ruling that a so called ‘private website’ was not exempt under Article 2(1). I can’t find the case now.

When reading this blogpost, you should only have 7 cookies downloaded, and they are all session cookies, except one with a life of a single day. The WordPress site is based in the EU, so no international transfers.

Enjoy reading the blog again, and welcome back!

The EDPB has now adopted its Guidelines 04/2019 on Article 25 Data Protection by Design and by Default after public consultation

The EDPB has now adopted its Guidelines 04/2019 on Article 25 Data Protection by Design and by Default after public consultation. 

And this is to briefly share 3 key thoughts and conclusions from the Guidelines which might seem to be not so obvious at first sight.

1. Be sure to understand not only literal and contextual meaning of the GDPR provisions, but also their spirit. Yes, EDPB directly speaks about spirit, and this is new compared to the version for public consultations. See Example 1 in paragraph 70.

2. The notion of ‘necessity’ is understood not only in the context of achievement of purposes of the processing, but also with regard to the ways of how personal data are obtained. This serves the purpose to keep data subjects involved in the processing of their personal data to the highest degree possible. See Example in paragraph 68.

And finally, probably the most important.

3. The EDPB writes that processing options cannot be presented “in such a manner that makes it difficult for data subjects to abstain from sharing their data, or make it difficult for the data subjects to adjust their privacy settings and limit the processing” and “in a way that nudges the data subject in the direction of allowing the controller to collect more personal data than if the options were presented in an equal and neutral way» (Example 1 in paragraph 70). Personally for me, it conjures up images of some cookie banners offering just options «Accept all» and «Settings», thus nudging a user to press the ‘right’ button desirable for controller.

Some DPAs (e.g. Danish #Datatilsynet) has previously stated such type of ‘nudging’ is not allowed.

7 practical takeaways from the EDPB Guidelines 07/2020 (by Herbert Smith Freehills)

I remember myself criticising new EDPB Guidelines 07/2020 for obvious mistakes in choosing an approach for giving explanations:

https://virtualshadows.wordpress.com/2020/09/13/do-new-guidelines-07-2020-on-the-concepts-of-controller-and-processor-in-the-gdpr-guidelines-really-help-to-identify-joint-controllership/

Today I came across an article from Herbert Smith Freehills (see the link below) and, ironically, found the same thought I had a month ago: “the guidelines do not appear to add much clarity with respect to the concept of joint controllers and when such a relationship will arise” and “tests will only serve to complicate matters further by requiring additional layers of analysis”.

Exactly! So obvious! Why there hasn’t been any talks on this before?! EDPB often does great things, but sometimes (like all humans, I believe) it may produce shit.

Authors of the article tried to outline 7 practical takeaways from the guidelines. An attempt to squeeze (at least) something useful out? You decide. My point here is that the guidelines partly add little new to the landscape we saw and learnt before, partly – create misunderstanding and ambiguity and, indeed, “complicate matters further”, thus making a step backward from ‘old’ WP29 Opinion 1/2010.

https://hsfnotes.com/data/2020/10/13/new-edpb-guidelines-on-the-concepts-of-controller-and-processor-seven-practical-takeaways/#page=1

Swedish DPA has updated its guidance for employment sector.

Swedish DPA #datainspektionen has updated its guidance as to how personal data should be processed in employment relationships. The information is primarily addressed to employers in both the private and public sectors. It can also help workers, job seekers, trade unions and trade associations.

Original text is in Swedish but can be easily translated into English via online translators.

https://www.datainspektionen.se/vagledningar/arbetsliv/

CNIL partners with Order of Chartered Accountants to help SME to improve their compliance with the GDPR.

While many transnational companies continue to feel headache after ‘Schrems II’ hit in July, the problem for SMEs looks simpler and more trivial: they seem to be unable to meet even more general and clear data protection requirements without external help.

This can return us to early talks (they are sometimes heard now, though) that the GDPR may be too burdensome for many business actors. And we see it can really be like this.

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.