GDPR Step-by-Step - Operationalise

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

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

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

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

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

So why can’t you just replace “information security controls” with “data protection controls”? Because the entirety of ISO 27001 covers only 1 of 99 Articles in GDPR (Article 32), the rest of the Articles cover aspects of data protection that the ISO standard was never designed to encompass. Nor should it try.

That said, a lot can be learned about how to adopt GDPR’s “appropriate technical and organisational measures” by bridging them with the ISO concepts. As partially demonstrated by this white paper from IAPP and OneTrust; Bridging ISO 27001 to GDPR (my thanks to Gabriel Avigdor for bringing this to my attention).

In the end though, to operationalise GDPR you will be implementing some new concepts [to you anyway], as well as taking existing concepts to a whole new level. Still simple, and still bloody difficult, especially without appropriately qualified expertise.

Things to operationalise:

  1. Senior Leadership Commitment: Leadership commitment to cybersecurity is one thing, but GDPR has the potential to significantly impact the way an organisation performs its core function(s). The commitment from the CEO/BoD has to pay a lot more than lip service, data protection needs to be built into the company’s values and goals. They need to live and breathe this stuff or no-one else will;
    o
  2. Governance: GDPR is the perfect program to put in the hands of governance. What other function in the organisation has both the support from senior management AND representation from all departmental verticals?;
    o
  3. Employee On-Boarding: Lost count of the number of times I’ve harped on about this one. Go here if you want more, just add ‘data protection’ to the list of subjects HR could help address; Human Resources, the Missing Piece From Every Security Program;
    o
  4. Employee Awareness & Training: As stated above, data protection is everyone’s responsibility, so every employee MUST receive training appropriate to their role within the organisation;
    oprovacy law
  5. Policies, Standards & Procedures: Data protection adds a whole raft of ‘paperwork’ to any organisation. Without appropriate document management, these will not keep up with the changing face of privacy law. In this respect, data protection is no difference from cybersecurity, as without your ‘paperwork’ in place you will never be compliant with anything;
    o
  6. Risk Management: This is almost identical to the risk management performed for cybersecurity and IT; 1) measure your risk, 2) determine whether your current controls meet the risk, 3) if yes, do nothing, if no, remediate the gap(s), 4) repeat. Of course there are differences, in that a normal risk assessment will not cover the requirements of a Data Protection Impact Assessment (DPIA), but the process is VERY similar and will likely involve much the same people;
    o
  7. Asset Management: Core to cybersecurity, and core to data protection. You cannot manage what you don’t know you have. However, while cybersecurity cares about the security controls you have in place around the data assets, data protection cares about what you’re doing with the data. This takes asset management to a whole new level, a level you have no hope of achieving if you can’t manage your data life cycle;
    o
  8. Vendor Due Diligence: While you could almost get away from not doing this well for ‘just’ security, under GDPR your third parties must ALL be held to much higher standards. There is little room for error in both contracts and ongoing service monitoring, as you could well end up 100% liable for their failings. Controller/Processor relationships are critical;
    o
  9. Incident Response / Breach Management: Like vendor due diligence, organisations are very lazy about getting incident response right. Not under GDPR, there will be very few excuses supervisory authorities will accept if you cannot, as a controller, report a breach after 72 hours of being notified. You will need a very good REASON;
    o
  10. Record Keeping: Unless your organisation has fewer than 250 employees AND your processing of personal data is ‘occasional’, you will need to keep a record of your processing activities. For most this will be a manual process on a spreadsheet, but that does not mean it should not be assigned ownership and warrant frequent review at senior level.

There are literally dozens of other things that need to be addressed, but I think these are the big ones. It’s actually quite scary how similar these are to security. Which perhaps explains why security people get cornered with this stuff so frequently. But while there are definite similarities, even parallels, the differences are profound and must be addressed by the appropriate skill-set.

