Scope of the obligation to provide «a copy of the personal data undergoing processing» (Article 15(3) GDPR).

#EDPB in draft #Guidelines 01/2022 attempted to clarify the scope of the controller’s obligation to provide «a copy of the personal data undergoing processing» (Article 15(3) #GDPR).

What Article 15(3) implies by «a copy» – has long been a controversial issue, while approaches varied across #EU Member States. Below are some examples:

#Germany: there have been contradictory views as to how the term “copy” should be understood – i.e. whether it should be literally a copy or just summary (https://lnkd.in/eRbC5gY7)

#Austria: GDPR (Article 15(3)) does not grant a right of access to files or documents. However, the content of documents may qualify as personal data. Providing copies of personal data stored within a document will often be the easiest option by redacting superfluous information and providing the document to the applicant (https://lnkd.in/eRgPcEDs)

More insights can be obtained from the #IAPP article – https://lnkd.in/e9g37p9v

Now, EDPB seems to take a so-called ‘fit-for-purpose’ approach to how the notion of ‘copy’ should be understood.

Para 23, 25 of the draft Guidelines 01/2022 say that a right to obtain a copy refers ‘not necessarily to a reproduction of the original documents’ and ‘that the information on the personal data concerning the person who makes the request is provided to the data subject in a way which allows the data subject to retain all of the information and to come back to it’.

Further to this, para 150 stipulates that ‘an obligation to provide the data subject with a copy of the personal data undergoing processing […] does not mean that the data subject always has the right to obtain a copy of the documents containing the personal data, but an unaltered copy of the personal data being processed in these documents. Such copy of the personal data could be provided through a compilation containing all personal data covered by the right of access as long as the compilation makes it possible for the data subject to be made aware and verify the lawfulness of the processing’.

In other words, against this purpose, ‘it is the responsibility of the controller to decide upon the appropriate form in which the #personaldata will be provided’.

EDPB Guidelines 05/2021 on the interplay of Article 3 and Chapter V: not a big deal at all

I intentionally deterred myself so far from reading opinions and analytics about newly issued Guidelines 05/2021 so that those do not inform my personal ‘first’ opinion. 

For now, Guidelines 05/2021 do not appear to be a big deal at all, nor are they free from inconsistency with the new SCCs and from casuistic examples.

1) Three criterions of transfers do not look like something ‘surprising’. C’mon, there could scarcely be anyone who expected the existence of ‘transfer’ between a controller/processor and a data subject. Maybe it is just me, but I can see few (if any) things that could be seen as significantly changing the landscape and adding value to the current understanding of things. 

2) At the same time, a misalignment between the EU Commission and the EDPB still continues. Recital 7 of the SCCs implementing decision noted that SCCs may be used for transfers “only to the extent that the processing by the importer does not fall within the scope of Regulation (EU) 2016/679”, and this is in clear contradiction with EDPB’s transfer criteria #3. More on the conflict between the Commission’s and EDPB’s approaches can be read here: https://iapp.org/news/a/why-it-is-unlikely-the-announced-supplemental-sccs-will-materialize/?mkt_tok=MTM4LUVaTS0wNDIAAAGAiv2DhonU2mSs-GNpYnvfsyMcmuYxz64LrNpH1YIA75K7-YZFEz3tT0a3i4wGnMiMXfBDlsr1mVDx_wDm-qJrSV0CybkgplN9HxJo5DkdpDW2

More interesting, there is still no uniform definition of ‘data exporter’ and ‘data importer’. From new Guidelines 05/2021 it is clear that only controllers, processors and joint controllers may qualify as ‘data exporter’ or ‘data importer’, and only between exporters and importers a transfer may take place. More or less (with some textual discrepancies) the same understanding may be seen in Annex 1 of the EDPB Recommendations 01/2020. But the different approach is seen in Clause 1(b) of the SCCs where the understanding of ‘exporter’ of ‘importer’ bears no relation to controllership issues. 

3) Such details may become important in some scenarios – let’s look at Example 5 (employee of a EU-based company travelling to a third country). First of all, this example seems to be borrowed from Norwegian DPA’s guidance – https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/overforing-av-personopplysninger-ut-av-eos/ . Second, what if, let’s say, an employee is not travelling to a third country but permanently sits there? Will this change the assessment and why does EDPB endorse such casuistic examples? Will this make the employee ‘importer’ and will this give rise to a ‘transfer’? My answer is ‘No’ for many reasons. And if the EDPB agrees (does it?..), what would be the role of such employee in the scheme? I tend to believe these will qualify as an ‘establishment’ of an employer (who, in turn, can be either a controller or processor). 

