Press "Enter" to skip to content

Category: GDPR


“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

Abraham Maslow

An open letter to the information security profession

Dear infosec people,

You do a tough job in a complex, high-stress and fast-paced environment. I admire the cleverness of your technical capabilities and respect the challenges you face.


Seriously. You’re making the lives of privacy professionals really difficult, and that’s not going to lead to collegiate and constructive co-operation. You’re also occasionally making yourselves look like right knobbers to those of us who do know what we’re talking about in this area.

I’m generally not a fan of the ‘stay in your lane’ philosophy – breaking down silos and working together is an essential part of being effective these days. However, if you have not learned the rules of the other lanes, then carelessly blundering into them and screwing with the traffic flow is just as bad – if not worse – than hiding in a silo.

I absolutely welcome infosec people learning more about privacy/data protection – it’s the career path I took myself and have flourished upon. What sends me up the bloody wall though, is the Dunning-Kruger Effect that is evident when infosec people try to tackle data protection without having spent the time and effort to understand privacy law. Because they get it so very wrong and are uncritically parroted by other people who aren’t familiar with either professional knowledge domain, thereby spreading myths, tropes and general #GDPRubbish.

Infosec and privacy are not the same thing at all. There is overlap, but only for a small proportion of both. There is wide divergence and narrow convergence. Information security is about protecting corporate information and systems. Privacy is about protecting individuals and society. Data Protection is privacy applied to information about living people.

pie chart of data protection principles
DP principles

Data protection requires information security, but only as a small feature in a broad landscape of human right-based risks, controls, considerations and obligations. There are seven principles in data protection law, and only one of them is ‘process personal data securely’.

There are a whole bunch of individuals’ rights that have nothing to do with the security of their data. There are a pile of obligations that don’t relate to information security in any way. If you didn’t know that, or you don’t know what those principles, rights and obligations are, then please either go and learn, or belt up and refrain from undermining privacy by hijacking GDPR conversations and narrowing them to infosec-centricity.

It’s understandable that when your whole world is one topic, you’ll see everything else within those terms of reference. It’s natural to have a whole bunch of cognitive biases and assumptions. This isn’t a value judgement on your character, it’s just me pointing out an opportunity to integrate rather than colonise.

To assist you with this, here are some nuggets of data protection wisdom for you to take away and keep.

  • Privacy is not equivalent to confidentiality, it is the right to be free from unwarranted or arbitrary interference. This may involve a degree of confidentiality for information, but not necessarily. Data Protection is usually more concerned with why you’re doing stuff with/to people via their data than how secret the data is.
  • Privacy is not the binary opposite of ‘in public’. In fact, ‘in public’ is a spectrum anyway, but even if it were a single environment, it would still not be the opposite of privacy, because being amongst other people does not negate your human rights.
  • ‘Personal data’ is wider than ‘personally-identifiable information’. It’s heavily influenced by context and association, and the same piece of info may be ‘personal data’ in one scenario but not in another. There is no binary always/never threshold. Deal with it.
  • ISO27001 or any other infosec standard will NOT deliver GDPR compliance. Not even close. Not even 50%. Done properly, 2700x can help you adhere to the security and accountability principles, but does nothing to address fairness, rights, transparency, rights, lawfulness (etc)
  • No system, tool, document set or ‘solution’ can be ‘GDPR-compliant’ in itself. Only when used in accordance with all of the data protection principles, within an organisational culture of respect for privacy, in a privacy risk-managed way, can it play a small part in GDPR ‘compliance’. Which, by the way, requires the org to have integrated strong data protection risk management as business-as-usual into EVERY process, system, activity and decision.
  • The GDPR is principle-based law on purpose. It leaves room for innovation, creativity, risk appetite and context. If you’re looking for a prescriptive checklist of inflexible instructions for which no nuance is required, then stop trying to understand data protection and focus on PCI-DSS instead.
  • The only time ‘encryption’ is the ‘answer’ to data protection, is when the question is ‘what is one way to protect the confidentiality and integrity of data within a particular digital processing environment?’.
  • Security controls themselves must be assessed for privacy risk. User monitoring and profiling, authentication and verification for example, carry inherent privacy risks of their own and the security justification for using them may be negated by the privacy justification for NOT using them. This is not ‘privacy stopping you from doing your job’ but ‘the lesser of two evils’.

I believe that the disciplines of infosec and privacy can and should work collaboratively and constructively. But in order to do so, privacy pros need to be sterner about emphasising the ‘rights and freedoms’ aspect of data protection, and infosec pros need to accept that their security expertise does not equate to competence in the privacy domain.

Thank you for reading

Lots of luv and respect,


(This was originally going to be an exasperated sweary rant, but it turned out quite moderate and civil. Apologies to anyone I have disappointed as a result.)

More about the differences between privacy and security

Discover what the other 90% of the GDPR is all about

10 Legitimate Interests Lessons for Marketers

1. Just because you’re interested, doesn’t make it legitimate.

2. You can’t use LI to avoid getting consent when you suspect the answer will be “No”

