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

PIN on Mobile

PCI: Software-Based PIN Entry on COTS (a.k.a. PIN-on-Mobile)

Almost four YEARS ago I wrote Software PIN, the Rosetta Stone of Future Payments, then just over a year later I wrote; Mobile Authentication: Exceeding Card Present Security?

Just this month the SSC finally came out with their Software-Based PIN Entry on COTS Security Requirements v1.0.

[Ed. While I don’t have to wonder why PIN was my primary focus, I can see how pointless it was …almost. It just makes the delay on this standard that much more inexcusable.]

On with the story… Software PIN is more commonly referred to as PIN-on-Mobile (or the catchier PIN-on-Glass), and is the ‘game-changing’ technology that will; “enable merchants to accept PIN-based payments with the PIN entered on a commercial off-the-shelf device, such as a consumer-grade mobile phone or tablet.”

What has taken them so long to make what – from my jaded perspective – is the only move that will delay their inevitable demise? It’s not like there was some miraculous innovation in mobile or encryption technology in the last couple of years! Every requirement in the standard was available/achievable long before I even wrote my blogs. As were viable solutions for that matter.

I suspect there’s lots of reasons of why they were so slow, but chief amongst these has to be their complete inability to adapt to the fast-paced innovation rampant in the FinTech industry. Especially given their hopelessly antiquated technology. It’s only their global adoption and sheer ubiquity that keeps them where they are. I blame the banks too, change for them means acceptance of liability.

Come to think of it, what an amazing coincidence that PSD2 – the biggest nail in the payment card’s coffin since …well ever, came out this month as well. Weird huh?

As far as I am concerned, PIN-on-Mobile was the card brand’s last hold-out, now they’re done. Hopefully between the XYZ-Pays (ApplePay, SamsungPay etc.) and now the entry of cardholder PIN on [almost] any CoTS device, big merchants / retail associations will finally have the balls to stand up for themselves.

How many millions have they spent in the US on EMV terminals just to find out a few years later that it was not only entirely unnecessary, but they’re now tied into an investment that will leave them lagging behind their competition who were slower of the EMV block?

I know that’s harsh, and we really have no right to judge. Have any of the following questions ever occurred to you?:

  1. If I can use my phone to pay for something, why do I have to tie that payment to a branded card?;
  2. With all of the security requirements required for the entry of a software PIN, why the Hell do I still have to use one? In other words, if it’s that bloody difficult to secure it, why not use something else?; and
  3. Isn’t there a better way!?

If you’re like the majority of the population, these questions are more like:

  1. Why doesn’t MY bank support this?! (looking at YOU Barclay Business!), or more commonly; why would I use this service when I have a piece of plastic?;
  2. What’s wrong with PIN?; and
  3. [nothing]

The fact is that the lion’s share of the cashless transactions globally are performed by those who have never known a time before payment cards. We simply can’t imagine anything else and we don’t even notice their inconvenience. We also don’t see the costs imposed by the middlemen.

But let me ask you this; Would you ever go back to using a feature phone? I’ll [almost] guarantee that you had no idea what features you wanted in a phone until you used a smartphone for the first time. And now you can’t live without it. Hell, most of us can’t even put the damned things down!

The same thing WILL happen to payments, but not until consumer indifference is overcome by something shiny and new.

Frankly this blog is boring even to me, and I really have nothing more to say about payment innovation that I have not already said a hundred times. But I simply can’t let anything so patently meaningless as PIN on Mobile to go unanswered.

Innovation my arse.

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


If AI is the Answer, You’ve Asked ALL the Wrong Questions

For those reading this who are cybersecurity professionals (and who else would read this crap?); In your entire career, have you ever come out of the back-end of a risk assessment and said; “We need Artificial Intelligence.”


I seriously doubt it, unless you happen to sell artificial intelligence, or more likely, you’re trying to pass off your product as artificial intelligence.

But let me just clarify before I continue whining; AI is exciting as Hell, and I cannot WAIT to see what comes next. I am not in the ‘Skynet’ camp, and I even disagree with people a thousand times smarter than me. No, not my wife (this time), but the likes of Stephen Hawking, Bill Gates and Elon Musk, all of whom have issued their own warnings/predictions on the subject. I think AI is going to make our lives better in almost every way. Almost.

But not in cybersecurity at the organisation level. Not yet. Most businesses simply don’t have anywhere near the foundations in place to implement it appropriately, let alone effectively. Implementing any technology on top of broken processes and/or an indifferent security culture may only serve to make things worse.

I can see it in working the threat intelligence arena, where a behemoth like Alphabet – and their mind-boggling access to almost everything -, can fund something like Chronicle. But this is just one small part of a security program, feeding into the ages-old clichés of ‘defence in depth’ or ‘layered security’. AI is certainly not the panacea those with a vested interest would have you believe. Basically, if you don’t have the same access and deep pockets as Alphabet, you should be probably be focusing on the hundreds of other things you should have done long before now.

And even if there was an AI ‘appliance’ that you could just plug-and-play on your network, do you honestly think the bad guys won’t work out how to circumvent it with some AI tricks of their own? Regardless of the technology, the good guys always have to play by the rules and the bad guys will always do whatever it takes. This is not a fight we are EVER going to win, so stop trying. The only thing we can do, and the sole premise of my career, is to minimise the damage. Security folks are the definitive guys bringing a knife to a gunfight. But we will fight.

