DPO

Should a CSO/CISO Ever Be a DPO?

I finally figured out why this blog was so damned difficult [for me] to write; I’ve been thinking all wrong about what exactly a DPO actually is. Which is odd, because I had the exact same challenge when writing about CSO/CISOs, and I really should have learned from my mistake.

When you think about a CISO (assume this also means CSO), or a DPO, you instantly picture a person. Maybe your organisation already has one so their face springs to mind, or if not, you have a indistinct and faceless image of someone in a suit. The fact is, neither the CISO nor the DPO are people, they are functions. Multiple functions in fact.

And not only that, they involve multiple disciplines, skill-sets, even personal preferences. Most importantly, neither the CISO nor the DPO functions [performed correctly] are ever a single person. A DPO would, quite literally, have to be an expert in privacy law (both EU and national), contracts, risk management, policy development, distribution and audit, and understand all personal data flows throughout the business.

You therefore need to break the function down before you can move forward. For example; I broke the CISO function down into 3 distinct skill-sets/phases:

  1. The Planner: The p-CISO comes in at the beginning of an engagement, before an organisation even knows what it actually needs. Their job is to design a security program that does the only thing it’s supposed to; support / enable the company’s business goals;
    o
  2. The Executor: e-CISOs get things done. They take the hand-off from the p-CISO and put the agreed plan into action; and
    o
  3. The Optimiser: o-CISOs are in it for the long-haul. These are the folks that take the still raw security program, and make sure it get fully instilled in the company culture and business as usual processes.

I have never, I mean NEVER, met any one person who is fully competent at, or even wants to perform all of these things. For example, I thrive as a planner, would fail miserably at execution, and could not be less suited for optimising. In fact, phase 1. and 2. are likely short to mid-term specialist external consultants, and only 3. is a full-time employee or ‘indefinitely outsourced’ service.

The DPO will be no different, but first you have to address exactly what they are required to do (per Article 39):o

  1. to inform and advise the controller or the processor and the employees who carry out processing of their obligations pursuant to this Regulation and to other Union or Member State data protection provisions – so any incumbent not only has to have significant knowledge of their organisation’s business processes, but they have to have sufficient understanding of both the GDPR and any national laws relevant to member states under his/her remit;
    o
  2. to monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data, including the assignment of responsibilities, awareness-raising and training of staff involved in processing operations, and the related audits – so the incumbent not only has potentially significant additional tasking in staying up to speed with relevant EU and national law(s), but they have to able to translate that into appropriate policy, training material, and audit procedures;
    o
  3. to provide advice where requested as regards the data protection impact assessment and monitor its performance pursuant to Article 35 – so the incumbent has to be able to balance the risk to data subject rights to the value of the processing to the business, and justify any decision to proceed to a supervisory authority. Or NOT to proceed to their CEO/Board!;
    o
  4. to cooperate with the supervisory authority – the incumbent must sound credible, they must at least be able to talk-the-talk;
    o
  5. to act as the contact point for the supervisory authority on issues relating to processing, including the prior consultation referred to in Article 36, and to consult, where appropriate, with regard to any other matter – again, the incumbent had better know his/her stuff. If the supervisory authority thinks the DPO is nothing but an empty suit this will reflect very poorly on the organisation concerned

Now ask yourself; Does any one person in your organisation have what it takes to manage the above? I think it unlikely.

So that should leave you breaking the development of the DPO role into a similar 3-phase process, similar to the CISO’s above. It would look something like this:

  1. The SME: The sme-DPO comes in at the beginning of an engagement to design the data protection compliance program. S/he has enough knowledge (and access to other more task-specific SMEs) to ensure that the program has the requisite leadership commitment, that all personal data will be discovered and mapped to business processes, that all policy and contract language will be in place and so on;
    o
  2. The Program Manager: the pm-DPO should also be very knowledgable in data protection, but their role is to take take the sme-DPO’s plan and run all work streams to their appropriate conclusions. To all intents and purposes, this organisation is now compliant. They can perform GDPR Article 30 reporting, they can answer any data subject access request, their breach notification is documented and tested, their 3rd party and vendor contract addendums / DPAs are in place and so on; and
    o
  3. The Maintenance DPO: m-DPOs are now the ‘named-face’ of data protection in an organisation, but like a governance function, it’s more of a organisational role. They are responsible for combining the right departmental expertise and external SME guidance into a coherent and sustainable program.

If you assume that the CISO will only be one of many SMEs in phases 1. and 2., what makes them the right person to handle 3.? Actually, if the CISO has be hired correctly, there is quite a lot in their favour. They:

  1. should already have dotted-line reporting, and direct access to, the Board – Both of which are prerequisites for a DPO, just as they are for internal audit;
  2. should already have a seat at whatever passes for Corporate Governance – where the responsibility for data protection and data security rightly sits;
  3. will, as an intrinsic part of their job, have an almost unparalleled understanding of where the personal data is, and what’s done with it;
  4. will, again as an intrinsic part of their job, have an almost unparalleled understanding of who does what in an organisation;
  5. should certainly be able to handle all aspects of “technical and operational security measures”, should a supervisory authority ever ask;
  6. should already be very familiar with the development, distribution, and ongoing maintenance of a training program;
  7. must understand the absolutely necessity for, and the enforcement of, good policies, standards and procedures; and
  8. must understand the maintenance of a compliance program from an internal policy, and an external regulatory perspective

