If you’re fairly new to this ‘privacy stuff’, you might be wondering why I used the phrase ‘data privacy’, not ‘data protection’. Well, unlike the security industry where we can’t even agree on when to use ‘cybersecurity’, ‘data security’, or ‘information security’, the privacy world has its act together. Hell, security folk can’t even agree on the spelling OF cybersecurity/cyber security!

But for the purposes of this blog, and the Part 2 guest blog to follow, it’s important that you accept my definitions at least, whether you agree with the names or not. It’s the points I’m trying to make that matter, not the nomenclature.

‘Security’ Definitions:

I am assuming it’s universally accepted that ‘information’ is simply ‘data in context’. So ‘data security’ and ‘information security’ are pretty much the same thing, they’re just at different stages of a data life cycle. e.g. If I steal a whole bunch of individual files with no indication of their content I have stolen data, but if I steal the plans for a revolutionary widget, I am stealing information. ‘Data’ and ‘information’ are used pretty much interchangeably from a security persons perspective – as will I for the reminder of the blog – because it’s not security folks who make the decisions on the data/information’s use, the business does.

I will therefore settle on the following names/definitions:

• Security – Every aspect of security, from physical (e.g. buildings, laptops, personal safety, etc.) to logical (e.g. cybersecurity);
• Data Security – Is the protection of data or information assets in any format; i.e. physical (e.g. paper) and electronic (e.g. on a computer);
• Cybersecurity – Is the protection of any electronic form of data or information, regardless of data life cycle context;

In this respect, I have always seen cybersecurity (joined up because Gibson coined it ‘cyberspace’, not ‘cyber space’) as a subset of data security, but apparently ‘cyber’ is just way cooler to say despite it’s more limited applicability. The security industry, it seems, is obsessed with the need to introduce new buzz-phrases to replace things that weren’t actually broken.

None of this means anything to a privacy person who only cares about ‘data privacy’ and ‘data protection’, which are not the same thing. The privacy person cares about how the data/information is used (privacy), how personal data is protected is a subset of that goal.

‘Privacy’ Definitions:

Privacy is a state, not a function; i.e. you either have it or you don’t. Loss of personal data does not, in and of itself, equate to a loss of privacy, just as you can lose privacy where no data is involved (e.g. peeping toms). In data terms, privacy is lost if, and only if, the data is used in a manner that actually violates the data subject’s fundamental human right to privacy (first enshrined in UDHR Art. 12). The protection of this right in the EU is now significantly matured in the GDPR, and that’s really the whole point of this two-part blog series; how is the use/misuse/loss/theft of personal data driving two disciplines, previously perceived as quite separate, together?

But back to the definitions:

• Privacy – “a state in which one is not observed or disturbed by other people.” the ‘state’ of privacy cares nothing for how you have it, just that you do have it in-line with the right to it;
• Data Privacy – not surprisingly this is also known as ‘information privacy’, and is concerned with the proper handling of data (e.g. collection, consent, use, transfer to third parties etc.), particularly under regulatory obligation (like the GDPR);
• Data Protection – is concerned with the unauthorised use, corruption, loss, availability of the personal data.

All of the above definitions, security and privacy, can be summarised thus:

If Privacy is a state, then so is being ‘Secure’, and the overlap between the two is likely far more significant than the above diagram might suggest. Especially in the 21st century where privacy has become little more than a currency, and security no more than an afterthought to convenience or for a few ‘likes’ on social media.

I have spent 20 years in the IT / IT Security industry, and it was not until I read the draft GDPR back in early 2016 did I see it as something that impacted me. I had my own ideas of privacy, none of which appropriately factored in privacy’s growing interdependencies with my chosen career path. It took another year or so for me to realise that unless I knew more about how privacy would impact security that I would be severely limited in the help I could provide my clients. Most of whom, quite frankly, knew little about either. Why would they, that’s why they hired me in the first place?

The overlap between security and privacy has been increasing rapidly in the 3 years that I’ve been paying attention, and we’re getting to the point that privacy is no longer a ‘siloed’ aspect of security professional’s body of knowledge, it’s intrinsic to the industry itself. As a security professional you no longer have a choice, you either learn enough about privacy to talk somewhat intelligently, or your security-relevant guidance cannot be seen in an ‘appropriate business context’.

Having seen the writing on the wall, I did what most people do when they start to feel left behind; I jumped on the study / specialist certification bandwagon. I read as much as I could from the better law firms, absorbed most of what the ICO posted, subscribed to the more objective newsletters, and wrote blog after blog hoping the real experts would pay attention and set me straight.

I then got myself ‘acronymed up’ by taking IAPP’s CIPT, CIPM, and CIPP/E, all to do just one thing; to gain enough knowledge that I can translate what the real privacy experts say into language the IT/IS experts can understand. And vice versa. I will never truly understand privacy, not from a purely legal perspective, I have always been, and will always be a security person. But someone has to take what the privacy folks say in legal-ese and translate that into geek-speak, or every decision stays on the paper on which it was written.

So here we, 1,000 words into my blog and I’m finally getting to the point; security people are perfectly placed to be the translators if, and only if, they make the necessary effort to do so.

If you assume that a GDPR compliance project looks something like this (much simplified):

• Step 1: IT folks discover all data assets;
• Step 2: IT / IS folks help the business-side map the data into process flows, including 3rd party dependencies;
• Step 3: Privacy experts make determination of lawful basis for processing for all process flows, and dictate the changes that have to be made to that processing;
• Step 4: IT / IS folks have to implement the “technical and organisational measures” that fulfil those required changes;
• Step 5: IT / IS folks have to detail the final work product back to the privacy expert for signoff and onward reporting.

But who sits in the middle? Who can:

• tell the IT folks what to look for in the first place, and how to report the findings?;
• guide the business side into the right way to report the resulting processes?;
• present the business process mappings to the privacy experts in their language?;
• translate the privacy expert’s guidance into action items an IT person can follow?;
• report back to the privacy experts in a language that can be readily incorporated into contracts, records of processing, policies, notices, and so on?

The problem with the security person trying to do all of this themselves, and the reason why it’s a 2-part blog, is that VERY few security folks are able to go the whole way by themselves. The ‘legal’ side absolutely must make an equivalent push in the other direction, as without a similar level of effort from both sides the two simply will not meet in the middle.

But what options are there other than to study as I did? A few universities are offering courses that attempt to tie these disciplines together, but we are wayyyyy behind the curve on this one. It is up to each security professional to decide what’s best for them and get themselves back to ‘school’. That or be left behind.

In Part 2, I will present a guest blog from the ‘other side’; from a lawyer, contracts guru, DPO, and all-round expert in the field. Not in theory, in practice.