3. Whether LI can be applied depends on your own assessment of what you’re doing, why and how – which you will be expected to justify and defend.

4. LI is not ‘unclear’ or ‘ambiguous’; it requires thinking to be done and a decision to be made.

5. Publish your Legitimate Interests Assessments (LIA) if you anticipate/plan to reject objections to processing.

6. If a law says you have to get consent for a processing activity, then forget about LI. You can’t use it. Move on.

7. LI is only a valid lawful basis for processing personal data if you’re adhering to all of the principles. It’s not a loophole around compliance.

8. If your LIA is post-hoc rationalisation of something you won’t consider ceasing to do even though you suspect it’s a bit dodgy; then you wasted your time. Just make sure you have funds set aside to deal with complaints, regulatory action and reputation damage when you get found out.

9. The ICO is not responsible for your continuing professional development

10. No-one else can do your thinking for you

Bad Privacy Notice Bingo!

Snark attack!

Having spent many, many hours reviewing privacy notices lately – both for the day job and for my own personal edification – I’m discouraged to report that most of them have a long way to go before they meet the requirements of Articles 13 and 14 of the GDPR, let alone provide an engaging and informative privacy experience for the data subject.

Because I am a nerd who cares passionately about making data protection effective and accessible, but also a sarcastic know-it-all smartarse, I created this bingo scorecard to illustrate the problems with many privacy notices (or “policies” as some degenerates call them) and splattered it across social media. Hours of fun.

Whose Decision is it Anyway?

Controller/Processor determinations

(a.k.a how a data protection anorak spends their leisure time)

Update: Sorry that the tool is not currently working – My supposedly ‘unlimited’ free Zingtree account has expired, and they want £984 a year for me to renew it, which I can’t afford. Currently looking for alternatives – if you know of one, hit me up! I’ll post a downloadable text version of the tool very soon.

Following a lot of pre-GDPR kerfuffle online about Data Controller/Data Processor relationships (and the varying degrees to which these are direly misunderstood), I spent a geeky Sunday night putting together a decision tree tool which should – hopefully – help people who are getting confused/panicked/deeply weary of the search for answers.

It’s not intended to be legal advice, it’s not formal advice from me as a consultant and it’s not guaranteed to be absolutely 100% perfect for every possible scenario. It’s designed for the low-hanging fruit, the straightforward relationships (like standard commercial supply chain) rather than the multi-dimensional nightmare data sharing behemoths one tends to find in the public sector.

Anyway, here it is. Enjoy. If you like it, please tell others where to find it. If you have constructive criticism (that’s not “oh you missed out this incredibly niche complex scenario that would only ever happen every 100 years”) please tell me.

The Tool


Here are also some useful links:

Who’s in Control?

I’m a muse|amused

Inspired by my #GDPRubbish rantings, the ever-droll Javvad Malik has put together a handy video guide for all those newly-minted “GDPR consultants” that have been mushrooming up; on how to make as much from this shiny new market as possible…..

Cookies are disabled (stuff might not work)
If this is a problem for you, please click “Reluctantly Accept” in the banner.

(NB: this is parody and satire; anyone who actually does the things described herein has no business working in data protection at all and should GTFO ASAP)

Consent or not consent?

Update: I’ve exported the tool as a PDF so you can see the questions and answers. It’s no longer interactive, but it may still be helpful.

Consent decision tree

Update: Sorry that the tool is not currently working – My supposedly ‘unlimited’ free Zingtree account has expired, and they want £984 a year for me to renew it, which I can’t afford. Currently looking for alternatives – if you know of one, hit me up! I’ll post a downloadable text version of the tool very soon.

Following on from some of the ranting I’ve been doing about the current unhealthy obsession with consent for processing, here’s a funky tool that I have created for determining whether consent is the appropriate legal basis for processing under GDPR.

At the moment, it only covers Article 6 but I’m working on another one that addresses special categories of personal data as well.

Please let me know what you think about this tool in the comments section!

Verelox, insider threat and GDPR implications

If you haven’t heard about Verelox, they are a Dutch cloud hosting provider who’ve recently been wiped off the internet (along with all of the customers hosting with them) by what is reported to be an attack by an ex-sysadmin, who has wiped customer data and servers.

I’ve been seeing tweets and discussions on tech and infosec forums, some of which have queried whether this circumstance would be a breach under GDPR for which regulatory penalties could be enforced. The answer to whether this incident represents a failure of Verelox to meet the requirements of GDPR is going to depend on many details which are not currently available, however as a former infosec professional now turned to privacy; I’d be inclined if asked, to give the standard Data Protection Officer answer: “It depends”. Because it does.

What the GDPR does – and doesn’t – say about consent

Meme courtesy of Jenny Lynn (@JennyL_RM)

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.



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.

Hello. I use privacy-friendly analytics (Matomo) to track visits to my website. Can I please set a cookie to enable this tracking? I’m afraid that various plugins and content I have on the site here also use cookies, so a ‘yes’ to cookies is a ‘yes’ to those too. Please have a look at my Privacy Info page for more info about these, and visit my advice page for tips on protecting your privacy online