And the list goes on. In fact, the only real questions to ask are:

  1. Does the CSO/CISO have the necessary and business-appropriateexpert knowledge of data protection law and practices (Article 37(5))” to do the job?; and
    o
  2. Do they want it?

For the longest time my gut feeling was that the m-DPO should be more of a legal function (which it is), but in-house legal expertise is actually more rare than in-house security expertise. So now, in the absence of legal, I find myself unopposed to security filling the m-DPO seats, but only if both the candidate, and the position itself meet ALL of the above criteria.

About the only thing I would warn against is taking any stock in “certified DPO” courses, they are about as useless and inappropriate as “certified CISO” courses. You don’t learn these things from a course, you learn them from doing the bloody JOB.

And finally, would I ever recommend a ‘virtual-DPO’ or other ‘indefinitely outsourced’ service to handle the m-DPO function? That depends, can they meet all of the above criteria without a seat at the governance table? For a small monthly retainer? Over the phone?

Dunno, your call, but now you know the right questions to ask.

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

 

[Ed. I wanted to thank a ‘colleague from Kosovo’ for prompting this blog :)]

Information Security vs Privacy

Information Security vs Privacy, are the Lines Blurring?

My original title was “Data Security vs Data Protection[…]”, but an unfortunate number of people see these as pretty much the same thing, even interchangeable. Then I chose Cybersecurity instead of Data Security but that doesn’t cover all forms/formats of personal data, so I finally had to settle on Information Security.

As for Data Protection, it’s not, in and of itself Privacy, and so on…

But you see the problem already? If we can’t even agree on common terminology, how are we expected to ask the right people the right questions in order to solve our problems? But I digress…

For the purposes of this blog I have chosen the following definitions of ‘Information Security’ and ‘Privacy’:

  • Information Security – “…is the practice of preventing unauthorised access, use, disclosure, disruption, modification, inspection, recording or destruction of information.”; and
    o
  • Privacy – “…is the ability of an individual or group to seclude themselves, or information about themselves, and thereby express themselves selectively.”

It should be immediately obvious that these are NOT the same thing. Significant overlap, yes, but as always, security is just an enabler. Security does not dictate the goals of a business, it enables them; security does not give you privacy, it enables you to have it. A personal trainer does not make you healthy, s/he provides guidance in ONE aspect of your health goals. You still have to eat better, drink less, stop smoking, reduce stress and so on.

But now there seems to be an expectation that security people should also be privacy experts (I’m not saying they can’t be, but I actually don’t know any). Because GDPR is a big deal and ‘data protection’ is seen as the same as ‘data security’, everyone is looking to security people for guidance. Would you hire a fat personal trainer?

Take me for example: I have spent a large chunk of the last 2 years learning more about privacy (and GDPR in particular), I still consider myself 99.9% a security guy. I have even written fairly extensively on both privacy (personal opinion) and GDPR (hopefully accurately), but once again, neither of these things is what I DO. Privacy is not a core competence of security (just look at the CISSP CBKs).

But, and to the point of this blog, can a ‘security guy’ keep doing just security in the brave new world post-May 25th? The short answer is of course yes, if that’s all they want, but are they doing their careers any favours? And what about their clients? Can a security expert without at least a foundation in privacy really perform their function appropriately? For security to enable anything, they need context, privacy is now a major factor of that context for any business.

In other words, has privacy now become so important, that any field with a significant impact on it must revise its training syllabus? And given that information security has such a significant overlap with privacy, are security people best placed to take on a bigger role in providing privacy guidance?

The answer, as in everything else, is; that depends. A business has to be able to find the appropriate help, and the ‘expert’ has to have the appropriate skillset. There is no standard here, and only the people [on both sides of the equation] who educate themselves should be making any decisions. Should.

In reality, most organisations don’t even have in-house security expertise, let alone privacy expertise, so where is this guidance supposed to come from? I now think that security folks are very well placed to begin taking on a larger privacy mantle. I even believe that security folks who don’t get a foundation in privacy are severely limiting their careers. Could you imagine hiring a CISO who hasn’t even read the GDPR?

Information Security and Privacy will never merge completely, they are just too big and too different, but the lines are indeed blurring.

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

GDPR Muppets

GDPR: Now We Know Who the Muppets Are

Well, here we are, close of business May 25th, and oh look!, the sun is still shining, the world is still spinning, and no one [decent] went out of business.

What we do have however is an indication of who the world’s biggest muppets are. For example:

…and:

…and the list goes on and on.

As if the barrage of ridiculous and utterly meaningless emails over the last few months wasn’t enough, the spectacular ignorance shown by these and many other organisations defies belief. The only good thing I can say about these weapons grade plums is that they are actually taking GDPR seriously. They DID something. The fact that they are needlessly damaging their reputations is apparently beside the point.

