GDPR Means DPIAs: Is Your Call Centre Ready?

Posted by: Malcolm Jarvis CIPP/E

Pop quiz: What do Equifax, Sony, Morrisons Supermarkets and the US National Security Agency all have in common?

If that was too easy, it’s probably because data breaches are big news and they have a habit of sticking in the public consciousness far longer than your average political scandal or FTSE upheaval. People have constructed a level of trust in organisations’ ability to protect and respect the information that they entrust to them, and when that trust is broken, 9 times out of 10 there’s a story of negligence leading to an avoidable accident all over the headlines.

Second question: if the individuals at the head of these organisations were given the chance to go back in time to put better protection in place to prevent these data breaches from occuring, what do you think they would do?

While time travel isn’t an option for them, hopefully your organisation is still data breach free and it’s not too late to put safeguards in place. If you’re looking for a systematic method of plugging the holes and securing your defenses, a Data Protection Impact Assessment, or DPIA, might be just what you’re looking for. Beyond that, the GDPR makes numerous references to DPIAs, so it’s worth knowing what they’re for, when you need to do one, when you probably should do one anyway, and what benefits you’ll realise as a result.

Before we start, I’ll make the usual disclaimers. I’m not a solicitor, data protection lawyer, or otherwise qualified in any way to give legal advice on this subject. Anything you read below is entirely as a result of my own research, mostly in response to questions from our customers in the face of the oncoming GDPR. Where possible, I’ve linked my source material so you can check for yourself and form your own opinions where appropriate. As in previous articles, I’ll pay special attention to the challenges specific to call centres, though the process will be very similar regardless of the industry you’re operating in.

When Do I Need To Do A DPIA?

One of the ways in which the GDPR differs from previous data protection legislation is the need for organisations to carry out a DPIA under certain circumstances. A DPIA is hardly a new concept, and from the supporting documentation released so far regarding DPIAs, it seems there’s a lot of crossover with Privacy Impact Assessments or PIAs, which are even more established. DPIAs use within the GDPR is interesting in that for most organisations they’ll be completely optional, but there’s a strong argument to be made for conducting them anyway.

If you have a look at Article 35 of the GDPR, you’ll find that it’s all about DPIAs.

Here we find that it’s the responsibility of the data controller to ensure a DPIA is carried out when required, where the controller is the company that’s calling the shots as to how the data is to be used. Obviously, data processors will be involved in the process of completing a DPIA, and if a Data Protection Officer (DPO) has been designated for the organisation or project, then they must be consulted throughout the process.

Article 35 starts with the statement that a DPIA is necessary when the use of data is “likely to result in a high risk to the rights and freedoms of natural persons”. It goes on to state that the supervisory authority, the ICO in the case of the UK, will publish a list of the kinds of data use that will require a DPIA, and another list of those that won’t. Once these lists are available it should be much easier to say for sure whether a DPIA is mandatory or purely optional for your business.

In the meantime, there are three circumstances that are listed in the GDPR as requiring a DPIA to be carried out. It’s worth noting that this is not an exhaustive list and it’s likely that comparable processing operations, either in terms of scale or the effect of the processing on individuals will also be considered to require a DPIA. For more examples, have a look at pages 7 and 8 of the Article 29 Working Party’s DPIA guidance, which is definitely recommended reading.

The three specific examples of activities that necessitate a DPIA be carried out are:

1. A systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person.
2. Processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10; or
3. A systematic monitoring of a publicly accessible area on a large scale.

Part (a) is all about profiling and automated decision making (ADM), which, while this is a recurring theme within the GDPR, isn’t generally relevant to call centre operations. It’s possible that some targeted profiling operations that call centre managers carry out may fall into the category of profiling in this case, but even then it only applies if the result of the profiling leads to a “significant effect” on the individuals. Companies like Facebook who use personal profiles to target advertising, or banks and insurers making financial decisions using personal information, are the most relevant types of organisation here.

Part (c) is concerned with monitoring public areas, such as with CCTV or wireless access points, so isn’t especially relevant to call centres.

Part (b), however, is relevant to call centres whenever a campaign involves data that falls into one of the special categories of data. Just as a reminder, these are:

