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 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 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. name, 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 ‘payroll’ process must be retained for x years post termination;
  4. List of third parties – 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.

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 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 Deadline

GDPR: May 25th is NOT a Deadline!

It seems there are only two ways to sell GDPR products and services:

  1. Tell everyone they are going to get fined €20M or 4% of their annual revenue; and
  2. Tell everyone that they only have until May 25th to get compliant or they’re in big trouble

These are both utter nonsense.

While the monster fines are a theoretical possibility (per Article 83), I would hope by that you know they will be reserved for the VERY worst offenders. If you don’t, read this from the UK’s Information Commissioner herself; GDPR – sorting the fact from the fiction. With my favourite quote being:

Issuing fines has always been and will continue to be, a last resort. Last year (2016/2017) we concluded 17,300 cases. I can tell you that 16 of them resulted in fines for the organisations concerned.”

And not one of these 16 (0.09% of the total!) was anywhere near the maximum of £500K, so forget the damned fines!! Unless of course you work for a bunch of total scumbags like Keurboom, then I hope you get completely reamed.

Anyway, so here we are, less than 3 months away from May 25th, and the ‘deadline’ for compliance is the most prevalent scare tactic!

“Get compliant before May 25th or else!!” “Deadline fast approaching!!” “Trust me, I’m a certified practitioner!!”

The thing is, “or else” what, exactly? What do you think is going to happen on May 25th? That your supervisory authority is going to be banging on your door with cries of “Article 30!! Show us your records!!“? Do you expect to receive hundreds of requests for access from people who know even less about GDPR than almost anyone reading this blog? Do you think you’ll suddenly be the subject of a class action suit?

Do you think your supervisory authority even knows who you ARE at this point? [No offence]

I’ll tell you what’s going to happen on May 25th …not a bloody thing different. It will be business as usual.

However, what WILL happen from May ONWARDS is a gradual increase in how the GDPR is enforced in each member state. Guidance from supervisory authorities will increase in-line with the real-world issues they face; certification mechanisms will be released forcing all organisations to at least review and consider them; the general public will gradually come to expect the heightened protection mechanisms and vilify those organisation who are not up to speed and so on.

To put this another way; Data Protection law is not going away and cannot be ignored. By anyone. In fact, in light of things like AI/ML, Big Data and the Internet of Things, data protection is only going to become more embedded in everything we do. It has to, and you need to keep up with it.

So the more time that passes the fewer excuses you will have for doing nothing, regardless of the size / type / industry vertical in which your business operates. In the UK for example you are already 20 years too late to be proactive. The DPA has been out since 1998 and compliance to it would have covered the lion’s share of the GDPR. Which itself has been out for almost 2 year.

While I can sympathise with organisations fumbling around but doing their best, I have little sympathy for organisations who have done nothing. It’s these folks who should be the most concerned, not for May 25th, but every day after it.

Not one organisation out there is incapable of doing these 6 things before the ‘deadline’. Not to completion perhaps, but a good chunk:

  1. Find out where all your personal data is; – [even crappy questionnaires and interviews will get you most of the way there]
  2. Map that data to the business processes that created it; – [HR, Sales, Marketing and so on…]
  3. Agree on which business processes should continue as they are, which should change, and which should stop altogether;
  4. Get rid of all instances of personal data that do not support the agreed business processes;
  5. Obtain appropriate guidance on the lawful basis(es) for processing what’s left; and
  6. Commit, in writing, at the Board level, to achieving full compliance

While this is nowhere near a full demonstration of compliance, you have done 3 things that the ICO have every right to expect. You have:

  1. reduced your risk by minimising your threat exposure – you can’t lose or misuse what you don’t have;
  2. done your best to ensure that you are supporting the data subject’s rights – the whole point of this exercise; and

I don’t care if you only achieve full compliance 5 years from now, and it’s unlikely the supervisory authorities will, if, and ONLY if:

  1. Your commitment is real;
  2. You have a plan; and
  3. You don’t get reported or breached

It’s up to you to do ENOUGH now to make sure 3. doesn’t happen, work on the rest when you can. Just make sure you can justify your timelines.

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

GDPR Certification

What Will GDPR ‘Certification’ Look Like?

From my current perspective, these are the 3 most significant unknowns in the implementation of GDPR:

  1. The appropriateness of Privacy Shield (i.e. it’s not);
  2. What will ‘Representation’ look like (per Article 27); and
  3. What will ‘Certification’ look like (under Articles 42 & 43)