But never mind, it is just an example, and it does not really matter what I (or you) personally think. It is EDPB (not us) who is here to give clear answers applicable in a vast majority of scenarios – as opposed to superficial and often evident explanations and casuistic examples, evading a deep-dive into the heart of the issues. 

Anonymisation – who is to blame and what to do?

The IAPP article provides retrospective of the #anonymisation issue under European data protection landscape and reiterates that there is still no ‘one-size-fits-all’ approach to making personal data #anonymised

The current standing can be described as confusion and vacillation, and, probably, the main culprit of this is #WP29 which took contradictory stances to anonymisation in 2007 and 2014, followed by ignorance from #EDPB side and, again, contradictory stances of national DPAs prone to either 2007 or 2014 approaches.

The simple thing is that straightforward ‘disguising of identity’ (e.g. by one-way cryptography), as WP29 suggested in 2007, can no longer be accepted as anonymisation (of course, unless stated otherwise by a national DPA). And the simple thing number two is that there is no industry standard describing step-by-step anonymisation algorithms and techniques. 

From a practical standpoint this calls for a case-by-cases assessment by an anonymisation entity. The recent AEPD-EDPS joint paper ‘on 10 misunderstandings related to anonymisation’ (‘joint paper’) specifically mentions that ‘anonymisation processes need to be tailored to the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons’.

Out of options suggested by the article, the most practical and realistic is, probably, arguing the risks of reidentification is sufficiently remote in every single case where anonymisation is relied on. In fact, this will require an ‘Anonymisation Impact Assessment’ (I have just come up with this term) which must include assessment of re-identification risks. The joint paper acknowledges that such risks are ‘never zero’ (‘except for specific cases where data is highly generalised’) and that ‘a residual risk of re-identification must be considered’.

Until to date, although addressed by WP29 and adopted by the GDPR, the notion of anonymisation and its application still remains ‘terra incognita’.

EDPB Recommendations 01/2020 – softening without being too soft?

Right after the final version of the Recommendations 01/2020 was issued, we (including myself) started to believe that now, here we will live the life! 

A reference to inability to rely on “subjective factors such as the likelihood of public authorities’ access to your data” is gone, data exporters may now assess how the laws are applied in practice, and even previous importer’s experience.

In fact, it may appear nothing more but just starting euphoria. Let’s be honest, we were happy because we understood: in the majority of cases the legislation of a third country will end up in the cohort of “problematic legislation” (para 43.3).

Okay, para 43.3 says that “you may decide to proceed with the transfer without being required to implement supplementary measures, if you consider that you have no reason to believe that relevant and problematic legislation will be applied, in practice, to your transferred data and/or importer”. That’s the exit, isn’t it? Let’s find some practice that “problematic legislation” does not apply to our transfer, and no need to think of supplementary measures. Everyone’s happy.

Not really. EDPB provides significant requirement to “sources of information” confirming our conclusions.

Non-exhaustive list of them is contained in Annex 3 (various reports from various credible organisations, warrants from other entities…), they must be “relevant, objective, reliable, verifiable and publicly available or otherwise accessible” (para 46). “Documented practical experience of the importer with relevant prior instances of requests” alone cannot be relied on (para 47). 

The question here is: do you know a third country with “problematic legislation” but at the same time with “relevant, objective, reliable, verifiable and publicly available or otherwise accessible” practice confirming that there is not really a problem for the transferred data?

In any event, it is clear: supplementary measures are here to stay.

Some fresh thoughts and updates on new #SCC

1. SCC cover data transfers to importers (i) established in thirds countries AND (ii) NOT subject to #GDPR through Article 3(2). This is not clearly articulated in implementing decision and SCC themselves as recitals and articles of both seem to contain controversial information. From confidential sources it’s become known that Directorate-General for Justice and Consumers will soon publish FAQ clarifying these issues. European Commission is not taking any position on the definition of the concept of international data transfers, though.

