Right to Erasure

GDPR: The Right to Erasure Does Not Always Mean Forgotten

The title should actually be more in question form; Did you know that there’s even a difference between being erased and being forgotten?

Article 17 of the GDPR is “Right to erasure (‘right to be forgotten’)“, which suggests they are the same thing. They are not [quite], and I think the only reason the right to be forgotten was added in brackets is because everyone was already calling it that. But it’s just not accurate …enough.

The right to be forgotten is intended to allow an individual to “determine the development of their life in an autonomous way, without being perpetually or periodically stigmatized as a consequence of a specific action performed in the past.” For example; you may have been guilty of a minor criminal offence 30 years ago, which in the UK would likely make that offence “spent” (i.e. it should not be considered in any decisions against you related to insurance, employment, loans and so forth). However, if this criminal record has been posted online then duplicated in numerous forms all over the place, it will never go away. In other words, you’ve paid your ‘debt to society’ but it will haunt you for the rest of your days.

Just ask that poor sod Mario Costeja González how something in your past can perpetually bite you on the arse. He just wanted something fairly benign to be ‘forgotten’ and now he’s one of the most famous names in this whole debate.

On the other hand, the right to erasure is just that; deletion of data that, for whatever reason, is of no further use or shouldn’t be there in the first place (amongst other things). For example; Your previous employer has a BUNCH on information on you, a good chunk of which is simply not relevant. Training schedules, certificates, next of kin and so on. In reality they need only enough to meet certain regulatory and/or legal obligations and a note on whether or not they’d ever hire you back.

So what are you actually trying to achieve when you ask to be erased? I think that > 95 times out of 100 all you want is for an organisation to stop pestering you in some way, but this actually precludes you from being forgotten. If you ask someone to erase everything about you how can they possibly know not to contact you again? They have to keep something, even if it’s just enough to leave you alone.

When asking to be forgotten, you actually don’t have the right in some instances, because doing so would put other people’s rights at risk. Remember, privacy is not an absolute right, it’s only a fundamental right.

For example; Would you want the system to ‘forget’ about someone’s embezzlement background when they are applying for a job in your bank? Or a person’s serious medical condition when applying for a job to drive your kids to school? What about pedophiles?

On the other hand, don’t most of us deserve a chance at retribution for minor mistakes from our past? Should we really have to suffer our whole lives for something we deeply regret and have made amends for a thousand times over?

If you think about it, ‘erasure’ and ‘forgotten’ should really be combined into the ‘Right to the Application of Appropriate Context’ as that’s what you’re looking for from anyone with access to your data.

The above is rambling, enormously oversimplified, and I’m not even sure what my original point was. In the end the implementation of GDPR is going to have an enormous impact on us all, it’s up to you to ensure that impact is positive.

So whether you are data subject trying to invoke your right to erasure, or an organisation trying to understand what your recourse is, you MUST have the right context. You can only achieve that context by doing your homework.

[If you liked this article, please share! Want more like it, subscribe!]

DPO

Should a CSO/CISO Ever Be a DPO?

I finally figured out why this blog was so damned difficult [for me] to write; I’ve been thinking all wrong about what exactly a DPO actually is. Which is odd, because I had the exact same challenge when writing about CSO/CISOs, and I really should have learned from my mistake.

When you think about a CISO (assume this also means CSO), or a DPO, you instantly picture a person. Maybe your organisation already has one so their face springs to mind, or if not, you have a indistinct and faceless image of someone in a suit. The fact is, neither the CISO nor the DPO are people, they are functions. Multiple functions in fact.

And not only that, they involve multiple disciplines, skill-sets, even personal preferences. Most importantly, neither the CISO nor the DPO functions [performed correctly] are ever a single person. A DPO would, quite literally, have to be an expert in privacy law (both EU and national), contracts, risk management, policy development, distribution and audit, and understand all personal data flows throughout the business.

You therefore need to break the function down before you can move forward. For example; I broke the CISO function down into 3 distinct skill-sets/phases:

  1. The Planner: The p-CISO comes in at the beginning of an engagement, before an organisation even knows what it actually needs. Their job is to design a security program that does the only thing it’s supposed to; support / enable the company’s business goals;
    o
  2. The Executor: e-CISOs get things done. They take the hand-off from the p-CISO and put the agreed plan into action; and
    o
  3. The Optimiser: o-CISOs are in it for the long-haul. These are the folks that take the still raw security program, and make sure it get fully instilled in the company culture and business as usual processes.

I have never, I mean NEVER, met any one person who is fully competent at, or even wants to perform all of these things. For example, I thrive as a planner, would fail miserably at execution, and could not be less suited for optimising. In fact, phase 1. and 2. are likely short to mid-term specialist external consultants, and only 3. is a full-time employee or ‘indefinitely outsourced’ service.

