FUD

Do Not Hire Companies Using GDPR Fines as a Sales Tactic

Taking a week’s break from my Step-by-Step series in order to have one final rant [I promise] about the use of GDPR fines/penalties in marketing material. Hopefully this third attempt will sort the problem out once and for all, I DO have 400 followers after all.

In my business, I am advising everyone who will listen to not do business with ANY organisation using fear, uncertainty and doubt (FUD) as a tactic to sell. If they were offering decent services they would not have to resort to such unprofessional and unethical practices.

If you or your organisation use these tactics then you are everything wrong with the industry and I can only hope you fail. I will using the hashtag #gdprcharlatans to draw attention to more egregious lies. But if you fall for these tactics then frankly you deserve it, because you have not done your homework.

For anyone watching the industry closely, it is clear that GDPR represents a fundamental shift in how data protection is going to be addressed globally. So while the fines/penalties may be a stick to help keep things moving in the right direction, they will NEVER be anything other than “effective, proportionate and dissuasive” (Article 83(1)). This is not a do-it-once compliance project for May 25th, this is slow and steady integration of a human right into the way we do business. Permanently. Fines are not the important part.

I hereby predict that you will never see an organisation go out of business because of a fine, it will be because they were stopped from processing for egregiously breaking the rules. In other words they will deserve it.

Here is my reasoning (borrowed yet again from previous blogs):

  1. The maximum fine for ANY infringement, no matter how egregious, is 4% of the annual revenue from the previous year (in the case of an undertaking), it can be assumed therefore that 4% is what the EU considers the maximum for any fine. Therefore, a fine of €20,000,000 (Art. 83(5)) would be reserved for any individual organisation with revenue over €500,000,000 annually. Yes, that’s 1/2 a BILLION.
    o
  2. It must also follow that if 4% is the maximum, then fines will go down the less egregious the offence. Everything you need to determine the level of ‘egregiousness’ in an offence is contained in the 11 lines of Article 83(2)(a) – (k). With words like ‘intentional’, ‘negligent’, ‘degree’, and ‘manner’, it’s clear that there is a significant amount of information to be taken into account long before a fine is even considered. A fine, IF levied, will be carefully considered and FAIR.
    o
    e.g. For Art. 83(2)(b) – “the intentional or negligent character of the infringement” consider the answers to the following questions:
    o
    * To what degree are the lawful bases for processing for all business processes supported by legal review and approval?
    * Was senior management aware of the organisation’s risk exposure?
    * Did senior management ignore, or actively suppress recommendations to correct processing?
    o
    Would you fine an organisation doing its very best and has established Board-level accountability the same as one that couldn’t care less?
    o
  3. Fines simply don’t fix the cause of the breach, and supervisory authorities KNOW that. For any breach there will be remediation and potentially reparation required, often at significant cost. So unless a breach was truly intentional or negligent, why would a supervisory authority fine an organisation for a mistake as opposed to allowing them to use what money they have left to fix the underlying issues?

To try and put all of this into a more demonstrable format, I have developed a GDPR Fine Calculator designed to do the following:

  1. Determine the level of fine for which you are potentially liable – Art. 83(4) and (5) break down, by reference to 50 other Articles/sub-Articles, which infringements incur which penalties (2% and 4% respectively). Just answer the 50 questions on the ‘Breach Questionnaire’ tab to determine which applies to you (Note: If even 1 answer is 4%, that’s what applies);
    o
  2. Estimate the fine for which you would be liable based on the ‘egregiousness’ of the offence – Whichever fine structure you fall under based on the results of the breach questionnaire, go fill it out. Enter your organisational status (undertaking or not) and your annual revenue (in €), then answer all the questions predicated on the 11 “conditions for imposing administrative fines“.

I think you will find that unless you are unbelievably crap at absolutely everything, your fines should not be anywhere near the infamous €20M mark.

This is not to say you shouldn’t worry about fines, because if you are in fact crap OR you’re still doing absolutely nothing towards GDPR compliance, and you are breached, you will deserve every fine you get.