This is neither cynical, nor a cop-out, it’s reality, and spending money on a technology you’ll never understand, or maintain yourself, is not going to change that.

But none of this will stop organisations spending money on nonsense. On the one side you have product vendors, technology-centric consultants, hype in the press, and indifferent CEOs. On the other side, you have the ages-old security basics and a very limited number of stubborn practitioners. It’s not really that surprising that acronyms and the latest shiny-things get all the attention, just unfortunate.

In fact, it’s no different from ‘get rich quick schemes’ or ‘diet pills’, there are very few shortcuts to wealth and none to losing weight. Both involve getting off your lazy arse and doing something. So does security.

But most of all I simply can’t abide vendors who try to fit every single problem into the one thing they can do. From operationalising the whole of GDPR with ISO 27001, to solving every limitation of digital payments with biometrics, the attraction of the silver-bullet is just too much for some to resist. AI and machine learning are the latest purveyors in a long line of empty promises.

Perhaps I’m no better, all I can do is help you implement the basics. But I’ll guarantee what I’m selling is a damned sight cheaper and significantly more permanent! 🙂

[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).

GDPR in Plain English

Free Resource: The GDPR in Plain English

So here we are, it’s 2018 and the GDPR will be enforced THIS year. I suspect that both marketing budgets and the corresponding hype will now grow exponentially until everyone is sick to death of it. I know I am, and judging by the majority of questions on LinkedIn, I’m one of the seemingly few who have actually read the damned thing. Really read it.

And that’s the point of this blog. As a privacy novice I have made a significant effort to truly understand the GDPR. I have, quite literally, spent months poring over it in an effort to fully grasp its intent in order to provide appropriate guidance to my clients, and to more junior cybersecurity professionals. But just as importantly, I read it because the GDPR is about MY personal data, MY privacy, MY fundamental human right.

More often than not my guidance to others has been; “Talk to a privacy expert/lawyer.”, but I am now in a position to provide something a little more useful. In partnership with Angela Boswell (Lawyer / DPO / GDPR implementer), we have drafted a ‘GDPR in Plain English‘ resource designed to allow anyone to get a significantly better understanding of its meaning without having to either be a lawyer, or go through months of soul-destroying tedium.

The resource consists of 3 spreadsheet tabs:


  1. ‘Recitals’ – All 173 Recitals with 3 additional columns:o
    1. Recital Title‘ – Very brief summary of the Recital’s main theme, similar to those provided for the Articles;
    2. Plain English‘ – Angela’s and my attempt at turning legal-ese into plain language; and
    3. References‘ – Links to every Article or external document for more convenient access to relevant context
  2. ‘Articles (Reference)’ – The Articles contain a significant number of references to other Articles, Recitals, and external documentation. They are all provided here for convenience. ‘In-cell’ comments provide titles and, where appropriate, relevant content
  3. ‘Articles (Operations)’ – Work in progress, but we intend to provide implementation and operationalisation guidance as and when available. This will include the excellent guidance so far produced by the likes of the UK’s ICO, the WP29, and numerous law firms happy to share their knowledge for free (most notably Bird & Bird from whom I have plagiarised shamelessly).
    We have broken this tab into 7 distinct columns.

    1. Regulation‘ – A significant portion of the Articles relate to the ‘administration’ of the regulation itself and require no specific action on behalf of the controllers or processors. These cannot be ignored, but you should probably spend more time on the other stuff;
    2. Principles‘ – The foundational principles of the GDPR and should be fully understood by everyone. Again, no specific action is required other than to read and understand them, because these underpin everything that the GDPR is about;
    3. Process‘ – These are the things that will eventually need to be operationalised in some fashion. Documentation, record keeping, technology, security etc. all fall within this category;
    4. Legal/Compliance‘ – Things that will require legal expertise to handle. While this does not have to be a privacy lawyer, or any lawyer for that matter, if these things are not handled by subject matter experts you’re leaving yourself wide open;
      …and eventually;
    5. People Requirements‘ – The implementation and ongoing maintenance of GDPR is the definitive team effort. This is not an IT problem, or a legal one, it is a business challenge. This section will provide guidance, examples/samples, links and hopefully, in time, some real-world input from generous contributors;
    6. Process Requirements‘ – From policies and procedures, to privacy notices, to contractual language, at some point you are going to have to DO something. This section will provide guidance and sanitised samples of what others have done to meet a requirement; and
    7. Technology Requirements‘ – Technology can never fix a broken process, it can only make a good process better. This is as true for security as it is for the GDPR. Technology will be required to support/enable your ongoing operational efforts, and this section will provide guidance on technologies to consider, and to avoid. We will only care about function, not brand.

Hopefully this resource will be of some benefit to you, and you’re welcome to do with it as you wish. We only ask 2 things:

  1. Credit both Angela and myself if you do end up using this for commercial benefit; and
  2. Add to it! This resource has been the work of only 2 people who have nowhere near the experience or skill-sets to make it universally relevant. There will be translation gaps, naive assumptions, and things that we didn’t know we didn’t know. Help us!

Finally, I would just like to reiterate that the GDPR is not just a burden placed on businesses, it is a fundamental shift in how YOUR personal data is used. This is a significant enhancement to one of your fundamental human rights. Everyone should read this regulation, so please do your part to get this out to every ‘data subject’ and ‘natural person’ who needs it.

Download the Excel spreadsheet here: GDPR in Plain English

Please provide any feedback to

We thank you in advance.

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