• Racial or ethnic origin
• Political opinions
• Religious or philosophical beliefs
• Trade union membership
• Genetic data
• Biometric data for the purpose of uniquely identifying a natural person
• Data concerning health
• Data concerning a person’s sex life or sexual orientation

If your call centre is storing or gathering information from customers relating to any of these categories, then you’ll be expected to have a DPIA completed for each of these campaigns, should the ICO ever come knocking.

The Question of Scale

Recital 91 of the GDPR attempts to give an idea of what is meant by “large scale” without setting an explicit line in the sand. The example given is that processing wouldn’t be considered to be on a large scale if it only concerns, say, personal data from patients of an individual physician or clients of a lawyer. According to NHS Choices, the average number of patients per GP is 1,724 (or thereabouts), so it could therefore be concluded that a few thousand records is not considered “large scale”, whereas a hospital-worth of patient data definitely is.

It’s possible that one approach to minimising both your DPIA and DPO requirements could be to ensure that your data retention policies mean that special categories of data are only held for the short period while an application is being processed and is immediately deleted once the application is completed or declined. If this resulted in a maximum of a few thousand records containing such data being stored at a time, this may (and I stress, “may”) mean that the processing is not considered to be “large scale”, and hence the need for a DPIA (and indeed a DPO) may not apply. So far, it’s just a thought and, as with all these grey areas, seeking qualified legal advice is your best bet here.

Should You Conduct A DPIA Regardless?

Just because you don’t need to do a DPIA doesn’t mean you shouldn’t do one. The whole point of a DPIA is to ensure that:

1. Your business is giving due care to the personal data you hold
2. You can prove that you are giving due care to the personal data you hold
3. You have given proper thought and consideration, as an organisation, to giving due care to the personal data you hold

Conveniently, in carrying out a DPIA, you also tick many of the boxes required to ensure that the area of your business concerned is fully compliant with the GDPR. It doesn’t cover every aspect, but it certainly goes a long way.

Of course, there’s every chance that you’ll never need to prove your GDPR compliance, so conducting a voluntary DPIA could technically be a waste of time and resources. However, seeing as we don’t know how frequent ICO assessments will be (in the UK) once we get a new Data Protection Act (see Section 146 on page 80 of the Data Protection Bill), and that the process of conducting a DPIA will be of substantial benefit to your business both in terms of promoting best practice and protecting your business interests, a voluntary DPIA followed by occasional revisions may not be a bad idea regardless.

The other problem is a Catch 22. If part of a DPIA involves systematically identifying the existence and severity of risks in your use of data, and a DPIA is legally required for “high risk” processing of data, how can you be sure you don’t need a DPIA if you haven’t completed a DPIA?

The good news is that paragraph 1 of Article 35 states that you can rely on a single DPIA for multiple processing operations provided that the processing and risks are similar. This means you could use the same DPIA for multiple call centre campaigns provided they’re carried out in similar ways and involve similar types of data. Of course, if a DPIA was conducted for a campaign that, say, didn’t involve special categories of data (e.g. data relating to health), and you were looking to launch a campaign that did, then you’d be expected to review and revise your DPIA early in the new campaign specification process.

It’s probably worth noting that the DPIA guidelines mentioned above state on page 10 that systematic monitoring of employee activity counts as “high risk” processing and requires a DPIA. If you’re running a call centre, you’ll very likely be closely monitoring employee activity as a matter of course, so all indications are that all businesses operating a call centre will need to carry out at least one DPIA regardless. While this isn’t strictly a rule within the GDPR, guidance given by the Article 29 Working Party tends to be relied on heavily when interpreting the intention of regulations they relate to.

While we’re on the subject, page 11 of the same document states that a DPIA is not required for processing operations that have begun before 25th May 2018 (although it is “strongly recommended”). While it could be argued that a call centre’s processing operations within a single campaign remain unchanged from month to month, I’m not sure if I’d want to attempt to rely on that a couple of years down the road. If you do decide to delay conducting a DPIA on this basis, be aware that any significant changes to the way you use data (changes to scripts, forms, reports, IT systems, regulations etc), will mean that the controller needs to carry out a DPIA review. In the event that everything somehow remains unchanged, there’s still a time limit of three years before you’ll need to conduct a DPIA.