Continue reading

GDPR Step-by-Step - Operationalise

GDPR Compliance Step-by-Step: Part 6 – Operationalise

This is the final part in my GDPR Step-by-Step series, and one that, in my cynicism, I see very few organisations even trying to attempt. I have lost count of the number of companies with whom I have tried to implement a continuous compliance program, only to have them stop once they received their initial ‘certification’. In this respect, GDPR will be no different from something like PCI.

But for GDPR, if you don’t  build the necessary knowledge / processes into everyone’s day jobs, your compliance program will falter. While data protection and privacy are everyone’s responsibility, they cannot, and will not be at the forefront of everyone’s mind as they work through an ordinary day.

There are some who are convinced that you can ‘operationalise’ the entirety of GDPR with ISO 27001. This is, of course, nonsense. However, the concept is perfectly valid in that ISO 27001’s goals are to:

  • Systematically examine the organisation’s information security risks, taking account of the threats, vulnerabilities, and impacts;
  • Design and implement a comprehensive suite of information security controls and/or other forms of risk treatment;
  • Adopt an overarching management process to ensure that the information security controls continue to meet the organisation’s information security needs

Continue reading

GDPR Step-by-Step - Documentation

GDPR Compliance Step-by-Step: Part 5 – Documentation

As a consultant there’s nothing I like more sitting around a table with a bunch of really smart people simplifying complex issues and guiding them towards an appropriate and effective security program.

Then someone has to go spoil the ride by saying; “That sounds great David, when can we expect the report?” [sob] 

‘Documentation’ really should be a 4-letter word.

But with the GDPR, you have no choice. Documentation is your evidence of compliance. Even if you’re lucky enough not to have to maintain ‘records of processing activities’ (see Article 30(5)), you still have to document everything else, even WHY you don’t think you have to maintain records.

The word “appropriate” appears 115 times in the GDPR final text, and “reasonable” a further 23 times. That’s 138 times in one regulation that YOU have to make a determination of whether or not what you’re doing meets the grade. Lawyers can turn to precedent to agree what’s reasonable, where can WE turn to agree not only what’s appropriate, but to justify it?!

Here’s where the concept of Risk Management comes in, because like it or not, you WILL be taking a risk-based approach to GDPR compliance. And the one thing that risk management demands; documentation.

Note: The following is at a very high level, not comprehensive, and not representative of every organisation’s needs.

First, you will need policies. Not just the information security policies that I usually focus on, but policies that cover all relevant aspects of data protection. You will need policies on things like:

  • General Data Protection / Privacy
  • Employee Privacy
  • Third Party / Third Country Transfers
  • Data Subject Rights
  • Engagement of Processors
  • …and so on.

There are [of course] a bunch of vendors out there promising to provide every document you’ll ever need for £XX+VAT. But NONE of these #gdprcharlatans can provide the appropriate context that only comes from working with a person who knows that the Hell they are doing. These cannot just be paperwork, they must reflect your commitment to data protection by design and default, and the way you do business.

Second, you’ll need a documented record of what data you have a what you’re doing with it, but you should have taken care of this in your data discovery and business process mappings performed in Parts 2 and 3 of this series.

Third, all of your lawful bases for processing and corresponding data subject rights determined at Part 4 should be clearly articulated. Each will have its own idiosyncrasies:

  • Consent – corresponding privacy notices in clear and plain language, no ‘bundling’ of conditions etc;
  • Contractual – employee contracts, client contracts, data transfer agreements and so on;
  • Legal – [I’ll let a lawyer supply samples here];
  • Vital Interest – If lives are at stake you’d BETTER have a lawyer helping you out!;
  • Public Interest – Assuming you’re a public body, you should already have appropriate representation; and
  • Legitimate Interest – you will need to be VERY clear on how your ‘commercial’ interests are not “overridden by the interests or fundamental rights and freedoms of the data subject“.

Fourth, you will need to document all of your security controls in place around the personal data, as well as the risk assessment results that show that the controls meet the defined risk(s). Do not even THINK about showing a supervisory authority your PCI Attestation of Compliance, but a properly scoped ISO 27001 certificate would likely go a long way.

Finally, and if applicable, you will need to document your ‘records of processing activities’. Article 30(5) states; “The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.

So most of us can probably avoid the ‘high risk’ and ‘special category’ caveats, but ‘not occasional’? While ‘occasional’ is hard to define (like reasonable and appropriate), if you are processing personal data as part of a defined business process, it is unlikely that you will get away with saying “it’s only once a month” (for example).

That said, the requirement for maintaining record are not THAT onerous, unless you have hundreds of separate processes. They should also be made very clear by your supervisory authority. The UK’s ICO for example has even provided two templates, one for controllers and one for processors (near the bottom of the page).

I know this sounds like a lot, but with the exception of the lawful bases and records, you should already have the rest of this. If you don’t, not only will next week’s GDPR Step-by-Step be impossible, so will GDPR compliance.

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