Please Note: The fine calculator has absolutely nothing to do with any official ‘body’, known fact, or even direct experience, it’s based entirely on my opinion and hopefully a little common sense.

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

GDPR Step-by-Step - Lawful Basis for Processing

GDPR Compliance Step-by-Step: Part 4 – Lawful Basis for Processing

If you are looking for a clear and legally accurate treatise on how to apply the 6 lawful bases for processing to your business, you have:

  1. not read any of my previous blogs;
  2. probably not read the GDPR itself; and therefore
  3. come to the wrong place

I am not a data protection/privacy expert and I am not a contracts lawyer, which are the most important skill-sets that should be used in making both the lawful basis determinations, and writing the required contracts/privacy notices/policies etc. to support those decisions. No one else is truly qualified, certainly not a cybersecurity guy like me.

[Note: But if you DO make these decisions on your own, I can certainly empathise, the above skill-sets can be expensive. Just be careful and do a LOT of homework.]

While some scenarios would seem to be obvious; like doctors requiring personal data for vital interest, lawyers requiring personal data for legal reasons, or service providers requiring personal data to fulfil a contract, the devil, truly is, in the detail. Getting this wrong not only has a direct impact on your ability to demonstrate ‘compliance’, but you may also be implementing all the wrong controls.

And that’s the point of this blog; what to actually DO with the lawful determinations once they’re made? Because there is actually a very good chance that what you end up doing is not what the lawyers told you to do, because it would just be too bloody difficult/expensive. It would probably be inappropriate as well. I can think of several examples where you will / should actually change your business processes rather than implement what would be required to maintain them in a ‘GDPR compliant’ manner.

But please don’t see this as compliance getting in the way of your business, rather you now have a compliance driver to do what you should have been doing all along. GDPR is not there to tell what to do, it’s there to have you justify what you are doing.

Before Implementing the Lawful Bases for Processing:

o

1. Determine if it’s the RIGHT decision – This may sound strange given what I said above, but the lawyers are only going to make decisions based on the facts / evidence provided in the Process Mapping step, they will likely have little insight into [or care about] the criticality of the business process in question. Or of the impact changes will have on the business.

For example: should the lawyers state that ‘Business Process A’ requires consent, from a technology perspective you will have to implement data subject’s rights of access, rectification, erasure, restriction, AND portability to each and every individual. Does this make sense to the business? Is it really worth the effort?

If the answer to the above is ‘No’, then you will have to change your business process to one that balances both compliance and business needs. I’m not saying you have to change the lawful basis, but maybe if you just stopped collecting certain data? Only the business can make this determination;

2. ‘Minimise’ what’s left (Data Categories) – Data Minimisation is, by itself, one of the 7 Principles of GDPR, and has to be in place by law. But now you have a really good reason to put it into effect; the less data you have, the less you have to do with it. You must ask 3 questions:

i. Do we even need the data?;
ii. Do we need ALL of these data categories?;
iii. Can we tokenise / anonymise / pseudonymise any part of what’s left?

Obviously if the answer to any of these three is ‘Yes’, do those things before doing anything else. Not only will you in one relatively simple step reduce your workload, you will have significantly reduced your risk;

3. Consolidate what’s left (Data Sources) – Just because you need something, does not [necessarily] mean that you need several of that something. In most organisations, the amount of data that is duplicated in applications/databases/spreadsheets is quite frightening. You only need ONE copy of something (along with all requisite access and resilience obviously);

4. Shut down / amend the legacy data acceptance channels (“stop the bleeding”) – Now that you’ve worked out what you need to keep, stop the bad stuff coming in. Whatever your ‘acceptance’ channels are (batch data from clients, web-based forms/registrations, third party marketing campaigns etc.), adjust them in-line with your new data source baselines; and

5. Implement appropriate data-tagging and data classification – This may sound like I’m pushing it, but in my mind there’s little point making all of the above effort if you have no way of maintaining your baseline(s) going forward. This is a blog in itself, and frankly too detailed and organisation-specific to bother, but whatever you do, you must keep ‘continuous compliance’ in mind.