Beginner’s Guide to Carrying Out a DPIA

So how do you do a DPIA? The GDPR itself doesn’t give a lot of guidance, with paragraph 7 of Article 35 stating the following:

The assessment shall contain at least:

1. A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
2. An assessment of the necessity and proportionality of the processing operations in relation to the purposes;
3. An assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; and
4. The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.

Seeing as this is a legal requirement for many businesses, this really isn’t much to go on. Fortunately, the ICO published its “Conducting privacy impact assessments code of practice” in 2014, and it’s linked from the Article 29 Working Party’s guidelines on DPIAs as an example of an existing EU DPIA framework.

As I mentioned above, a DPIA and a PIA are not the same thing, however it seems that the opinion of those closest to the GDPR is that PIAs are similar enough to DPIAs to draw inspiration from. There’s a fair bit of controversy among industry experts as to the way that the GDPR and the Article 29 Working Party seem to almost use the terms DPIA and PIA interchangeably, and we can only hope that clearer guidelines and approved frameworks will appear in time.

Within the Article 29 Working Group guidelines on DPIAs, you’ll also find links to a couple of industry-specific DPIAs for Smart Metering Systems and RFID Applications (which has mysteriously disappeared in the last few weeks). These will give you an idea of what an EU approved DPIA looks like.

There’s also a recommendation to have a look at the ISO/IEC 29134:2017 guidelines for conducting a Privacy Impact Assessment (which you’ll need to pay for), further suggesting that in the context of the GDPR, DPIAs and PIAs are largely seen as covering the same ground or at least involving very similar processes.

The Article 29 Working Party presents the process for conducting a DPIA as an iterative process (i.e. there’s always room for going through the steps and refining your assessment once more), as follows:

1. Description of envisaged processing
2. Assessment of the necessity and proportionality
3. Measures envisaged to demonstrate compliance
4. Assessment of the risks to the rights and freedoms
5. Measures envisaged to address the risks
6. Documentation
7. Monitoring and Review
8. Back to Step 1

Let’s take a run through these and contemplate these steps in the context of a call centre environment. While a DPIA covering assessment of agent performance, attendance, salary, bonuses etc is just as relevant, as this is largely generic in the context of modern businesses, we’ll mostly focus on elements specific to call centre campaigns here.

1. Description of the envisaged processing

To begin your assessment you start by describing your business’ use of data as if it’s going to be read by someone entirely unfamiliar with call centre operations. As we saw above, paragraph 7 of Article 35 gives a very bare-bones introduction to what needs to be described here:

“a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller”, with Annex 2 of the Article 29 Working Party DPIA guide giving us much more detail.

So, under the heading “Systematic Description of the Processing”, you need to describe the “nature, scope, context and purposes of the processing”. This is a very broad question, and it’s probably easiest to break your answer into multiple subsections. The more detail the better though as it helps demonstrate your commitment to data protection and will make the following sections much easier.

Business Overview

What type of business or organisation do you operate? What benefit does it provide to its customers and especially the people you intend to contact through your call centre. Put another way, if your business ceased to exist, why would people be worse off?

For the particular operation that your DPIA relates to, whether that’s a campaign or an internal process, answer the same question - what is its purpose and why is it, on balance, a benefit to society?

How many people do you employ? What roles do they fill?

What do you intend to achieve by using the data involved in your operation? Is it purely to provide a product or a service while generating a profit, or do you perform a different function?

Is your call centre just telephone based, or do you also conduct web chats, process SMS messages, handle e-mails, social media communication and so on?

Why do you believe you are legitimately allowed to use the data you are working with? This needs to tie in with the legal basis for processing outlined in Article 6. The most common justifications for commercial call centres either being that you have the consent of the individuals you are contacting to contact them, or your business has a “legitimate interest” in contacting them and they haven’t objected to you doing so either directly or by means of the TPS. This topic, and the supporting “balancing test” is covered in much greater details here.

Data Acquisition and Handling

What data do you intend to use? Broadly speaking, how frequently and for what duration will you use and retain data after you’ve obtained it?

