GDPR - Let's give the project some shape

In my previous article, “Opportunity Calling - The General Data Protection Regulation (GDPR),” I mentioned the notion of not being driven by the text (i.e. the articles and recitals that make up the General Data Protection Regulation) during the initial stages of an alignment project - “don’t get bogged down in the details” - and suggested that one might be better off gaining a good general understanding (perhaps paying particular attention to the 6 principles (Article 5) and the ICO’s “12 steps to take now”) and using that to shape the project and/or wider data governance programme.

It’s not a tick box exercise

One of the biggest differences between the GDPR and other legislations and compliance obligations is that it’s principle based rather than a set of hard and fast rules. I think this makes many a senior manager uncomfortable, as they instinctively want to take the “problem” and turn it into a task list - “just tell us what we need to do” is something I hear often at the moment - doing so makes the whole thing binary and therefore easier to manage and understand. I’d argue that this approach is flawed and that the GDPR is designed such that it can’t be turned into another tick box exercise that’s destined to fail in achieving its goals. I’ve heard it said (in the context of GDPR) that sticking to the letter of the law isn’t necessarily enough, as one must be seen to enter into the spirit of the regulation. For me, this is where the beauty of the legislation lies - there is no bare minimum - embrace it, or fail. Perhaps this is why many organisations have found it difficult to start or know where to start, they’re thrown into a quandary when they realise that the traditional approach of doing the least possible (just doing enough to get the certificate) isn’t going to work.

If you’re aiming for compliance, you’re doing it wrong

If you’ve been reading about the GDPR then you may have heard that aiming for compliance (at this stage) is not the best approach (or words to that effect). One reason for this is that we don’t know what compliance looks like yet (case law post 25 May 2018 will help us to build a picture of what compliance truly looks like), you’ll have to settle for “alignment” and/or “maturity” at this stage, though be sure to seek specialist legal advice to ensure that your planned efforts will put you into a defensible position. Another reason is that “compliance” suggests a line in the sand - job done, box ticked, “certification” achieved. Nothing could be further from the truth when it comes to the GDPR - privacy needs to be embedded into every organisation that processes personal data, it needs to be continual, become operational and “by design and default” - 25th May 2018 is arguably just the beginning.

Personal Data IN - “Purpose.” Personal Data OUT - Subject Access Requests (SARs) and Data Breach.

Okay, so it’s not quite as simple as the heading suggests but it’s not a bad initial approach - start with purpose at one end and SARS and data breach notifications at the other - work backwards from / reverse engineer the SAR and breach notification requirements to establish what needs to happen for you to be able to execute and deliver on them. Be clear as to your purpose for collecting personal data in the first place, establishing the legal basis for processing should then be relatively straightforward (famous last words!).

Do more with what you already have

Many of you will already have products/solutions in place that can help with GDPR (this could be anything from a security related product to a document management platform), review how they’re being used currently - are you making full use of them? Are they being used correctly? Are there policies, guidance, and instructions in place to support their use? Is there an upgrade available that’s better aligned to the GDPR or one that introduces new features designed to help you on your journey to compliance? Be sure to sweat your existing assets before you go out shopping for technology solutions.

So, how do we give the project shape?

The following is just one way of breaking the project down into three (high level) logical phases, that it is not to say that some of the activities involved cannot run in parallel with each other.

Information You Hold and Awareness

This phase includes data discovery, classification and mapping - for most this will be the first phase in the project. With this being the first phase, it should also contain some high value, low cost, quick wins such as a training and awareness programme and perhaps penetration tests to identify and mitigate any high-risk security items. You may want to conclude this phase with a Data Protection Impact Assessment (DPIA) to validate the measures taken during this phase and to reaffirm the planned actions in the phases that follow.

Data Marking and Breach Notification

This phase (some might say phase 2) will include data marking and the implementation of measures required for successful data breach identification and notification. This phase could also include items such as retention policy, backup and restore, purpose limitation, access control and items relating to data change control (data minimisation, storage limitation, etc.)

Privacy Information, Consent and SARs

This phase will include updating privacy policies (and communicating them accordingly), establishing the legal basis for processing and consent mechanisms and management (if required). SARs will need to be tested.

There are few shortcuts

The measures required for GDPR alignment are intricate and there are many interrelationships and dependencies between the numerous individual components. Missing a single component could have a detrimental affect on your ability to deliver breach notifications and/or SARs to the level of detail (and within the timescales) required - reverse engineer breach notification and SAR requirements to avoid this potential pitfall.