The DPO will be no different, but first you have to address exactly what they are required to do (per Article 39):o

  1. to inform and advise the controller or the processor and the employees who carry out processing of their obligations pursuant to this Regulation and to other Union or Member State data protection provisions – so any incumbent not only has to have significant knowledge of their organisation’s business processes, but they have to have sufficient understanding of both the GDPR and any national laws relevant to member states under his/her remit;
    o
  2. to monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data, including the assignment of responsibilities, awareness-raising and training of staff involved in processing operations, and the related audits – so the incumbent not only has potentially significant additional tasking in staying up to speed with relevant EU and national law(s), but they have to able to translate that into appropriate policy, training material, and audit procedures;
    o
  3. to provide advice where requested as regards the data protection impact assessment and monitor its performance pursuant to Article 35 – so the incumbent has to be able to balance the risk to data subject rights to the value of the processing to the business, and justify any decision to proceed to a supervisory authority. Or NOT to proceed to their CEO/Board!;
    o
  4. to cooperate with the supervisory authority – the incumbent must sound credible, they must at least be able to talk-the-talk;
    o
  5. to act as the contact point for the supervisory authority on issues relating to processing, including the prior consultation referred to in Article 36, and to consult, where appropriate, with regard to any other matter – again, the incumbent had better know his/her stuff. If the supervisory authority thinks the DPO is nothing but an empty suit this will reflect very poorly on the organisation concerned

Now ask yourself; Does any one person in your organisation have what it takes to manage the above? I think it unlikely.

So that should leave you breaking the development of the DPO role into a similar 3-phase process, similar to the CISO’s above. It would look something like this:

  1. The SME: The sme-DPO comes in at the beginning of an engagement to design the data protection compliance program. S/he has enough knowledge (and access to other more task-specific SMEs) to ensure that the program has the requisite leadership commitment, that all personal data will be discovered and mapped to business processes, that all policy and contract language will be in place and so on;
    o
  2. The Program Manager: the pm-DPO should also be very knowledgable in data protection, but their role is to take take the sme-DPO’s plan and run all work streams to their appropriate conclusions. To all intents and purposes, this organisation is now compliant. They can perform GDPR Article 30 reporting, they can answer any data subject access request, their breach notification is documented and tested, their 3rd party and vendor contract addendums / DPAs are in place and so on; and
    o
  3. The Maintenance DPO: m-DPOs are now the ‘named-face’ of data protection in an organisation, but like a governance function, it’s more of a organisational role. They are responsible for combining the right departmental expertise and external SME guidance into a coherent and sustainable program.

If you assume that the CISO will only be one of many SMEs in phases 1. and 2., what makes them the right person to handle 3.? Actually, if the CISO has be hired correctly, there is quite a lot in their favour. They:

  1. should already have dotted-line reporting, and direct access to, the Board – Both of which are prerequisites for a DPO, just as they are for internal audit;
  2. should already have a seat at whatever passes for Corporate Governance – where the responsibility for data protection and data security rightly sits;
  3. will, as an intrinsic part of their job, have an almost unparalleled understanding of where the personal data is, and what’s done with it;
  4. will, again as an intrinsic part of their job, have an almost unparalleled understanding of who does what in an organisation;
  5. should certainly be able to handle all aspects of “technical and operational security measures”, should a supervisory authority ever ask;
  6. should already be very familiar with the development, distribution, and ongoing maintenance of a training program;
  7. must understand the absolutely necessity for, and the enforcement of, good policies, standards and procedures; and
  8. must understand the maintenance of a compliance program from an internal policy, and an external regulatory perspective

And the list goes on. In fact, the only real questions to ask are:

  1. Does the CSO/CISO have the necessary and business-appropriateexpert knowledge of data protection law and practices (Article 37(5))” to do the job?; and
    o
  2. Do they want it?

For the longest time my gut feeling was that the m-DPO should be more of a legal function (which it is), but in-house legal expertise is actually more rare than in-house security expertise. So now, in the absence of legal, I find myself unopposed to security filling the m-DPO seats, but only if both the candidate, and the position itself meet ALL of the above criteria.

About the only thing I would warn against is taking any stock in “certified DPO” courses, they are about as useless and inappropriate as “certified CISO” courses. You don’t learn these things from a course, you learn them from doing the bloody JOB.

And finally, would I ever recommend a ‘virtual-DPO’ or other ‘indefinitely outsourced’ service to handle the m-DPO function? That depends, can they meet all of the above criteria without a seat at the governance table? For a small monthly retainer? Over the phone?

Dunno, your call, but now you know the right questions to ask.

[If you liked this article, please share! Want more like it, subscribe!]

 

[Ed. I wanted to thank a ‘colleague from Kosovo’ for prompting this blog :)]

Information Security vs Privacy

Information Security vs Privacy, are the Lines Blurring?