Once you’ve completed the above, you can take the whole lot back to the lawyers and have them sign off …again. This is now their baseline for the creation of all necessary policies / privacy notices / data processing agreements / contract addendums and whatever else is needed. Imagine if they had tried to do this on all of your ‘broken’ processes.

NOW you can implement the relevant data subject rights. For some organisations this will be as simple as writing an API or two, for other is will involve enormous amounts of manual labour, others will simply outsource as much as they can. Whatever method you choose will be significantly easier now that you’ve implemented data minimisation.

Whatever choices you make, it will not be the lawyers making the final decisions, it will be the business. Lawyers, like IT and like cybersecurity, are only there to enable, not dictate. But oddly enough, it will be these same three groups working with the business to negotiate a workable compromise long after May 25th has come and gone.

But that’s OK, it’s not about compliance, it’s about doing what you can now, and having a plan for the rest.

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

GDPR Step-by-Step - Process Mapping

GDPR Compliance Step-by-Step: Part 3 – Process Mapping

If you have performed the data discovery exercise laid out in the last GDPR Step-by-Step blog, you will now have a bunch of data with only limited context. For data to become information, you need to provide the appropriate context, which in GDPR terms, is in the form of a ‘business process’.

Every department has at least one, and likely several individual processes that handle personal data, each in their own way. All of these need to be defined as they will each require a determination of their lawful basis for processing, and will correspond directly to the record keeping requirements of Article 30.

For example, HR will have processes for Recruiting, On-Boarding, and Benefits; Sales will have Current Client Management, New Client Prospecting, and Telesales; Marketing will run campaigns based on data from past/present/future clients, and so on. Not one of these processes use the exact same data sources, nor will they have the same deliverable. It’s that unique combination (plus a few other factors) that determines how many business processes you will need to define.

However, the first thing you have to do is start building a ‘master list’ of all data categories from which each team will then provide all other data mapping elements. Data Categories are the ‘base unit’ of the GDPR implementation and will include everything from Names, Addresses, Mobile Number, Next of Kin, Passport Number, and potentially hundreds of others (unless your business is relatively small).

This is the part that actually causes a lot of confusion for organisations; what exactly constitutes personal data? Here you must turn to the definition of direct and indirect identifiers;

  • Direct Identifiers’ are “data that can be used to identify a person without additional information or with cross-linking through other information that is in the public domain.” e.g. Passport Number, SSN/NIN, Address etc.
    o
  • Indirect Identifiers’ are “data that do not identify an individual in isolation but may reveal individual identities if combined with additional data points.” e.g. > 80 percent of people in the US can be uniquely identified just by combining date of birth, gender and post code.

You will notice that even a Name is not a direct identifier, as there can be many people with the same name (there are over a dozen “David Frouds” on LinkedIn alone for example). But this also means that ALL data fields you have collected against an individual are potentially personal data (include ‘preferences’ like favourite dog). Just because you cannot tell who I am from a single piece of data (Salary for example), you will likely be able to do so from the combination of Department/Supervisor/Gender/Age, so all of these must be included.

Usually each department builds their own master list of data categories, but because a lot of departments may share data sources it is important that the organisation maintain a company-wide list as well. Standardisation is key.

So, now that you have a list of all data categories your business process uses, you must assign the following to each and every one:

Data Category ‘Metadata’:

  1. Category of Individual‘ – e.g. Current Employee, Potential Client, Candidate and so on. This will likely be the same for an individual business process;
    o
  2. Category of Personal Data‘ – e.g. Contact Data, Salary Data, Performance Data and so on;
    o
  3. Mandatory‘ – Yes or No – Is the data category in question absolutely necessary to complete the business process, or is it a nice-to-have? You would be surprised how much data is collected without a defined requirement in a regulatory, legal or contractual mandate;
    o
  4. Responsibility‘ – Is your organisation the Controller, Joint Controller, or Processor?;
    o
  5. Data Type‘ – Direct, Indirect, Special Category etc.; and
    o
  6. Retention Period‘ – How long do you need to keep the data, but again, this should be compared against a defined requirement in a regulatory, legal or contractual mandate

