British Airways

BA Faces £500M Fine: Shut Up and Get Your FACTS Straight!

Just about every major news outlet in the UK has the same headline for the BA data breach: “BA faces record £500M fine for data breach!“. Some are not content with even this degree of utter nonsense and are actually making things worse by saying that affected passengers are now “threatening boycott“.

I can only assume these morons are short-selling BA stock in order to cash in on their otherwise total journalistic ignorance and complete lack of integrity.

I was personally affected by the breach, and I can assure you I will not be giving my business to Easy Jet as a result.

Yes, I am pissed off. Here’s why: 

  1. The fines under GDPR for a data breach are 2%, not 4% so off the bat the headline should be “BA faces record £250M fine for data breach!” – this one shows either ignorance of the regulation, a deliberate attempt to dramatise the headline, or plagiarism;
  2. The maximum fines under GDPR are reserved for the most egregious offences, not any offence, and must at all times be “effective, proportionate and dissuasive” (Art. 83(1)) – explain to me how a half-BILLION pound fine for the loss of 380K payment cards is in any way ‘proportionate’ given the apparent sophistication of the attack; 
  3. Loss of payment card details is already covered under the Payment Card Industry Data Security Standard (PCI DSS), as are appropriate fining / recompense structures – so why would the ICO jump in and investigate when there is a program in place already, and has been for over a decade? For what it’s worth, the fine for the loss of 380K payment cards under PCI would be in the order of £2.5M, if one is given at all;
  4. According to Art. 34(1), you may assume BA had no choice but to notify the data subjects of the breach; “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.”, but seeing as all fraud losses related to breached payment cards is actually covered by the card issuers, can this really be called ‘high risk’? BA did it anyway;
  5. There is no such thing as 100% security – if someone with the right skill-set and patience wants in, they’re getting in, and there’s nothing you can do to stop it. You protect data to a level appropriate to its value, and no matter what business you’re in, there will always be gaps. Always.
  6. I have worked with the BA security team in a previous life, and I VERY much doubt this breach was either negligence or incompetence, they take security very seriously. This by itself would negate a huge chunk of the GDPR fine, and their obvious pro-activity related to every other factor in Art. 83(2) should negate the vast majority of the rest.

Bad news sells, I get that, but I will forever be disgusted by journalists hell-bent on destroying the image of good people and otherwise good organisations for the sake of a brief and anaemic limelight and a few column inches.

It takes an incredible variety of skills to design and build a house, any idiot with a bulldozer can knock one down.

It will be your turn soon, it’s just a matter of time.

[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 :)]

Technical and Organisational Measures

GDPR: Reporting Your “Technical and Organisational Security Measures”

You could almost be forgiven in thinking that words/phrases like; ‘pseudonymised’, ‘anonymised’, ‘access control’ or ‘encrypted’ are all that is required when reporting your technical and organisational security measures for Article 30 – Records of Processing Activities.

Almost.

The UK’s ICO themselves provided a sample of what records of processing should look like, and even included examples of content. Their column headed “General description of technical and organisational security measures (if possible)” contains just two examples; “encrypted storage and transfer” and “access controls“. So in the absence of more detailed guidance from any supervisory authority [that I have seen] just what are organisations supposed to do?

First, you need to understand that in Article 32 – Security of Processing, the phrase “technical and organisational security measures” is qualified twice by the one word that makes the whole thing not only clear, but very simple; “Appropriate”.

Article 32(1): “Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk…”.

I’m not going to go into detail about how you define ‘appropriate’, I’ve already done that in GDPR: How Do You Define ‘Appropriate’ Security Measures?, but I am going to provide an example of what this would look like on the only medium that counts; paper.

Continue reading

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