To read the latest update (August 2021) to The Periodic Table of Data Privacy, click here.
The Data Privacy Periodic Table continues to be well-received and widely shared and commented upon. Since our last update in January, data privacy has barely left the news.
Proposed fines have been awarded to some of the biggest brands, including British Airways (£183.4m) and Marriott Hotels (£99m – announced 24 hours after British Airways), AI and automation commentators continue to debate how to progress within the boundaries of Privacy by Design, and there have been constant updates to new local and national draft laws.
The British Airways fine in particular is interesting as it represents only 1.5% of BA’s turnover, far behind the maximum 4% that the GDPR permits. To the casual observer it therefore seems a light penalty, but in fact it is probably a carefully chosen figure – more than enough to provoke shock and awe across the industry and media, but not so high as to be easily challenged. It’s also a far cry from the £500,000 that the ICO’s powers used to permit, continuing the trend of Supervisory Authorities being willing and perhaps eager to use their powers to punish the most grievous and negligent offences.
And so to this update of the Data Privacy Periodic Table. While data privacy has largely been kept at the forefront of our minds by brash headline-grabbing fine announcements, the changes on this occasion are conversely driven more by the subtleties of the laws themselves.
The updates
Changing “Controller” and “Processor” to “Owner” and “Executor”
When we first launched this project in September 2018, we were determined to make sure it reflected the wider privacy world and was not just a Periodic Table of the GDPR. This is harder than it sounds, despite the principles of the GDPR appearing to be reflected in almost all national privacy laws drafted since.
As new laws have been drafted since, it has become clear that the terminology of “Controller” and “Processor” (elements #40 and #41) has become too specific, though not unique, to the GDPR. The roles and demarcation are very common, but the names are not consistent.
For instance, the draft Indian privacy bill describes a role that is ostensibly the same as that of a GDPR Controller, and names it “data fiduciary”. Hong Kong uses the term “user” (which has created enormous confusion in client engagements when discussing collecting the data of website visitors or SaaS platform customers!), and the CCPA refers to “service providers”.
We therefore felt that “Controller” was becoming too GDPR-centric and have changed it instead to “Owner”.
For some, this will be appear to be unwise wording. After all, the central ethos of data privacy is that the data subject is the ultimate owner of their personal information, and not a brand who simply holds a record of it. However, we wanted to use a term that conveys an obligation to oversee the treatment and physical safety of the data – in other words, they are not the owner of the data (that will always be the data subject), but the owner of the responsibility.
Meanwhile, for the same reasons of GDPR-centricity, we have changed “Processor” to “Executor”.
We considered “Agent” but it risked being too easily confused with “Controller” / “Owner” who is often said to have “agency over data”. Plus it suggests being in the direct and total control of the Controller, which is not accurate.
We considered “Proxy”, but we felt it implied too much control over the decision-making.
And we considered “Intermediary”, but it didn’t feel quite representative of all types of data exchanges between the two parties.
“Executor” meanwhile is a sufficiently recognised legal term to be understood, while striking the right balance between performing a role that is instructed at a high level, but that also allows suggests enough freedom in the performance of the role to bear some responsibility.
Data Protection Impact Assessments vs Privacy Impact Assessments
A big conversation currently is the difference between a Data Privacy Impact Assessment and just a Privacy Impact Assessment. GDPR requires DPIAs, while the industry has always been accustomed to PIAs, and has mistakenly conflated the two.
So, what’s the difference?
We could spend thousands of words on this, but in brief terms, a PIA is a process that privacy teams use to assess how changes to the business affect the overall privacy strategy, impact Privacy by Design, and whether they create new risks.
Meanwhile a DPIA is more targeted, both at an individual process, and on the impact on the data subject. The two processes certainly overlap, but they also have different aims. They should both be performed, in tandem, with any change to the business – but by no means should one replace the other. Accordingly, we have split them out in the table, as elements #27 and #28.
To make room, we combined “Suppliers” and Partners” in the bottom half of the Central Components of Data Privacy section, where various types of data subject are listed, to create a new element, “Third Parties”.
“Data Protection Officer” now “Privacy Officer”
Just as with Controller and Processor above, we feel that the GDPR-centric title of Data Protection Officer “DPO” hasn’t become universal, or even as commonly used as anticipated.
Russia does use the term, as does the Indian privacy bill, but Brazil’s draft for example simply refers to “Privacy Officers” whose roles are arguably more akin to CISOs, especially given there’s no requirement to avoid conflicts of interest. The CCPA has no requirement for the role at all, although commentators are widely recommending that having one would be best practice regardless.
In essence, there is too much variety in nomenclature, and even in the exact requirements or necessity of the role itself, for us to continue to use DPO as it is commonly understood. We have therefore switched it to “Privacy Officer” (element #39), intending it to refer simply to an internal supervisory role where the rights (ethical as well as legal) are represented within the business. Whether an organisation is compelled to appoint one or not, it is surely prudent to have such oversight in place.
Replacing ICANN with US States
The ICANN saga (element #114 in the Future Developments section) appears to have reached something approximating a conclusion – for now at least. As of May, the WHOIS directory has been redacted and access is now controlled. And while conversations continue over whether this affects anti-terrorism efforts and the like, and a long term solution is still being sought, there is unlikely to be major change for some time.
We are replacing this with an area of far greater disorder and confusion – the various privacy laws of the US’ individual states. Three states – Nevada, Maine and California – have passed their local laws (though see our previous update as to why we are still keeping the CCPA in Future Developments rather than Core Legislation), and as many as 11 have bills in progress, and five have been toppled in some way, including Hawaii’s that was vetoed only a few days ago.
As many know, there is talk of whether these states’ bills will create enough pressure for a single federal bill to be introduced, but for now, and perhaps for quite a while yet, we suspect the states will have to continue to handle data subject protection themselves.
(As a side note, did anyone notice our deliberate use of USSs for this element, not be confused with USSS, the United States Secret Service – an ironic potential confusion for this topic!)
As always, let us know of any suggestions, disagreements or recommendations. This is an open and live project that actively seeks input and is regularly updated as things change.
Back