Categorise Your Data Sources:

Unless you are completely digitally transformed or optimised, it is very likely that you not only have several sources of data for each business process, you also have data in several different locations and formats. The following should be defined against every data source:

  1. Friendly Name‘ – What does everyone call it? Does not matter what it is as long as it’s known to all concerned;
    o
  2. Functional Responsibility‘ – Who manages the data source? Here you will need to differentiate between internal / third party AND the location of the managers i.e. in the EU, or based in a third country;
    o
  3. Data Type‘ – database, flat-file (e.g. spreadsheet), application export and so on; and
    o
  4. Location of Data‘ – While you will want to know EXACTLY where the data is for asset management, for now just an indication of ‘in the EU’ and ‘not in the EU’ will suffice.

Business Process Narrative:

With your data categories fully mapped you must now ‘tell the story’ of your business process in order to provide the remaining context for the legal team for them to make legal basis determinations. As well as complete the record keeping requirement per Article 30:

  1. Purpose of Processing‘ – This can be as simple as ‘Payroll’, but if it’s a little more complicated than that you must explain in detail exactly what the business process is designed to achieve. Let the lawyers summarise this appropriately;
    o
  2. Relevant Obligations‘ – Not every business process will have entries here. But where a law, legal or even contractual obligation is present, list them here. ‘Recruiting’ will be subject to anti-discrimination laws for example;
    o
  3. Outputs to Third Parties‘ – Does the output of your business process go to third parties? if yes, to whom?;
    o
  4. Outputs to Third Countries‘ – Does the output of your business process go to third countries? If yes, to where?; and
    o
  5. Description of Security Measures‘ – High level stuff; encryption (storage and transfer), pseudonymisation, RBAC, access audits and so on.

Now take all of this and give it to your legal experts for Part 4 in the GDPR Step-by-Step series; Lawful Basis for Processing.

Obviously every organisation is different and what I’ve detailed above is overkill for some and nowhere near enough for others, but these are the basics.

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

GDPR - Data Discovery

GDPR Compliance Step-by-Step: Part 2 – Data Discovery

In truth, this should be called Data Discovery & Asset Management, because there’s absolutely no point having one without the other. Nor should these things not already be part of your standard practices.

It’s 2018 and I can think of very few businesses who don’t have data as some of their most critical assets. No businesses bothering to read my blog anyway. So if data assets are that critical, why don’t you already KNOW where all of your personal data is? Why don’t you already have a record of who has access to it, and what they are doing with it?

Assuming yours is like 99.9% of business out there, you don’t have these mappings, and the reasons are as myriad as the business themselves. And maybe it didn’t matter that much up to now, but now it does. Very much so.

Under GDPR you are responsible for:

  1. Determining your lawful basis for processing for each of your separate business processes (both internal and client facing);
  2. Implementation of data subject rights in-line with 1. (erasure, portability etc.);
  3. Data minimisation (during collection and data retention);
  4. Data confidentiality, integrity, and availability (all to defensible levels);
  5. ‘Legitimising’ all transfers of, and responsibilities for, data to third parties

…and so on.

How exactly can you perform any of these things if you don’t KNOW what you have and where it is?

So assuming you agree with me so far and you need to get started, you have 3 choices:

  1. Run a series of interviews and questionnaires with all unique departmental stakeholders to manually track this stuff;
  2. Run some form of data discovery technology to find the data on end systems / databases / other file stores etc.; or
  3. Do both at the same time

Clearly 3. is the best option because a) you’ll need to involve the departmental stakeholders at some point anyway, and b) no manual process will ever find the stuff you had no idea was even there (which will be a lot).

While I’m not going to go into step-by-step instructions on how to run the two main processes above – which are bespoke to each business – I will provide sufficient guidance for you to ask the right people the right questions:

Interviews and Questionnaires

At a bare minimum, you will need to collect this information from all the non-IT departmental verticals (HR, Sales, Finance etc.):

  1. All categories of data received (name, phone number, home address etc.) both ‘direct’ and ‘ancillary’;
    i. Direct Personal Data (DPD, my term) is any data that by itself can determine the data subject – e.g. email address, mobile phone number, passport number etc.
    ii. Ancillary Personal Data (APD, again, my term) is any data that in and of itself cannot be used to determine the data subject, but a combination of APDs may do so. Or the loss of this data along with the related DPD would make the breach significantly worse – e.g. salary, disciplinary actions, bonus payments, disability etc.;
  2. In which application, database, file store etc. this data is kept – not looking for mappings down to the asset tag, just a general understanding;
  3. Data retention related to each business process – e.g. all data categories related to the ‘x’ process must be retained for ‘y’ years post termination;
  4. List of third parties/third countries – if applicable, from whom do you receive the relevant categories of data, and to whom do you share them;
  5. Other – Ideally you should also be able to determine, per business process, whether; a) you are the controller or processor for each data category, and b) the data category is ‘mandatory’ (process won’t work without it) or ‘non-mandatory (nice-to-have)

Assuming the non-IT stakeholders cannot answer the below questions, you will need to speak to those who can (from IT, InfoSec, relevant third parties etc.):

  1. Location of data sources – physical location, including end-system (e.g. host name of server, AWS instance ID, etc.), data centre, address and country;
  2. Format of data – e.g. ‘structured’ (databases, spreadsheets, tables etc.), and ‘unstructured’ (Word documents, PDFs, photos, etc.)
  3. Data ownership – someone has to be responsible;
  4. Security controls – e.g. encryption / anonymisation / pseudonymisation, and everything related to ISO 27001/NIST et al;
  5. Network and data flow diagrams – a ‘baseline’ of how personal data should flow in your environment

Data Discovery

I’m really not sure how the phrase ‘data discovery’ got lumped together with ‘business intelligence’, but that’s the way it seems on Google at least. And no matter which data discovery technology vendor you ask, they can all provide everything you need for GDPR compliance. If you believe them.

For those of you who remember the PCI DSS v1.0 way back in December 2004, you will also remember the disgusting land-grab of every vendor whose technology or managed services fulfilled one of the 12 requirements. You will also remember the even more disgusting price-hikes by those technology vendors, especially by Tripwire, whom Visa was dumb enough to list as an ‘example’ of file integrity monitoring.

So guess what’s happening now? Because every data protection regulation requires you to know what data you have, data discovery vendors are crawling all over each other to push their wares down your throat.

But all data discovery tools are not the same, and unless you can fully define what results YOU need from one, stick to the manual process until you do. These are a few of the questions to which you need answers:

  1. Do I need a permanent solution, or can a one-time, consultant-led, discovery exercise suffice for now?;
  2. Should the solution be installed locally on self-installed server(s), an appliance, cloud-based?;
  3. Can the solution perform discovery on the end-systems, databases, AND traffic ‘on-the-wire’?;
  4. How will the solution manage encrypted files / databases / network protocols?;
  5. Does the solution need to accommodate Cloud-based environments?;
  6. Do I need an agent, or agent-less solution?;
  7. Should the solution be able to perform network discovery (NMAP-esque) and some semblance of asset management to guarantee coverage?;
  8. Do you need data-flow mapping as well?;
  9. Should the solution be integrated with some form of compliance management tool?;
  10. Is this solution to be self-managed or outsourced?

…and the list goes on.

As I’ve stated many times over the almost 5 years I’ve been blogging; “No technology can fix a broken process, it can only make a good process better”. Data discovery is no different, and its many and very significant benefits will only be realised when you ask the right questions.

Don’t know the right questions? Find someone who does.

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

GDPR Step-by-Step Part 1 - Prerequisites

GDPR Compliance Step-by-Step: Part 1 – The Prerequisites