There will certainly be more as my knowledge grows, and you will have your own Top 3 depending on whether you know either more or less than me on the subject. Though it’s hard to imagine anyone who’s actually reading this crap knowing less.

I took on Privacy Shield last week, and I’ll take a stab at Representation at some point, but I just got through reading the European Union Agency for Network and Information Security (ENISA)’s ‘Recommendations on European Data Protection Certification1 so naturally I consider myself an expert in the field. Maybe I should create ‘Certified EU General Data Protection Regulation (GDPR) Certification Theory Foundation and Practitioner’ courses?

Basically the subject of ‘certification’ is far from straightforward. Not complicated per se, just very difficult.

For a start, what certification do you mean? Do you mean an organisation getting certified against the GDPR itself? Or do you mean someone who is certified to perform the certification?

First, it’s clear that there cannot be certification TO the GDPR, and that there will be no PCI DSS-esque tick-box exercise to perform. Instead, and only if applicable to your organisation, you will be certified AGAINST the GDPR in terms of adherence to its principles and intent. Or as ENISA puts it; “[…] compliance with the GDPR is not possible to be certified. What can be certified, is compliance with (or else: conformity to) certification criteria that are derived from the GDPR.

‘Criteria’ in this example could be as broad as; “Provide a summary of the appropriate technical and organisational measures in place.” (for Article 32). Or it could go as deep as; “For data protection, describe your encryption/anonymisation/pseudonymisation mechanism(s), including [where relevant] the cipher type and bit strength.”. Either way, it’s not telling you what to do, it’s making you demonstrate the appropriateness of what you have (i.e. compliance ‘against’, not ‘to’).

ENISA also makes it very clear that we must be specific and accurate in our terminology. ‘Certification requires the “provision of assessment and impartial third-party attestation that fulfilment of specified requirements has been demonstrated.“, whereas a ‘self-assessment‘ (first or second-party) can only lead to a self-declaration of conformity, never certification.

By far the lion’s share of organisations will be self-assessing, as hiring a third party to perform an onsite assessment would be overkill for a voluntary process (surmised from Art. 42(1) final sentence and Art. 42(3)). Yes, this could make a farce of the whole thing (like PCI SAQs), but should you BS your way through your self-assessment what do you think the supervisory authority is going to do if you appear on their radar? (Articles 58 and 83 for your reference.)

What I think this means in practice is that ‘compliance‘ will consist of demonstrating that your controls, processes, and documentation related to the processing of personal data are appropriate to meet the intent of the Regulation. And while that sentence seems to be just as wooly as the Articles 42 and 43 themselves, it should actually be very good news for you.

Why? Because it means that while no certification or even self-assessment mechanisms are available (and won’t be for some time) that compliance with the GDPR is determined by you!

Yes, you should be able to demonstrate that you are meeting the intent, and yes, you will actually have to fix what you know you’re doing wrong, but it means that May 25th is no longer a deadline, it’s an indication of your risk appetite. In other words, do you [stupidly] do nothing and wait for more definitive guidance, or do you do the best you can now until such times as a bar can be set by the supervisory authorities?

So, as I stressed way back in There is No Such Thing as GDPR Certification …Yet!, there still isn’t, and ANYONE with the word ‘certified’ anywhere near the word ‘GDPR’ is no more qualified to help you than someone who has done a few weeks of reading on their own (like me).

To reiterate one more time (for the UK):

  1. There is no certification mechanism for organisations wanting to validate GDPR/DPA compliance through a third-party;
  2. There is no official self-assessment mechanism for organisations wanting to self-assess their conformity to GDPR/DPA;
  3. There are no organisations able to provide ANY form of OFFICIAL certification program for businesses or individuals; and
  4. There are no individuals certified to a program sponsored by ANY body associated with the administration of GDPR/DPA

For certification to work in a harmonised fashion across all member states there is still a lot of work to be done. I cannot see a mechanism for certification, self-assessing etc. in place for some time. So UNTIL they officially announce one, focus on doing the basics that will be required regardless of how this issue get settled.

Waiting for this certification mechanism before you do anything towards compliance is no different from letting yourself drown until someone throws you a life preserver. The first steps in ANY GDPR project are as simple as they are common sense:

  1. Find your personal data;
  2. Map the data to your business processes;
  3. Get rid of everything you don’t need;
  4. Protect the rest with appropriate security controls; and
  5. Determine your lawful basis(es) for processing.

