Archives

Month: May 2017

You may have noticed that the General Data Protection Regulation is rather in the news lately, and quite right too considering there is only a year left to prepare for the most stringent and wide-reaching privacy law the EU has yet seen. Unfortunately however, in the rush to jump onto the latest marketing bandwagon, a lot of misleading and inaccurate information posing as “advice” in order to promote products and services is flourishing and appears to be drowning out more measured and expert commentary. Having seen a worrying number of articles, advertisements, blog posts and comments all giving the same wrong message about GDPR’s “consent” requirements, I was compelled to provide a layperson’s explanation of what GDPR really says on the subject.

So, let me start by saying GDPR DOES NOT MAKE CONSENT A MANDATORY REQUIREMENT FOR ALL PROCESSING OF PERSONAL DATA.

and again, so we’re completely clear – GDPR DOES NOT MAKE CONSENT A MANDATORY REQUIREMENT FOR ALL PROCESSING OF PERSONAL DATA!!!

So what does GDPR say about consent? It says that to be allowed to process (i.e. do anything at all involving a computer or organised manual files) personal data, you must have at least one “legal basis” for doing do. Let’s call the list of legal basis “Good Reasons” for now, to keep the language friendly.

The Good Reasons are:

when you have consent to process personal data

when there is a contract between you and the individual (“data subject”) or between the individual and someone else which requires you to process their personal data in order to fulfil its terms. This also applies to any processing that is needed in order to prepare or negotiate entering into a contract. Example: buying a house

When there’s a law or legal obligation (not including a contract) that you can only comply with by processing personal data – example, accident reports for health & safety records

when someone’s vital interests are at stake unless personal data is processed (usually only applicable to life-or-death situations – e.g. the emergency services having a list of employee names to identify survivors after a building collapse)

In the public interest or when acting under official public authority – such as political parties being allowed to have a copy of the electoral register (providing they don’t take the mickey in their uses of it).

When personal data needs to be processed for an activity which is in the “legitimate interests” of the organisation (“Data Controller”) or the individual.

Now, just because consent is listed first does not mean that it is the most preferable Good Reason, the most important or the default option. It is none of those things – in fact, when considering which Good Reason applies to processing, the other options should be tested first. If you picked consent because it was top of the list and consent was later withdrawn, but you realised there was a legal obligation to continue to process the data, you would be in a pickle – either you’d be in breach of privacy law (continuing to process when consent has been withdrawn) or in breach of the other legal obligation.

Please note that opting for “legitimate interests” as the Good Reason is not a way of dodging around the prospect that consent may be withdrawn or refused, as there is anabsolute [edit; objection *can* be overridden by the Data Controller in some circumstances] right for the individual to object to the processing of their personal data when “legitimate interests” is the Good Reason for processing. All legitimate interests does is save you the effort of having to obtain and demonstrate specific, informed and freely-given consent before you can have or start using the data.

When it comes to special categories of personal data (formerly known as “sensitive personal data”), there is another set of legal basis (we’ll call these Damn Good reasons) which must also be met for the processing to be allowed. In fact, GDPR says that unless one of these Damn Good Reasons is applicable, then you’re not allowed to process special categories of personal data at all.

The Damn Good Reasons are:

When you have explicit consent

OR

When employment law, social protection law or social security law says you have to do something that requires the processing of special categories of personal data

When the processing is required in someone’s vital interests but the individual is incapable of giving consent

When the processing is necessary and carried out by a trade union, philosophical or religious non-profit organisation to administer their membership operations

When the individual has already and deliberately made the data public

When the processing is necessary to defend legal rights, legal claims or for the justice system to function

When the processing is necessary in the public interest (just like in the Good Reasons list)

When the processing is necessary in order to provide health care, treatment and management of health care services

When public health may be at risk if the processing isn’t carried out

When the processing is necessary for archiving, historical or scientific research, or statistical analysis

Again, although consent tops the list it does not mean that it should be the first choice of Damn Good Reason. As with the other list, it is wise to consider first whether there are other Damn Good Reasons that apply and only choose consent where there are no alternatives.

There is some confusion at the moment about the difference between “consent” (Good Reasons) and “explicit consent” (Damn Good Reasons), especially as GDPR says that for any consent to be valid, it must be “unambiguous”. I’m going to leave the dissection of that to greater minds than mine (see refs). However, I will say that when in doubt, go for whichever approach gives you the most solid evidence.

So that’s what GDPR says about whether and when you need consent.

HOWEVER – another law (the Privacy & Electronic Communications Regulations, aka “PECR”) says that you must have explicit prior consent before sending any unsolicited direct marketing by email. This is not the same as the Good Reason/Damn Good Reason “[explicit] consent for processing” but the separate requirements are often confused. It may be in your organisation’s legitimate interests to collect, store and analyse contact info but if you are emailing unsolicited direct marketing messages you will also need to have obtained consent for email marketing from the recipient.

A few words on mechanisms vs outcomes (if you’re still reading, congratulate yourself on your fortitude!)

‘Consent’ is an outcome – you and the individual have achieved a defined, mutually-understood, relationship in which you as a Data Controller can process their personal data for a particular purpose and in a particular way. This outcome needs to be an ongoing state of affairs. If the individual later decides to change the relationship and no longer allow you to process their data then you no longer have consent (and must stop and current or future processing).

Tickboxes, signatures and “click here” buttons are mechanisms for obtaining consent. However, if the agreement you have obtained using this mechanism is not specific, informed and freely-given then you do not have valid consent under data protection law.