Where will you source data from? If using external suppliers, what due diligence will you carry out to ensure that it is provided from a legitimate source? If relying on opt-ins, what methods will you use to ensure that opt-ins are valid? How will data be transferred into your care?

Who will have access to the raw data (i.e. the CSV or Excel file) and have responsibility for loading it into your IT systems?

Who will have access to the data you are using? For each job role with access to the data, how much access do they have?

If third party companies are involved (for example, a hosted call centre software provider), how will you transfer the data safely into their systems? What due diligence will you carry out to ensure that it will be properly managed and protected in their care? What assurances will you have that data will be properly deleted when it no longer needs to be retained by third parties?

Data Profile and Lifecycle

What fields will your data contain and what fields will be populated during the course of communication with a customer? Why do you need each field? Which of these fields are considered to be Personally Identifiable Information (PII)?

Remember to include details of data such as call history and call dispositions. These also build up a picture of the individuals you are calling (i.e. the times of day that they answer their home phone, whether they’re vulnerable or elderly or financially disadvantaged).

What fields fall into one of the special categories of data (health, ethnicity, political opinions etc)?

How will the data be changed or augmented in the course of your use of it?

How long will you keep each data field for? Will records meeting certain criteria be kept longer than others (i.e. after a successful call)?

If you’re recording calls, how long will you keep the recordings for? Who will have access to them? Does the naming convention for your call recordings contain any personal data? Will you be transferring any call recordings outside of your organisation?

Once loaded into your IT systems, what happens with each data record? How often will it be called / texted / e-mailed both per day/week/etc and over the lifetime of the record’s existence on your systems?

If you plan on anonymising the data in your system after you can no longer reasonably justify keeping it, which fields will you keep and which will you remove? Could any combination of remaining fields be used to re-identify the individual concerned?

Data Environment

What physical equipment will your agents, managers and team leaders have access to? Will everything be on PC, or will they have access to paper notepads as they work?

Will employees have restricted or unrestricted Internet access? Will they be supervised throughout their working day?

Do you have any homeworkers?

What software applications will they have installed on their PCs? What security controls are in place on agent desktops? On manager PCs and laptops?

Applicable Regulations and Codes of Conduct

What are the relevant codes of conduct that you must adhere to? As well as the GDPR, you’ll still need to be fully compliant with the Data Protection Act, the PECR, the e-Privacy directive, the new e-Privacy regulation when its adopted into law, and all the other rules or regulations applicable to your line of business.

That should be enough to provide a pretty comprehensive overview of your business, the data that you intend to (or already) use, the environment that you operate in, and the various parties involved. It should also get your mind thinking in terms of all the different types of risk that are present within your business, which will be very useful later in the process.

Paragraph 2 of Article 35 reiterates that if a Data Protection Officer (DPO) has been assigned to your project, then they need to be involved in all steps of the DPIA process. You’ll also want to make sure their involvement or absence is recorded within the DPIA itself.

Lastly, paragraph 9 states that, where possible, the views of the data subjects themselves should be sought. For most call centre environments this may be a step too far, but again you’d best record that it was at least considered.

2. Assessment of the necessity and proportionality

The second stage of your DPIA requires you to explain why you need to use the data you intend to use and why your use of the data is reasonable in relation to your needs and the rights of the people whose data you’ll be using.

Is Your Use Necessary?

Establishing the necessity should be easy enough as you just need to explain why you couldn’t achieve the goals described in the previous stage by another means. Why not send letters to everyone in your data list instead of phoning them? Why not purchase TV, radio or Internet advertising? What is the benefit to your business and your existing and potential customers in keeping the volume of data you hold for the duration that you hold it?

Try to list and describe as many benefits as possible to the consumer as well as to your organisation. If you have a complex or innovative product, attempting to describe it in an ad or brochure may not be practical. If you’ve looked at Facebook or Google ads and found the cost to conversion rate to be far worse than a call centre campaign, then here’s the place to state your findings. If your approach creates 50 jobs compared to zero jobs created by an e-mail campaign, that’s an argument too.

Is Your Use Proportionate?