ALL of these things can be done now by anyone, and once they are done, the remaining aspects of GDPR implementation will be reasonably self-evident. Yes, 5. may be difficult for non-legals, but you’d be amazed at the number of qualified people out there willing to help for next to nothing in return.

Basically stay away from anyone promising you certification of any sort, and just keep swimming.

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

1 My thanks to Gabriel Avigdor and for his direct guidance/advice and for his excellent blog;

EU Citizen

GDPR: It’s Not Just About EU Citizens, or Residents

It is with some chagrin that I write this post. I fell for the very thing that I have warned my clients about for decades; “Read [regulation name] carefully and NEVER make assumptions, and if you don’t know something, ask someone who does!” Here I am now having to admit that I thought the GDPR was only about EU citizens.

It’s not.

The WORD ‘citizen’ never even appears in the Regulation. Not once. In fact, I’ll go so far as to say that it’s not even about EU residents, because that word never appears in the Regulation either. Neither of these words is what GDPR means by “in the Union“.

I take some very limited solace from the fact that I have never claimed to be a privacy expert, but my ongoing mission of pushing everyone to actually read the GDPR carefully makes me something of a hypocrite. So apologies for that, I should have known better.

But even now that I have read the relevant Recitals and Articles, and asked real experts for guidance, I am still only able to make assumptions. I know that somewhere, someone(s) knows exactly what all of this means in practice (and precedent) as there is very little ‘arbitrary’ about the law. Hopefully these someone(s) jump in at the supervisory authority level.

So the real point of this blog is NOT to impart knowledge, or instruct, I am unqualified to do so. It is to gather feedback, or even opinion on the below interpretation(s). And yes, I have reached out to both the ICO and Art. 29 WP for clarity, but I doubt I’ll get much back anytime soon.

[Note: I won’t name the people who have provided the following guidance (unless they want me to), but I thank them for it. That said, if I’m still way off the mark the blame is entirely my own.]

First, the KNOWN Facts:

  1. Nowhere in the GDPR, or any referenced document [of which I am aware], are the phrases ‘data subject’ and ‘natural person’ tied to ‘EU citizenship’ or even ‘EU residency’;
  2. Recital 2 states – “The principles of, and rules on the protection of natural persons with regard to the processing of their personal data should, whatever their nationality or residence, respect their fundamental rights and freedoms, in particular their right to the protection of personal data. […]” – [this is, after all, a human right];
  3. Recital 14 states – “The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. […]” – [it does not matter who or where they are];
  4. Recital 22 states; – “Any processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union should be carried out in accordance with this Regulation, regardless of whether the processing itself takes place within the Union.” – [a business established in the Union can [with caveats] process the data anywhere in the world, GDPR still applies];
  5. The phrase – “[…] in the Union […]” appears frequently in relation to scope and/or applicability – [i.e. regardless of nationality and location];
  6. Article 3(1) states – “This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.” – [regardless of 4. above, GDPR still applies]; and
  7. Article 3(2) states – “This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to […]” – [applies to non-EU establishments if they ‘target’ people in the Union]

Now, the Assumed ‘Facts’:

  1. If your personal data is collected and processed while you are physically IN the Union, and Article 3(1) or 3(2) apply, it does not matter what your nationality is, nor does it matter where you live normally. GDPR applies.;
    Scenario: A US citizen is on holiday in the UK and orders something from an e-commerce merchant ‘established’ in the Union. The site collects personal information. GDPR applies.
  2. For processing of personal data outside of Article 3(1) and 3(2), it doesn’t matter whether you’re an EU citizen or not, GDPR does NOT [necessarily] apply;
    Scenario: Someone ‘in the Union’ orders online from a merchant based in the US, who has made no effort whatsoever to market/aim their services to anyone outside of the US. All payments must be in USD. Just because they agree to ship the merchandise to the EU does not, by itself, put the merchant ‘in-scope’ for GDPR, even if they do collect personal data.
  3. Even if you are not ‘in the Union’, the processing of your personal data by an establishment whose activities provide the context for the processing are in the Union, is in scope for the GDPR;
    Scenario: A citizen, including non-EU, is on holiday in the US and orders online from an e-commerce merchant ‘established’ in the Union. GDPR applies.

In the end it’s becoming clear that being an EU citizen does not give you rights anywhere outside of the boundaries of Union law. It is also clear that regardless of your nationality, or where you live, doing business with Union-based organisations may give you rights that it’s quite possible you are not receiving in your own country (especially in the US).

And not that I’m particularly bright, but for me to make such a fundamental mistake in interpretation further supports my contention that you should only ever take guidance from proven privacy experts. This is just too important to rely on people who have only recently jumped on the bandwagon.

