Yeah, I doubted my sanity going at this one too, but here I am, because working out whether or not the GDPR would apply in different practical and geographical circumstances is proving harder than it really should…for everyone. This regulation has been my almost constant companion for a fair while and even I just met myself coming in the other direction when someone brought up a particularly gnarly edge case. It was like failing to recognise my own phone number when someone says it wrong (it’s NOT 077 – 8475 – 5433 it’s 07784 – 755 – 433*. You know who you are).
Data Subject Rights are not like a handbags. You don’t define GDPR jurisdiction by checking who’s got one and asking if they can take it on holiday
After ‘All you need is consent’ and ‘Something, something, FINES’, saying ‘GDPR just applies to EU citizens’ is arguably the quickest way to wind up the data protection crew. I can’t find the GIF I wanted of Roger Rabbit going off like a turbo charged train whistle, but you get the idea. First, like I do for most of these posts, let’s go back to the drawing board. Further down there are some basic questions to help you confirm whether or not the GDPR applies to your organisation, but this is where it all comes from: Recital 2 and Recital 4:
That latter one, in case you were wondering, is a great aide-mémoire ref those ‘rights and freedoms of natural persons’ we keep banging on about. And here’s what it specifically says about territorial scope:
But how (I mused), how can I create a nice neural niche for this? Which in turn prompted me to pick away at my own psychological blocks.
The first epiphany that struck: it’s not primarily about people. That sounds like an utter nonsense when talking about a regulation built around fundamental human rights, but there it is. If you try and attach unqualified GDPR rights and protections to a person like something they carry around, it goes wrong:
- Does it apply to me when I’m just resident in the EU, but not a citizen?
- Does it apply to me when I’m a non-EU citizen who’s just on holiday in the EU?
- Does it apply to me, as an EU citizen, if it’s an EU company processing my data while I’m living outside the EU?
- Does it apply to me, as an EU citizen, if it’s a non-EU company processing my personal data while I’m living outside the EU?
BUT, BUT, BUT What ifffff….as an EU citizen I go on holiday to a non-EU country, visit a local cafe, sign up to WiFi, and the cafe owner keeps my email. He then transfers it to a spreadsheet and uploads it to his Google Drive. I go home to the EU and the cafe spams me continuously with marketing mail. It turns out their Google Drive is in the Irish cloud, PLUS the owner of the cafe has a cousin with a part share in the cafe business who lives in France!
(Delivered with triumphant ‘Pick the bits out of that sucka!’ grin)
So, so, so messy and like so much else related to GDPR, not helped by the massively variable quality and accuracy of data protection advice available. But taking this back again to basics: if a person in, say, France (even one with a very valid EU passport) wanders off the grid minding their own business, jurisdictional applicability of data subject rights and protections just doesn’t come up. It only comes up when data is processed…and that is the point.
Applicability of GDPR rights and protections is driven, in practical reality, by the controller/processor, processing location, and purpose of that processing. With processing defined as (and this is critical because we all have pre-existing biases about what that word means):
…any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction
Or to break this down into logical steps:
ONE: Is our organisation formally established as a legal entity in any EU member state? Y/N
If YES, the GDPR applies to any personal data processing (keeping in mind the broad definition) by that legal entity, or that entity’s processors including B2B, B2C, and employee data processing. Go to ASSESS
IF NO, go to TWO
TWO: Does your organisation, or any organisation within your group, actively enable, invite, or initiate any interactions with organisations or individuals (including employees) based in Europe?** Y/N
THREE: Does your organisation, or any organisation within your group, have future plans to actively enable, invite, or initiate any interactions with organisations or individuals (including employees) based in Europe? Y/N
IF YES to either of the above questions, go to question FOUR
IF NO to both questions, go to question SIX
FOUR: Do/will any of those interactions involve personal data?
HINT: This doesn’t mean PII or PSI as defined in many US security standards and regulations, it means personal data as defined in the GDPR*** and the answer is almost certainly YES.
IF YES, got to question FIVE
IF NO, go to END
FIVE: Can you practically and sustainably segregate in-scope data and data processing from the data and data processing out of scope for GDPR?
IF YES, go to END
If NO, go to ASSESS
SIX: Do you process any data on behalf of another organisation (e.g. a client or a partner organisation), who actively enables, invites, or initiates any interactions with organisations or individuals (including employees) based in Europe? Y/N
If NO, go to END
IF YES, go to FOUR
ASSESS: Move on to assess the kind of personal data (does this involve any special category data****, child data, or convictions data?), detail of processing (locations, systems, third parties etc), how much of each type is there, and what are the risks to the rights and freedoms of potentially impacted data subjects either from a future data breach, or ongoing data processing (especially any profiling or automated decision making)?
You need to note the legal basis for the primary data processing purposes (e.g. setting up an account, or paying for goods and services) and any related secondary uses (analytics to enable targeted marketing). Use results to identify any control gaps, including requirements to honour data subject rights. Then plan, in consultation with other data controllers or processors involved, to put required processes and controls in place.
But how much control is enough when you’ve confirmed that data processing outside Europe is in GDPR scope and must be protected? The European law can’t impose control standards on non-member other countries, so what applies (reams have been written about ‘adequate’ control and what that means, this is just a look at which legal standards would apply)
US: Privacy Shield is not a direct equivalent to the GDPR, it is a level of control the European Commission and US Department of Commerce agreed to be adequate to safeguard privacy of data subjects when personal data is transferred between the EU and US. This is slightly meatier than the original Safe Harbor agreement, but be aware control existence and adequacy is still self-certified and facing harsh scrutiny in the wake of recent Facebook and Cambridge Analytica fun. The safest place to be for firms serious about data protection and seamless ongoing data exchange with Europe, is having a current assessment of control status, and a plan to close high risk gaps referring out to Privacy Shield/GDPR requirements and industry security standards (e.g. ISO or NIST). If you are on the EU side of such personal data transfers, I recommend robust contractual inclusions (e.g. Model Contract Clauses, plus more if the risks associated with specific processing justify it) and proportionate due diligence, to confirm existence and adequacy of controls.
The European Economic Area (EEA) and Beyond: Outside of the 28 EU member states, where the GDPR directly applies as law, there are European Free Trade Area countries (Norway, Iceland, and Lichtenstein) who need to create local laws to adopt the GDPR. Here’s a piece on GDPR in that EEA/EFTA context. Organisations can transfer personal data outside the European Economic Area, but that requires a European Commission adequacy agreement (existing agreements include those with Canada and New Zealand, and new agreements are under negotiation with Japan and South Korea). At the moment (pre BREXIT) Switzerland is the only country within Europe which needs an EU Commission approved adequacy agreement for data transfers. It also has it’s own version of Privacy Shield for transfers to and from the US. In the absence of a pre-approved adequacy ruling an organisation can transfer data oversees, but only if they meet certain conditions that are enforced by the local Supervisory Authorities and the Commission. There’s more on requirements for non-EEA data transfers, including referral out to relevant GDPR extracts here.
END: If it’s NO to all but question five, you may well be one of the organisations to whom the GDPR does not apply. But that’s not, contrary to the start of this paragraph, the end. You need to keep a handle on that. Implement a check that happens when the organisation changes through mergers or acquisitions, the supply chain changes, you explore more online interactions that might involve personal data, and/or you diversify into other activity.
**A test applied here might be the language and currency used in interactions. If you, or other organisations you process data on behalf of, offer things priced in Euros, or offer content in a European language other than American English, you will have trouble arguing there’s no intentional interaction with European organisations or data subjects.
*** Defining personal data, including examples of special category data:
‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
****The full list of special category data:
…personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation…
Yes, I know, you can’t even sneeze these days without something personal being snapped or grabbed by something in the IoT. I also know that rights don’t go away when you’re not using them (trust me, I haven’t gone totally mad), but I also know, even when GDPR scope is fairly well understood, that’s not really the question that everyone is asking. The real question on everyone’s lips, the one they tiptoe round, is:
Do we really have to protect all the people who trust us with their data?
Before I go any further I have to give grovelling thanks to the lovely Rowenna Fielding: grand data protection meister, Protecture privacy guru, GDPRubbish hashtag creator, and all round good egg. This post is only here because she talked me down from an imposter syndromish ledge, then helped me to unravel a specific use case (working through this stuff in isolation is never really advisable). I am and will forever be grateful.
She, like most folk I trust in the data protection, privacy, and infoSec worlds, reminds us that this is most about fairness, transparency, and respect. Reducing the chance of harm to data subjects caused by daily data processing, or data related breaches, while keeping the ethical bits of the information ecosystem afloat. That’s why the whole crew grind their teeth a little when the conversations start to sound too much like “What can we get away with?”
You can’t approach it that way. Just like defining personal data, it isn’t about a hard line. Too many organisations seem to want to play reverse data bingo e.g. If you avoid filling in these specific data fields for this specific website/database/form (completely ignoring all the other data stores you can easily cross-reference): BINGO, you don’t have to risk assess, limit data use, secure data and honour data subject rights.
Instead, just like risk assessing a real life blind date, it’s dependent on a range of individual-centric, environmental, and situational factors.
GDPR Applicability (and the definition of personal data) is CONTEXT DEPENDENT.
It is, with very rare exceptions, a case of ‘IT DEPENDS’. You need to ask a number of questions to understand the context, assess answers (including any risks raised), and then make a locally relevant judgement call. Then, depending on resulting scope, assess risks and put risk-relevant controls in place. Which very well might require – if there are no big risks to data subjects, and existing control is already good – absolutely no extra spending or work. Alternatively, if you are reasonably confident about your data processing being out of scope of the GDPR, you have to reassess in future if things change.
But, above all, DOCUMENT WORKINGS OUT AND GET CONCLUSIONS SIGNED OFF BY SOMEONE SENIOR WITH FORMAL ACCOUNTABILITY.
I promise to stop shouting now, but this is important. In our globally digitised, and deathly interconnected existence there’s no such thing as a simple data exchange, or on/off sharing switch, and you can’t put your fingers in your ears and chant ‘la, la, la’. That process is the basis for your entire defence if something does go wrong. It demonstrates you made a reasonable effort to do the right thing…versus an effort to find loopholes to avoid investment and liability.
There will be substantial goodwill and pragmatism shown by regulators if firms can demonstrate this kind of due diligence. They don’t have either the time or inclination to come after firms who are trying hard and largely succeeding to do the right thing by data subjects.
The sign off by the accountable senior body is also vital, both to secure sponsorship for further assessment, and to gain support for mitigation when the assessment says it’s needed. Plus, if the organisation gives into temptation to wing it or wish, the buck will stop in the correct place. In addition regulators will look kindly on organisations willing and able to amend practices if future case law or still TBC codes of conduct change interpretation of some of the broader principles and requirements in both the GDPR, ePrivacy Directive. Then there are individual member state derogations for some specifics that are still waiting to be passed into law (e.g. use of convictions data for car insurance). That’s why you have to check back over time.
Fortnite Data Royale?
So, if GDPR jurisdiction isn’t about handbags, is there another less dry way we could think about it? I know, how about comparing it to Fortnite Battle Royale?
Analogies are always at best inexact, at worst misleading, no analogy is complete blah, blah, blah…I know, but I have to get some enjoyment out of spending my spare time writing this stuff.
I’ve developed a small Fortnite habit (like millions of others), despite being shockingly bad at it. If you see someone panicking and running away shortly before getting killed, that’s probably me. I also spend too much time trying to hide. That works analogy-wise given the borderline tin foil hat wearing attitude I have to protecting my data.
Any interaction involving weapons and ammunition (information systems and data) that isn’t purely for personal squad purposes, is protected. It comes with data subject rights and control requirements where at least one initiation point or interaction target is within the circle (EU). There’s also your location and details about your activity and movements. That gets tacked onto the direct data interactions to influence the battle and the outcome.
Your squad, their squad, citizenship, residential status, doesn’t matter. Shooting enemies = direct commercial or government interaction with data subjects. My scattergun and almost entirely inaccurate aim works to illustrate how rarely data just ends up with those you aim it at.
Dropping resources for teamies = personal direct data interactions, occasionally hijacked by other teamies or outsiders (like the nasty [redacted], who boogie bombed us when I dropped a purple SCAR for my teamie, then shot me with it). Balloon drops = free-for-all social media data scraping / buying from data brokers. Llamas = millions of breached records exposed via insecure internal systems, or dumped in some wide open amazon bucket for anyone to find, use, and abuse. Resources dropped by the dead = publicly shared personal data on social media, search, and elsewhere.
The regulation also applies if someone lurks in the edge of the storm to pick you off, or someone within the circle does the same to someone in the edge of the storm. An interaction with someone within the circle, even just tracking them through a scope and taking notes, means rights and protections apply.
When do problems start? If you do some recon, browsing round minding your own business, it’s all seemingly good. That’s ignoring the folk tracking you but not attacking. If the trackers tell the snipers, or you try to snipe someone at the wrong time, it all kicks off…a bit like getting that insurance quote, welcoming each and every third party cookie, and missing the pre-ticked marketing box (e.g. not having a silencer), then RIP inbox as every vendor and their dog gets a copy of your email and starts peppering your inbox and every site you visit with more or less related marketing. Then, if the word gets passed round the rest of the squad, you can get all kinds of nastier surprise ambushes from above, from the flank, from behind (e.g. your future employer keeping an eye on interactions, Cambridge Analytica ‘influencing’ your position, data obtained under warrant by the government for immigration control or national security purposes).
Of course this ‘interesting’ analogy falls right over if you try to look at appropriate treatment of in scope data once it’s collected. No one weaponises data. No-one is trying to cause folk grievous or fatal harm when they encourage them or force them to exchange data, or obtain data behind the scenes…right?
So the jurisdiction of the regulation is personal data processing that happens within the EU member circle, even if it’s initiated from outside, and no matter where the individuals impacted are officially from. But, in this analogy, the circle never shrinks. Except it will when the UK leaves the EU. That’s unless the UK Information Commissioner and Department for Digital Culture, Media, and Sport manage to wangle some totally imaginary status as a non-member with full data protection recognition, as opposed to (the non-imaginary option), ending up as a third country forced to negotiate a hastily cobbled Privacy Shield-ish adequacy agreement, if the EU will even sign it off given the UK’s questionable and ever shrinking bulk profiling and domestic surveillance limitations…but I digress.
But what ifffff…..
This post was never going to be exhaustive and (as ever) it can’t be taken as legal advice (I still don’t have a law degree), but it is an honest and carefully reviewed attempt to come at this from a couple of different angles that might help it make some more consistent sense.
But what about those early examples? How do they stack up when viewed this way? Why don’t you cast an eye back over points and give that a try.
HINT: If you do, or ever want to do business with any individual or organisation based in Europe, or any other organisation that has to follow GDPR rules, you probably want to get cracking with a review of the personal data that currently or potentially, involves.
Where the relationship between data controllers, processors, and data subjects, or their relative locations change, there will need to be some best efforts assessment of scope. It’s not all going to be clear and simple because it’s a principle and risk based regulation and data use cases form an unimaginably complex web. That said, we owe it to ourselves to back out of GDPR rabbit holes (or ask someone to grab us by the heels and pull) because obsession with edge cases, or being blinded by the headlights of scale and complexity, can stop us from making a start.
That is the real crux. Just begin. Draw a reasonable line for both scope and control gaps, document your reasoning, and sort out the riskiest stuff. The riskiest stuff for the data subjects involved. The fact of that shift in risk focus, the assessment, and the work in progress is, in and of itself, a massive step forward.
*The number at the top is a made up mobile number (I hope), but mine isn’t tough to find.
More confused than when you started out? No two people are wired the same when it comes to learning so I’m trying to source some other guidance from folk I trust to give us facts not FUD. That’s easier said than done as I’ve mainly seen it discussed in twitter threads and LinkedIn comments, but I’ll keep looking. I’ll update this section with what I find, but please feel free to point me to content you recommend.