The next question to answer is whether your use of data is proportionate to your needs and the rights of the individuals whose data you are using? For example, how long and how often will you use the data? What details will you acquire and store? Is your retention period and frequency of use in line with the reasonable expectations of the individuals you intend to contact? Is it in line with all relevant regulations and industry guidelines?

A good way to approach these questions is to discuss how you intend to use the data with a sample of people and ask whether they agree that your use of their data would be reasonable? While this could be conducted as a purely theoretical exercise, doing so honestly, or at a minimum quizzing family, friends and colleagues, could reveal some hard truths about people’s expectations regarding your use of their data. The louder the objections to your intentions, the more you may want to consider whether your use of certain types of data is strictly necessary, and the more safeguards you may want to put in place in step 5.

You should revisit your legitimate reason or other basis for using the data, as defined in Article 6 and explained in terms of call centres in my earlier blog post here, in more detail in this section. If you haven’t done a balancing test of your needs compared to the rights of the individuals whose data you’re using, you’ll find a lot of overlap between this and doing a DPIA.

It's a good idea to state clearly in this section that your use of data will be limited to only that described in your DPIA. Use of data for purposes other than those that you have documented is contrary to Article 5, paragraph 1(b), meaning you have a legal requirement to record what you intend to use data for and then only use it for that purpose (another good reason to conduct a DPIA, even if you don’t have to).

If your requirements grow, or for example, you realise you need to use additional data fields, then that’s fine but you’ll need to step revise your DPIA to keep your organisation completely GDPR compliant.

Eventually, You Need To Let Go

You also need to describe how long you intend to keep the data for, either as a fixed date or by describing the criteria that will determine when you will delete the data and explain why you think this period is reasonable. You’re allowed to keep anonymised data (i.e. data with names, addresses, phone numbers and other identifying information removed) for statistical purposes as long as you like, but “for historical analysis” or “just in case we need it” won’t be seen as justification for hanging on to people’s data in full.

While you probably don’t need to go through each data field individually here, an overview of the types of data field you intend to purchase/collect and a confirmation that each data field has been confirmed as necessary for the successful conduct of your business is worth including here.

Privacy Notices For Call Centres

The next thing to address are the measures that you will put in place to contribute to the rights of the individuals whose data you’ll be using. The rights of your data subjects are detailed in Articles 12 through 22 of the GDPR and the means by which you’ll be meeting these requirements need to be documented as part of your assessment of the proportionality of your processing. You’ll be addressing each of these individually as part of your risk assessment in step 4, so an overview of how you intend to convey these to your customers should be adequate here. One method would be creating a call centre script and training your agents on how to deliver it (or direct people to your website), which was covered in detail in this earlier post.

You’ll also need to consider whether data will be travelling outside the EU and if so, how you intend to provide the same safeguards once data has passed outside the remit of the EU nations.

In the event that your DPIA indicates that some aspect of your processing will present a “high risk” to your data subjects even with all safeguards in place, Article 36 states that you, or your DPO, must consult with the ICO (in the UK) before proceeding any further. Acknowledging this requirement and committing to comply with it at this point in your DPIA can’t do you any harm.

3. Measures envisaged to demonstrate compliance

It’s not enough to simply know that your use of data is compliant with the GDPR and other relevant regulations, you need to be able to prove it. The need to be able to demonstrate a proactive approach to data protection is one of the most significant changes in the GDPR from previous data protection legislation, and it definitely isn’t something you’ll be able to quickly fill-in if you find yourself under the ICO’s gaze.

For all the commitments you’ve made in the previous step, how will your organisation demonstrate that they’re being followed? This step will work hand-in-hand with a well thought out Data Protection Policy and staff data protection training programme, both of which give you reusable resources essential to GDPR compliance. Your Data Protection Policy details the various rules that your organisation will follow in relation to data throughout your organisation. If you haven’t reviewed it for some time (or worse, don’t have one), now would be a really good time to do so.

Good IT systems can go a long way to ensuring your data protection requirements are met. For example, properly configured systems can provide dependable logs of who has accessed customer data, restrict access to each type of data to only those who require access, and bolt down who can export bulk customer data and where it can be sent to. They can also prevent irrecoverable loss or corruption of data and keep track of which third parties you’ve shared individual data records with.

