4 minute read
UPDATE 3: The Data Privacy Periodic Table
By Sophie Chase-Borthwick on 22 July 2019
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.
Changing “Controller” and “Processor” to “Owner” and “Executor”
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
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”
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
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!)