Again, I am not saying that any of my assumptions/interpretations are facts. I actually expect to be corrected. About the only benefit you can get from this is you should now have your own questions to ask.

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

Have You Forgotten About the ‘Cookie Law’?

You’ve all heard of the Cookie Law, right?

If the answer is no, and your business has a website that uses cookies (or other ‘online identifiers’), I would suggest you do a little homework. The upcoming EU ePrivacy Regulation not only expands significantly on that law (which is actually a Directive), it includes a fine structure on par with the GDPR.

The Cookie Law is actually the EU ePrivacy Directive  and was responsible for the incredibly irritating banners that pop-up on almost every website in the EU. About the only good news for some organisations is that the banners will likely go away under the new Regulation.

Even for those who are aware of the ePrivacy Regulation (perhaps have even read it), there is still a great deal of confusion. Not just related to the contents of it, but as to whether or not it’s even relevant with the GDPR already covering ‘privacy issues’.

Just 15 minutes of research reveals the following:

  1. The ePrivacy Regulation “particularises and complements” the GDPR – In other words, ePrivacy is an expansion on a single aspect of the GDPR. In this case ‘electronic communications’ (e.g. the ‘online identifiers’ referred to in Recital 30);
  2. ePrivacy covers Article 7 of the Charter of Fundamental Rights of the European Union (“the Charter”), the GDPR covers Article 8;
  3. It’s not just about cookies, it covers EVERY aspect of electronic communication. Including; “…calls, internet access, instant messaging applications, e-mail, internet phone calls and personal messaging provided through social media.“, and all ‘metadata’ relevant to the communication channels themselves;
  4. Unlike the GDPR, it does not just apply to ‘natural persons’, but to ‘legal persons’ as well. i.e. business-to-business; and
  5. It has the most significant impacts in the area of marketing.

So, if your business has a website, performs marketing, or communicates with clients over ‘electronic channels’, you are in scope.

So why isn’t there anywhere near the kind of panic and hype over this Regulation as there is GDPR? If anything, I’d say this one has greater impact on most business, with a far greater degree of negative impact on how you are currently conducting your business. Just ask an online publisher what they think of it and brace yourself for the answer.

Imagine, for example, you provide online content free of charge. Your revenue is driven by online advertising which is in turn personalised to the viewer by cookies. Under ePrivacy you could no longer rely on pop-up banners to force acceptance of cookies, instead you have to rely on the viewer accepting cookies by default in THEIR web browser. Not only that, the Regulation is basically suggesting that all browsers should be ‘blocking all cookies by default’, then, in plain language, walk every citizen through changing the defaults to more ‘merchant-friendly’ settings.

However, here are a few bloody BRILLIANT outcomes:

  1. Unsolicited marketing phone calls should use a prefix on their numbers so you know what it is before answering! And no, they cannot get around this by blocking the caller ID;
  2. Inclusion of your personal data in ‘publicly available directories‘ (a.k.a. marketing lists) must be done with consent; and
  3. Any kind of “listening, tapping, storing, monitoring, scanning or other kinds of interception, surveillance or processing” of your personal data is strictly forbidden (the usual deprecations apply, e.g. ‘pubic interest’)

Not surprising that during the ‘Stakeholder Consultation’ conducted from 12 April to 5 July 2016 that 83.4% of citizens were for it, but 63.4% of businesses were against it. The lobbying that has taken place to soften the wording, while fruitless so far, has had the likely impact of delaying the enforcement of the regulation beyond the proposed data of 25 May, 2018 (yep, same date as GDPR, that’s how closely they are linked).

So I frankly have no idea why GDPR is such a big deal and ePrivacy is so obscure, but you just know it’s because only one of these is easily monetised by snake-oil merchants. GDPR attracted cybersecurity “professionals” because it’s about ‘data protection’, and lawyers because of the ‘lawful bases for processing’ and the requirement for DPO.

ePrivacy on the other hand provides no easy remedies, but you know they’re coming.

The bottom line here is that if you’re not familiar with it, get familiar, it WILL impact you. Once again, for those in the UK the ICO has lots of material on its website, but look for Privacy and Electronic Communications Regulations (PECR)¹ instead. Like how the DPA is the UK’s implementation of GDPR, PECR is ePrivacy.

Happy reading.

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

¹ (Hopefully the acronym will be pronounced/known as the ‘Pecker Law’ which should give our American friends a good laugh).