Lastly, if you’re using any third parties in processing your data or transferring information to another company (details of successful transactions, for example), then you’ll need to detail how you intend to confirm that these companies will properly take care of the data that you’re placing in their care.

For example, if you receive a request from an individual to erase all information you hold about them, you’ll need to have procedures in place to pass this request to anyone else you’ve shared the individual’s data with and guarantees that the request will be promptly actioned. Along with defined processes to handle these types of request, you also need to record what commitments to information security, staff training and data protection procedures each of your data processors has in place. Detailing the means by which you intend to assess the suitability of third parties and measure their ongoing compliance will ensure that you don’t land in hot water at a later date through the actions of individuals outside of your business.

4. Assessment of the risks to the rights and freedoms of your data subjects

This stage of your DPIA is when you and your team need to give serious consideration to the “rights and freedoms of your data subjects” that are potentially being affected by your use of their data? We’ll have a look at the types of rights and flavours or freedom that the GDPR is concerned with below, but firstly we need to understand what’s meant by “risk” in the context of a risk assessment.

A “risk” is a scenario describing an event and its consequences, with the severity estimated in terms of impact and likelihood. Recital 75 gives us more details around the types of risks that the GDPR is concerned with.

Way back in 2014, the Article 29 Data Protection Working Party issued an opinion (statement 14/EN WP 218) which states:

8/ In the context referred to above, the scope of “the rights and freedoms” of the data subjects primarily concerns the right to privacy but may also involve other fundamental rights such as freedom of speech, freedom of thought, freedom of movement, prohibition of discrimination, right to liberty, conscience and religion.

It may seem odd to think of data protection affecting freedom of movement or the right to liberty. However, if you stop and think about companies such as Apple or Google constantly collecting location data from someone’s smartphone, this data would allow you to predict when an individual is typically at home and when they leave the house. Thus a data breach revealing this information could result in that individual not feeling safe to leave their home.

You could easily extend this to phone call records building a picture over time as to when an individual is at home to answer the phone and when it goes to voicemail. Even the most mundane data in the hands of the wrong individual can lead to serious consequences.

Anyway, the ICO, in their Privacy Impact Assessments Code of Practice list the following “Risks to individuals” (and, yes, as mentioned above, I’m aware that a PIA isn’t the same as a DPIA, but we’ll work with what we’ve got!):

• Inadequate disclosure controls increase the likelihood of information being shared inappropriately.
• The context in which information is used or disclosed can change over time, leading to it being used for different purposes without people’s knowledge.
• New surveillance methods may be an unjustified intrusion on their privacy.
• Measures taken against individuals as a result of collecting information about them might be seen as intrusive.
• The sharing and merging of datasets can allow organisations to collect a much wider set of information than individuals might expect.
• Identifiers might be collected and linked which prevent people from using a service anonymously.
• Vulnerable people may be particularly concerned about the risks of identification or the disclosure of information.
• Collecting information and linking identifiers might mean that an organisation is no longer using information which is safely anonymised.
• Information which is collected and stored unnecessarily, or is not properly managed so that duplicate records are created, presents a greater security risk.
• If a retention period is not established information might be used for longer than necessary.

From this we can conclude that the definition of “risk” is very broad indeed. Data being used for a purpose other than which it was intended is a risk. Data being kept longer than necessary is a risk. The possibility of someone being upset because they didn’t expect a call from you is a risk. Collecting more information than individuals might expect is a risk. Given that all these risks are present in most call centre environments, an assessment to establish whether any of these constitutes a “high risk” is likely to be mandatory for most environments.

As well as establishing the risks to individuals, your DPIA should also consider the risks to your organisation, such as reputational damage, loss of business, litigation, fines, claims etc, in the event of a data breach. Lastly (but definitely not least), legal compliance risks such as failing to implement and enforce compliance with all relevant industry regulations, is the final category of risks your DPIA needs to consider.

In order to identify the risks inherent in your call centre, you and your team need to contemplate all the ways that your use of consumer data could land your business in trouble. While going through this process, you need to bear in mind that anything that causes consumers to complain to the ICO will sooner or later land your business in trouble. The ICO has historically prioritised their actions on businesses generating the largest volume of complaints, and there’s no reason to think that this will change under the GDPR.