Transaction logs, screen prints, signed documents and call recordings are evidence for the process of obtaining consent. These are only as good as the outcome that the process supports. If the individual has been misled, or they dispute that the processing you are doing is what they actually agreed to, or the processing purpose + Good/Damn Good Reason was not made clear to them, or they have simply changed their mind then you do not have valid consent even if you have evidence that consent was asked/supplied at one point in time. Consent is not a fire-and-forget activity, and consent obtained once is not set in stone forever.

So in order to be able to get and keep valid consent you need to have good processes for obtaining, maintaining and verifying the outcome, ie. the relationship between you and the individual. This means careful attention to training, customer service and content of privacy notices.

So, in summary (well done for getting this far!)

GDPR does not say “all processing requires consent”- and anyone who says that it does, clearly does not know what they are talking about. Ignore them.
GDPR says that sometimes you will need to get consent and when that is the case; it sets out the standards that you must meet.
Consent for unsolicited electronic marketing as required by PECR is not the same thing as consent for processing of data described in GDPR.

I hope that clears it all up.

More about consent under GDPR if that is the Good Reason/Damn Good Reason you need to use:

Unless you’ve been living under a rock, you’ll have noticed that there are lots of people talking about GDPR – which is a good thing.

However, there is lots of nonsense being talked about GDPR – which is a bad thing.

My Twitter timeline, LinkedIn feed and email inbox are being deluged with advertising for GDPR compliance “solutions” and services – which is fine as long as the product in question is treated as a tool in the toolbox and not a magic instant-fix-in-a-box spell for instant transformation

Based on some of the twaddle I’ve seen being talked about GDPR lately, and my own experience in supporting data protection within organisations, here is a list of markers which, should they appear in an article, advertisement or slideshow, should be a warning to treat the rest of the content with a hefty pinch of salt.

Banging on about fines. Yes; there is a big maximum fine. No, it’s unlikely to be enforced except for the most egregious cases of reckless negligence. The ICO has never levied the maximum penalty for any breach ever. Based on the evidence available, fines alone are not really a convincing justification for compliance.

Obsessing about consent. Consent is only one of a number of possible legal basis for processing of personal data. It may not the most appropriate, desirable or “compliant” basis to select and insisting on consent where there is a statutory or contractual requirement for processing personal data; or where the individual has no real choice whether to give consent may result in “unfair processing” which could draw regulatory enforcement or litigation.

Focusing on infosec and infosec tech. Information security (the “confidentiality and integrity” principle) is just 1 of 7 principles and doesn’t even start to fulfil obligations around rights or fairness. While it is important, focusing on infosec to the exclusion of the other principles is just as likely to cause serious problems as forgetting it altogether.

Claiming that encryption is a mandatory requirement. Yes, it is mentioned specifically in a few places (Recital 83, Article 6, Article 32, Article 34) it is referenced as an example of a tool with which to mitigate risk. Whether you need it depends on the “scope, nature and context” of processing. Just having encryption will not make you “compliant” and not having encryption on ALL TEH THINGS will not mean that data is at risk of exposure.

Making it all about “compliance”. A finding of “compliance” in an audit is merely a snapshot of a point in time, assuming that the audit itself was sufficiently robust. A compliance-focused attitude often leads to ‘gaming the system’ (as anyone who has ever had an argument about scoping for PCI-DSS or ISO2700x can attest). Ticking boxes does not produce the intended outcome on its own -the paperwork must match reality. GDPR requires your reality to uphold principles, obligations, rights. If you’re not doing this in practice, no amount of audit reports, certificates or checklists will save you when it all goes wrong. Think “maturity” and “assurance”, “quality” and “effectiveness” rather than “compliance”

Insisting that only lawyers can be DPOs. There are some very good data protection lawyers out there in the wild, but an awfully large majority of lawyers who know almost nothing about privacy law. There are many experienced and competent data protection professionals who know privacy law inside-out but do not have a law degree. The only reason for insisting on having a lawyer as a Data Protection Officer or DP Lead is if the lawyer is *already* a DP specialist with business, communications & technical skills. The “lawyer” part is incidental.

Marketing GDPR stuff by breaching other laws (PECR) or in breach of DPA/GDPR itself (were you given a privacy notice about the use of your information for marketing purposes? Is it a fair use of your personal data?)

Calling it the “General Data Protection Regulations”. Seriously, people. It’s Regulation (EU) 2016/679, singular (even though there is a lot of it).

OK, those are the “approach with caution” signs. But how to find good advice on GDPR? Here’s some advice for spotting people who probably know what they’re talking about:

A competent privacy practitioner will tell you

There is no magic spell; time, effort, decision-making and resources will be required to adapt to GDPR requirements

There is no single tool, audit framework, self-assessment template, cut-n-paste policy or off-the-shelf training module that will make you “compliant”. You need to address systems, process AND culture at all layers and contexts.

Records management is just as significant as infosec (if not more so)

It’s not about paperwork – it’s about upholding fundamental human rights and freedoms (OK, that last one might be a step too far for many DP pro.s, but it is significant both to the intent and the implementation of GDPR.)

A few more handy tips for your Privacy Team lineup

Domain-specific knowledge is vital and valuable – but remember that specialists specialise, and so it is unlikely that someone who has only ever worked in one area of information governance (e.g. information security, records management) or context (HR, marketing, sales) will be able to address all of your GDPR needs.

The same consideration applies for lawyers – commercial, contract and general counsel-type lawyers are probably not as familiar with privacy law as with their own areas of expertise.

WARNING - this site sets cookies! Unfortunately, I am unable to disable some of the inbuilt tracking without killing the site content. tell me more

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.