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!]

Lawful Basis for Processing

GDPR: Getting to the Lawful Basis for Processing

I have made no secret of my distain for organisations and individuals who consider themselves qualified to determine their client’s lawful basis for processing without having the necessary education or experience to do so. Just reading the GDPR a few times and doing some homework (like me), or taking the “Certified” GDPR Practitioner course (or equivalent), does NOT qualify you to talk legal matters with anyone. Don’t try.

On the other hand, a privacy lawyer (or equivalent subject matter expert) is just as likely to be spectacularly unqualified to get the information required to make the legal determinations in the first place. It is even more unlikely that they can manage the project from start to finish. Even if they could, there’s no way they’d be available, or affordable.

So what you end up with is either someone(s) who can only get you most of the way, or someone(s) only able to take you over the finish line.

In reality, getting to the point of, then actually determining the lawful basis, were never a single person’s responsibility. The work necessary in gathering everything ‘legal’ needs is 99% of the effort, requires only very limited data protection knowledge, and done properly, should make retaining a true privacy expert significantly more cost effective. Depending on the size and complexity or your organisation, perhaps even redundant.

In GDPR Compliance Step-by-Step: Part 3 – Process Mapping I spelled out all of the basic information required for a determination of lawful basis, but here I want not only give it some real-world context based on experience, but provide an example of a completed form.

I have developed a spreadsheet that anyone can use to gather all of the information a lawyer would need to not only make a determination of the lawful basis for process, but then give you every action item necessary to get each of your defined business processes GDPR compliant. I call it the ‘Data Inventory / Detailed Process Narrative’ or ‘DI/DPN’ for short. You can download it, and its corresponding instruction manual, here: http://www.davidfroud.com/downloads/

Please take a minute to review…

For the purposes of this exercise, let’s assume that the ‘Business Function’ you’re trying to ‘legalise’ is sales related. We’ll call it “New Client Acquisition” (download completed example here), and these are the steps to follow:

Step 1: Find a person who is best suited to describe, in significant detail, the process you’re trying to justify. In this example it will be someone whose job it is to process the data on a prospective client list received from a third party broker;

Step 2: Shadow this person while they perform the actual function, record all of the following:

  1. Data Repositories – e.g. spreadsheets, a CRM, network shares and so on. Everywhere the data has touched, or is going to touch at some point. Give them a ‘friendly name’, one everyone uses to refer to that source;
  2. Communications Channels – e.g. phone, email, fax, snail-mail etc;
  3. Data Fields Used – e.g. first name, last name, work email, work mobile etc. Record not only the ones actually used, but those that are available, as this has implications later for security safeguards (specifically access control);
  4. Determine Any Data Outputs – Does the data the salesperson uses then go TO anyone else outside of the organisation for further action?;

Step 3: From relevant departments, gather all of the following ancillary information related to the data repositories, as it’s unlikely the salesperson will either know or care:

  1. Functional Responsibility – Who manages the data source(s), internal resources or outsourced third party(ies)?;
  2. Location of the Data – While the location of data should be known to its exact location (it IS an asset), for the purposes of this process a determination of ‘in the EU’ or which ‘third country’ will suffice;
  3. Data Source Format – e.g. database, flat file, email, pdf etc. This has implications for security safeguards;
  4. Security Controls (a.k.a. Safeguards) – for the internally controlled data sources, what security controls are in place on the data? e.g. encryption, RBAC, network segmentation etc.;

Step 4: Complete all of the following against every data field in use:

  1. Category of Individual(s) – Here you will need to have pre-determined exactly what your organisation will use as categories e.g. ‘Employee – Former’, ‘Client – Current’, ‘Third Party’ etc. (See the ‘Metatags‘ tab on the DI/DPN template for an example);
  2. Category of Personal Data – Again, you will need to have a pre-determined your categories e.g. ‘Core Personal Data’, ‘Contact Data’, ‘Financial Data’ etc. (again, see the ‘Metatags‘ tab);
  3. Mandatory – What data fields do you absolutely have to have to perform the function? Mark them with a ‘Yes’. If they are just nice-to-haves put ‘No’, and you later will need to either justify their continued use, or get rid of them;
  4. Responsibility – are you the Controller, Joint Controller, or a Processor? The lawyer will likely make this determination for you anyway;
  5. Data Type – Directly Identifiable (DID), Indirectly Identifiable (IID), or Sensitive (SPD). While not a hugely important factor, this could have implications down the road if you’re claiming anonymisation of data, or are disclaiming profiling.

Step 5: Complete the Detailed Process Narrative’ tab of the DI/DPN spreadsheet.

While a lot of this is regurgitation from the DI tab, there are several fields you’ll need to populate with the information you’ve collected above. In the end, the only things you absolutely HAVE to provide to get to an initial determination of the lawful basis for processing are the:

  1. Purpose of Processing and Process Description – it’s critical that these are detailed enough that a lawyer knows exactly what you do to the data, and what result you get from it;
  2. Categories of Individual;
  3. Categories of Personal Data; and
  4. determination of Controller or Processor

Literally everything else is used to get you compliant.

Step 6: Hire an appropriate data protection expert. While I keep using the word ‘lawyer’, there are many data protection experts out there who perfectly capable of getting you to the lawful basis for processing. The issue is that vast majority of the work an expert does is after the determinations are made.

Even I can tell you that in the example above the lawful basis for processing is Article 6(1)(f) – Legitimate Interest, I can even tell you the data subject rights that you now have enable as a result …because a lawyer told me (see Annex A of the DI/DPN Instruction Manual).

What I CAN’T do is everything else:

  1. Develop a complete set of relevant data protection policies and standards to adequately demonstrate that the organisation is demonstrating accountability (Art. 5(2));
  2. Data transfers between legal entities under the same corporate umbrella still require some form of “legally binding and enforceable instrument” e.g. an Intra-Company Data Transfer Agreement (ICDTA) using “standard data protection clauses“.
  3. Third parties will require a Data Processing Agreement (DPA);
  4. Ensure that the contracts in place with third party data sources include guarantees that the data was collected fairly and lawfully;
  5. Data transfers to third countries outside of an ‘adequacy’ decision will require either a DTA, binding corporate rules, a Code of Conduct, and/or certification when it becomes available; 
  6. All correspondence to the prospect will need to contain links to an  opt-out mechanisms backed by not only an appropriate privacy notice, but all information required by the data subject to exercise their relevant rights;
  7. Perform a Legitimate Interest Assessment (LIA) to ensure that the organisation’s interests are appropriately “balanced against the individual’s interests, rights and freedoms“;
  8. Perform a Data Protection Impact Assessment (DPIA) if necessary;
  9. Add contingencies for variances in national laws if applicable;
  10. and so on…

And if YOU can’t do that stuff, you need to find someone who can.

Step 6 seems like a lot, but this is a worst case scenario and most qualified experts have an extensive portfolio of templates from which to choose. I am therefore convinced that if you can provide a completed DI/DPN for your relevant business process, the steps to make you fully GDPR compliant are actually very straightforward.

Honestly, there’s really nothing in the first 99% of this process that you should not be doing anyway.

[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