Roughly half the blogs I’ve written in the last 6 months have been about the GDPR or privacy in general. I could take this as a good sign in that it beats hands-down writing about PCI, but the reasons I write about both of these ‘regulations’ in the first place are two-fold:

  1. Organisations do so little homework on applicable regulatory compliance that they leave themselves wide open to unscrupulous vendors and consultants; and
    o
  2. I want to do everything in my power to protect organisations from those unscrupulous vendors and consultants.

From the GDPR’s first release came the “You can get fined 4% of your global revenue!” scare tactics, Now it’s the May 25th ‘deadline’ scare tactics. Millions upon millions have already been spent on vendors spectacularly unqualified to provide GDPR services, and this will continue as long as bullet 1 above remains true.

Therefore, in a series of several blogs, I will attempt to show just how simple GDPR compliance is. That’s right, SIMPLE. Yes, it will likely be bloody difficult, perhaps even expensive (up front), but it is simple. However, while it may be relatively costly in both capital and resource costs, do you really think supervisory authorities expect you to sacrifice the lion’s share of your profits just to achieve GDPR compliance?

Let me assure you that no supervisory authority cares about compliance itself, they care about protecting the human rights of all natural persons. As long as what you do for compliance is APPROPRIATE to the risks inherent in how you process personal data, this will be enough. For now anyway.

As far as I’m concerned not one organisation, regardless of size, region or industry sector, has to perform anything different than the steps I’ll be laying out in this series. The steps are the same, and should always start with the ‘prerequisites’.

GDPR Compliance Prerequisites:

  1. READ IT! ALL OF YOU! – There is not one person who does business with organisations ‘established in the Union’ to whom the GDPR does not apply. Not one. You are responsible in some way of ensuring other people’s personal data is protected, and you should be aware of your rights when it comes to your own data.
    o
    No, the GDPR is not the easiest read, but even a single pass through would remove a significant chunk of the confusion, AND put you in position to ask better questions. NB: This may help – GDPR in Plain English
    o
  2. Senior Leadership Buy-In – Like everything else, if the top people in an organisation are ignorant and/or ambivalent, so will everyone else be. Even if someone did care, they’d get no support. Your Board of Directors don’t have to be GDPR experts themselves, but they had better take it seriously. The accountability principle will likely attract civil penalties as supervisory authorities write aspects of GDPR into national law.
    o
  3. Stakeholder Training – This can be as simple as a one day engagement where an appropriate representative of each departmental vertical (HR, Sales, Operations etc.) undergo GDPR training bespoke to their business needs. While you’re not going to get all the way to lawful basis(es) for processing, determination of the appropriate next steps should be relatively straightforward. So should the removal of the fear-factor that has no place in this process.
    o
  4. Designation of Project Ownership – If you already have a Governance function, this is easy, just give it to them. If you don’t, you will have to assign the initial project to someone with enough knowledge AND influence to be effective. Yes, than can be an external consultant, but it’s much better if they are an internal resource. Or even better, a team of resources.
    o
    The list of action items at this early stage are already well defined, the most important one being the rounding up and ‘orientation’ of subject matter experts from each unique part of the business.
    o
  5. Find Appropriate Legal/Privacy Expertise – Regardless of how much you can do yourselves, unless you already have a qualified in-house resource, you are going to need help. From determining the legal basis(es) for processing, to privacy notices, to contract clauses, parts of your business are going to change. Don’t cheap out and hire a muppet, but don’t get fleeced. Find an appropriate resource to get you through this stage. Just bear in mind there are a LOT of generous experts out there who are making their knowledge and even templates freely available. Use them where you can.

For those of you who have already performed a GDPR implementation engagement, the above may seem like something the tooth-fairy would propose. It’s simply not realistic. And while I somewhat agree, if you don’t at least TRY to put the above in place first why are you even getting involved?

I will admit that you can begin a GDPR project without ANY of the above – that’s next week’s Step 2 -, it’s just significantly more difficult.

Again, the implementation of GDPR is simple, but only if you’re in a position to ask the right questions.

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