You also need to consider the likelihood of each risk occuring and the impact of the situation on the individual(s) concerned and your business should it occur. By combining the likelihood and the impact, you can also score the significance of each risk.

If you’ve ever conducted a health and safety audit, the process is very similar. No risk is too small to be considered and the more thorough your analysis of the risks, the better equipped you’ll be to consider means by which to address them. And, just as with health and safety audits, it’s all very tedious until there’s blood on the office floor or an ICO letter on your desk.

Obviously we don’t want to end up in either of these scenarios, so set aside some time with your team and come up with as many things that could go wrong in relation to the data that you use in your business and get them down on paper.

Some call centre specific examples would be:

These are just some ideas off the top of my head, and I’m sure you and your team will be able to think up dozens more. When coming up with your list of risks, you need to include the risk source (who is carrying out the action) and the nature of the risk (what they’re doing). You may want to further classify the risk source by the intention of the individual. Are they simply being clumsy or forgetful (the poorly secured laptop left on a train), or is there actual malicious intent involved?

Once you have your first draft of your list of risks, add two extra columns labelled Likelihood and Impact. You can score each by whatever system seems most appropriate to you and your team, but ultimately you’re looking for a means by which to identify the risks that are reasonably likely to happen and that will cause a degree of distress or disadvantage to the individual(s) concerned and/or the company itself should they occur.

Evaluating Likelihood

The likelihood of a risk occurring is a combination of the source of the risk (a disgruntled employee, a computer hacker, a poorly trained manager etc) and the difficulty with which they could execute the risk. This means that some risks will have more variations depending on who is carrying them out. For example, a disgruntled call centre agent may find it very difficult to download a list of all successful sales from the last year to a USB pen drive. A disgruntled manager or IT support person may find the same task relatively easy, at least without proper controls in place. In this case, list these as two or more separate risks so you can consider safeguards for each individually.

When considering the likelihood of any risks occurring, take into consideration existing safeguards (provided they actually work), but don’t include ones that haven’t yet been implemented as these will come later in the process.

Evaluating Impact

Contemplation of the impact of each risk from the point of view of the data subject (i.e. the person who the data is about) is essential. Consider the nature of the data that could be exposed by the risk and how they individual concerned would feel about that information being lost, corrupted or stolen. For example, a breach exposing data falling into one of the special categories of data would potentially constitute a very high impact, whereas a similar risk that only exposes vanilla name, address and phone number data would be relatively low impact.

As with your evaluation of the likelihood of a risk occurring, you may find that the impact of a risk happening is very different for the different stakeholders affected. For example, it may be the case that if you fail to inform people about their rights under the GDPR the impact on the individual would probably be very small. However, if audited and found to be missing this key element of compliance, the impact on the company could be very significant indeed.

For an example of how to score likelihood and impact of risks, the Article 29 Working Party has linked a couple of DPIA processes from other industries in their advice. If you look on page 27 to 31 of the 2014 DPIA Template for Smart Grid and Smart Metering Systems, you’ll find a detailed, systematic approach to evaluating risks that’s worth a look.

Remember, this isn’t a one-off process. As well as conducting regular reviews, you ideally need to instill in your team a risk-aware attitude that means that potential risks are continually being identified and added into your assessment.

It’s extremely important to remain as neutral and objective as possible while carrying out your assessment. If available, an external expert will make the process much more thorough and less likely to be affected by the preconceptions and assumptions of those inside your company.

Once you have your analysis of risks along with the likelihood of each occurring and the estimated impact should each occur, you’ll be able to see exactly where to focus your efforts. Only risks with both a low likelihood and a low impact demand little action. Risks with either a high likelihood of occuring, a high impact should they occur, or both, will need to have safeguards introduced to reduce the risk to acceptable levels.

5. Measures envisaged to address the risks

Now that you’ve got your first pass at the risks that your business and its activities pose to people’s data, it’s now time to think of how you’re going to reduce these risks. Ideally to the point that they’re not risks at all. For each of your risks, you need to provide clear, actionable safeguards that the teams within your business can implement in order to reduce the chance of high likelihood risks occurring and the impact that high impact risks would have.