2. It is not sufficiently clear to what extent negotiating parties may “add other clauses” to SCC? Example I have seen in one of #IAPP articles: would clauses limiting liability between the parties (not towards data subjects, of course) contradict the SCC?

3. As SCC are based on modular principle, one very formal issue is still unclear: when building SCC, should the labels (“Module One: …” etc.) continue to appear in the clauses?
What to do with insertions in the middle of the text (especially for Module Three) if other clauses are used at the same time – is also not perfectly clear?

4. In terms of assessment, new SCC says that parties, when assessing how law and practice in a third country impact an importer’s ability to comply with SCC, are encouraged to take into account “reliable information on the application of the law in practice (such as case law and reports by independent oversight bodies), the existence or absence of requests in the same sector and, under strict conditions, the documented practical experience of the data exporter and/or data importer”. It is a clear shift from strict position taken by EDPB Recommendations 01/2020 that parties should take into account “objective factors, and not rely on subjective factors such as the likelihood of public authorities’ access”.

The final version of #EDPB Recommendations 01/2020 is in the pipeline, and perhaps some important things will be changed compared to the current version for public consultations.

An interesting case from Austria that touches on Article 85 GDPR and refers to the balancing test developed by ECtHR of how to determine whether occurred processing was for journalistic purposes or not.

The case involved personal data mentioned by ex-convict in his Facebook publication. Ironically enough, Austrian DPA and court came to different conclusion using the same balancing tests. Contrary to DPA’s decision, the court found a violation of the data subject’s rights.

While the case is interesting by itself, it also raises thoughts about consistency of application of various tests and methodologies developed by #WP29 and #EDPB in their multiple papers to practical situations. In a nutshell, “two enforcers – three opinions”.

#dataprotection #lawandlegislation #privacy #politicsandlaw #compliance #dataprivacy #gdpr

Risk-based approach

I brushed up on one important thing – risk-based approach (RBA) which WP29 touched upon in 2014 in its “Statement on the role of a risk-based approach in data protection legal frameworks” (WP 218).

So what is RBA really about? The key phrase from the Statements that suggests answer: “… a data controller whose processing is relatively low risk may not have to do as much to comply with its legal obligations as a data controller whose processing is high-risk».

What does in mean? 

RBA does NOT mean that a controller may ignore some of its obligations if it processes low-risk data. This does not lead to compliance and this is a common misconception I’ve seen in my practice many times. Instead, RBA means that in this case a controller may do less to be compliant.

In fact, this is not correct to say that the whole GDPR implies RBA. Only some particular articles in particular cases do so (Art. 25, 30(5), 32-35 and some other).

The recent cases of usage of Facial Recognition Technologies (FRT)

Enforcement actions against Dutch supermarket and Swedish police remind that the bar for using FRT is very high.

Even if used for security purposes inside the supermarket, giving of relevant privacy notification to customers that FRT is used is not enough. However, no fine was issued by Dutch DPA (only warning).

In another case, Swedish Police unlawfully processed biometric data for facial recognition without conducting DPIA which resulted in a fine of approximately EUR 250,000. In addition, Swedish police was ordered to delete all data transfer to external database (Clearview AI) and notify data subjects that their personal data were transferred.

CLICK here to learn more on that

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.

Data Breach or not Data Breach?

Here comes one another evidence of why consistent applications of #GDPR across the #EU is just a ‘shimmering dream’ thus far.

Belgian DPA issued a decision where it said that unintentional (due to human error) sending of an e-mail containing personal data does not mean the violation of Article 32 (security of processing), which prevents the incident from being classified as data breach.

This appears to be in contradiction with #WP29 Guidelines on Personal data breach notification and with the recent #EDPB Guidelines 01/2021 on Examples regarding Data Breach Notifications. Both documents, vice versa, addressed examples of mistakenly sent e-mails, while sufficiency or insufficiency of security measures was not named as a factor of whether the incident should be classified as data breach.

Decisions like this clearly erode the idea and value of ‘consistency’ proclaimed by GDPR and promoted by EDPB.

Another non-obvious conclusion made by Belgian DPA is that unlawfully obtained data cannot be further lawfully processed.

#dataprotection #privacy #datasecurity #databreach #cybersecurity #edpb #dataprivacy #gdprcompliance #databreaches #security #privacyprotection #informationsecurity #infosec #privacyissues #compliance #privacylaw