If you only get one take-away from this GDPR Step-by-Step series, I hope it’s this; There is nothing new here. In some way, shape, or form, EVERYTHING required of you for GDPR has been done before, and there are a many people out there who have done it.

All you have to do is a little homework…

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

GDPR Step-by-Step - Documentation

GDPR Compliance Step-by-Step: Part 5 – Documentation

As a consultant there’s nothing I like more sitting around a table with a bunch of really smart people simplifying complex issues and guiding them towards an appropriate and effective security program.

Then someone has to go spoil the ride by saying; “That sounds great David, when can we expect the report?” [sob] 

‘Documentation’ really should be a 4-letter word.

But with the GDPR, you have no choice. Documentation is your evidence of compliance. Even if you’re lucky enough not to have to maintain ‘records of processing activities’ (see Article 30(5)), you still have to document everything else, even WHY you don’t think you have to maintain records.

The word “appropriate” appears 115 times in the GDPR final text, and “reasonable” a further 23 times. That’s 138 times in one regulation that YOU have to make a determination of whether or not what you’re doing meets the grade. Lawyers can turn to precedent to agree what’s reasonable, where can WE turn to agree not only what’s appropriate, but to justify it?!

Here’s where the concept of Risk Management comes in, because like it or not, you WILL be taking a risk-based approach to GDPR compliance. And the one thing that risk management demands; documentation.

Note: The following is at a very high level, not comprehensive, and not representative of every organisation’s needs.

First, you will need policies. Not just the information security policies that I usually focus on, but policies that cover all relevant aspects of data protection. You will need policies on things like:

  • General Data Protection / Privacy
  • Employee Privacy
  • Third Party / Third Country Transfers
  • Data Subject Rights
  • Engagement of Processors
  • …and so on.

There are [of course] a bunch of vendors out there promising to provide every document you’ll ever need for £XX+VAT. But NONE of these #gdprcharlatans can provide the appropriate context that only comes from working with a person who knows that the Hell they are doing. These cannot just be paperwork, they must reflect your commitment to data protection by design and default, and the way you do business.

Second, you’ll need a documented record of what data you have a what you’re doing with it, but you should have taken care of this in your data discovery and business process mappings performed in Parts 2 and 3 of this series.

Third, all of your lawful bases for processing and corresponding data subject rights determined at Part 4 should be clearly articulated. Each will have its own idiosyncrasies:

  • Consent – corresponding privacy notices in clear and plain language, no ‘bundling’ of conditions etc;
  • Contractual – employee contracts, client contracts, data transfer agreements and so on;
  • Legal – [I’ll let a lawyer supply samples here];
  • Vital Interest – If lives are at stake you’d BETTER have a lawyer helping you out!;
  • Public Interest – Assuming you’re a public body, you should already have appropriate representation; and
  • Legitimate Interest – you will need to be VERY clear on how your ‘commercial’ interests are not “overridden by the interests or fundamental rights and freedoms of the data subject“.

Fourth, you will need to document all of your security controls in place around the personal data, as well as the risk assessment results that show that the controls meet the defined risk(s). Do not even THINK about showing a supervisory authority your PCI Attestation of Compliance, but a properly scoped ISO 27001 certificate would likely go a long way.

Finally, and if applicable, you will need to document your ‘records of processing activities’. Article 30(5) states; “The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.

So most of us can probably avoid the ‘high risk’ and ‘special category’ caveats, but ‘not occasional’? While ‘occasional’ is hard to define (like reasonable and appropriate), if you are processing personal data as part of a defined business process, it is unlikely that you will get away with saying “it’s only once a month” (for example).

That said, the requirement for maintaining record are not THAT onerous, unless you have hundreds of separate processes. They should also be made very clear by your supervisory authority. The UK’s ICO for example has even provided two templates, one for controllers and one for processors (near the bottom of the page).

I know this sounds like a lot, but with the exception of the lawful bases and records, you should already have the rest of this. If you don’t, not only will next week’s GDPR Step-by-Step be impossible, so will GDPR compliance.

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

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