Initially, a brainstorming session, either with all departments involved or separately within each department will give you a good starting point for getting as many solutions as possible down on paper. Safeguards will naturally fall into different categories such as IT, training, physical security, processes, auditing and so on.

You’ll then need to evaluate each based on cost, complexity, availability of resources, effectiveness etc, in order to determine which can become part of company policy and which will need to be discarded. Even safeguards that are discounted are probably still worth keeping a record of so that you can explain your reasoning for not adopting them should you be challenged in the event of an audit.

Safeguards can, of course, be layered. One safeguard may reduce the likelihood of a risk from high to medium, but two safeguards could reduce its likelihood all the way to low or negligible.

The goal of the exercise is to ensure that all risks have been properly identified and evaluated, and that each of them has adequate safeguards to ensure that when their impact and likelihood are considered, there’s a negligible chance of any high impact risks occurring, and a negligible impact should any high-likelihood risks occur. Ideally, all risks should be reduced to the point that they’re either very unlikely to occur, or very low impact if they do.

In the event that any high risk activities remain after safeguards are put in place, you need to contact your supervisory authority for advice (the ICO in the UK), before any processing takes place. If you find your company in this situation, if possible you should first engage outside expertise as there are likely to be solutions to your problems that have been worked out elsewhere. Remember that while the GDPR is new, DPIAs and PIAs certainly aren’t, and data protection is a discipline that’s been around for decades. Plenty of expert advice is available, even if it is likely to be in increasingly high demand as the year progresses.

6. Documentation

As with everything to do with the GDPR, nothing counts unless it’s systematically documented. For all the stages of your DPIA, and all the safeguards you have identified, you must have adequate record-keeping procedures in place to prove that your company is practicing what your DPIA is preaching.

This will be a significant task the first time round, so you may want to look into outside help or the availability of toolkits to get you started. Either way, once you’ve got your first iteration complete, you’ll have a much easier task maintaining and adding to your DPIA as time goes by. You’ll also have an excellent starting point, both in terms of content and expertise, when starting a fresh DPIA for a new project.

7. Monitoring and review

Your Data Protection Policy and each DPIA should indicate how and when your DPIAs should be reviewed as well as processes and criteria for monitoring their success. The Article 29 Working Party Guide to conducting a DPIA states on page 12 that a DPIA should be continually carried out as a matter of good practice. Failing that, and on the assumption that no changes to the nature of the data or the means of processing occur, once every 3 years is advised as an absolute maximum.

Remember to document your review policy and set a date in your diary for when you need to revisit your DPIA. DPIAs should include an audit trail that records each time it has been reviewed and a summary of what’s changed.

8. Iterate

Of course, a DPIA is not a one-off process. In order for the first version of your DPIA to be considered complete, these steps should be repeated multiple times to ensure that all risks and potential safeguards are fully considered. The idea is that as you repeat the process and you become more familiar with your data, your environment and the risks involved, you’ll gain more insight into potential risks and safeguards that you hadn’t even considered the first time round.

As mentioned above, depending on how often the nature and means of processing changes, once the first DPIA is considered complete, the process should be repeated at least once every three years, but probably a lot more frequently than that.

The Need to Consult Your Supervisory Authority

If, having conducted your DPIA, high risks still remain, then you, or your DPO if one is designated, need to contact your supervisory authority (the ICO in the UK) and seek their advice. If you do so, you’ll not be surprised to learn that any advice or guidance given must be integrated into your DPIA.

If you’ve got this far then you’ll have realised that a DPIA is not a trivial process. Hopefully though, you’ll also have seen the potential benefits of carrying out a systematic, thorough assessment of your organisation’s use of data beyond the simple regulatory need to do so. Trust is a massive element in the success of a business, and few actions lead to loss of public trust like a data breach or lost data. While companies can and do recover from such scenarios, how much better for them would it be if they had taken adequate steps to avoid the breach or data loss in the first place?

Making DPIAs part of your business will take time and resources, two things that not all companies have a surplus of. However, given then accountability principle of the GDPR that demands systematic documentation of your data use and data protection, and the potential benefits that a DPIA offers, they might just help keep your proverbial fan stain-free.