My original title was “Data Security vs Data Protection[…]”, but an unfortunate number of people see these as pretty much the same thing, even interchangeable. Then I chose Cybersecurity instead of Data Security but that doesn’t cover all forms/formats of personal data, so I finally had to settle on Information Security.

As for Data Protection, it’s not, in and of itself Privacy, and so on…

But you see the problem already? If we can’t even agree on common terminology, how are we expected to ask the right people the right questions in order to solve our problems? But I digress…

For the purposes of this blog I have chosen the following definitions of ‘Information Security’ and ‘Privacy’:

  • Information Security – “…is the practice of preventing unauthorised access, use, disclosure, disruption, modification, inspection, recording or destruction of information.”; and
    o
  • Privacy – “…is the ability of an individual or group to seclude themselves, or information about themselves, and thereby express themselves selectively.”

It should be immediately obvious that these are NOT the same thing. Significant overlap, yes, but as always, security is just an enabler. Security does not dictate the goals of a business, it enables them; security does not give you privacy, it enables you to have it. A personal trainer does not make you healthy, s/he provides guidance in ONE aspect of your health goals. You still have to eat better, drink less, stop smoking, reduce stress and so on.

But now there seems to be an expectation that security people should also be privacy experts (I’m not saying they can’t be, but I actually don’t know any). Because GDPR is a big deal and ‘data protection’ is seen as the same as ‘data security’, everyone is looking to security people for guidance. Would you hire a fat personal trainer?

Take me for example: I have spent a large chunk of the last 2 years learning more about privacy (and GDPR in particular), I still consider myself 99.9% a security guy. I have even written fairly extensively on both privacy (personal opinion) and GDPR (hopefully accurately), but once again, neither of these things is what I DO. Privacy is not a core competence of security (just look at the CISSP CBKs).

But, and to the point of this blog, can a ‘security guy’ keep doing just security in the brave new world post-May 25th? The short answer is of course yes, if that’s all they want, but are they doing their careers any favours? And what about their clients? Can a security expert without at least a foundation in privacy really perform their function appropriately? For security to enable anything, they need context, privacy is now a major factor of that context for any business.

In other words, has privacy now become so important, that any field with a significant impact on it must revise its training syllabus? And given that information security has such a significant overlap with privacy, are security people best placed to take on a bigger role in providing privacy guidance?

The answer, as in everything else, is; that depends. A business has to be able to find the appropriate help, and the ‘expert’ has to have the appropriate skillset. There is no standard here, and only the people [on both sides of the equation] who educate themselves should be making any decisions. Should.

In reality, most organisations don’t even have in-house security expertise, let alone privacy expertise, so where is this guidance supposed to come from? I now think that security folks are very well placed to begin taking on a larger privacy mantle. I even believe that security folks who don’t get a foundation in privacy are severely limiting their careers. Could you imagine hiring a CISO who hasn’t even read the GDPR?

Information Security and Privacy will never merge completely, they are just too big and too different, but the lines are indeed blurring.

[If you liked this article, please share! Want more like it, subscribe!]

GDPR Muppets

GDPR: Now We Know Who the Muppets Are

Well, here we are, close of business May 25th, and oh look!, the sun is still shining, the world is still spinning, and no one [decent] went out of business.

What we do have however is an indication of who the world’s biggest muppets are. For example:

…and:

…and the list goes on and on.

As if the barrage of ridiculous and utterly meaningless emails over the last few months wasn’t enough, the spectacular ignorance shown by these and many other organisations defies belief. The only good thing I can say about these weapons grade plums is that they are actually taking GDPR seriously. They DID something. The fact that they are needlessly damaging their reputations is apparently beside the point.

Continue reading

GDPR Step-by-Step - Operationalise

GDPR Compliance Step-by-Step: Part 6 – Operationalise

This is the final part in my GDPR Step-by-Step series, and one that, in my cynicism, I see very few organisations even trying to attempt. I have lost count of the number of companies with whom I have tried to implement a continuous compliance program, only to have them stop once they received their initial ‘certification’. In this respect, GDPR will be no different from something like PCI.

But for GDPR, if you don’t  build the necessary knowledge / processes into everyone’s day jobs, your compliance program will falter. While data protection and privacy are everyone’s responsibility, they cannot, and will not be at the forefront of everyone’s mind as they work through an ordinary day.

There are some who are convinced that you can ‘operationalise’ the entirety of GDPR with ISO 27001. This is, of course, nonsense. However, the concept is perfectly valid in that ISO 27001’s goals are to:

  • Systematically examine the organisation’s information security risks, taking account of the threats, vulnerabilities, and impacts;
  • Design and implement a comprehensive suite of information security controls and/or other forms of risk treatment;
  • Adopt an overarching management process to ensure that the information security controls continue to meet the organisation’s information security needs

Continue reading