Data Protection by Design: Part 3 – Data Protection Impact Assessments

September 2020

Getting your DPIA process on track

Deciding when to carry out a Data Protection Impact Assessment (DPIA), and understanding how to conduct one effectively, is a challenging area.

I’ve come across cases where DPIAs are not being conducted when necessary, or left incomplete. Less frequently, DPIAs are over-used, creating an unnecessary burden on key teams.

DPIAs sit at the heart of Data Protection by Design, and this is part 3 of our series, following on from:

Part 1: Data Protection by Design – The Basics 

Part 2 – How to approach Data Protection by Design

Just to be clear – we may be hearing the term DPIA more frequently, but it’s not a new idea – what changed under GDPR is they were made mandatory in certain circumstances. And even if not mandatory they can be a very useful tool in your data protection toolbox.

So how do you make sure your DPIA process is on track? I’ve taken a look at the key stages you should have in place, and how to get people on-board and improve their understanding.

But first things first.

What is a Data Protection Impact Assessment?

Just to recap, a DPIA is a management tool which helps you:

  • Identify privacy risks
  • Assess these risks
  • Adopt measures to minimise or eliminate risks

It’s a way for you to analyse your processing activities and consider any risks they might pose. It focuses on identifying any risks to people’s rights and freedoms, and considers the principles laid down in data protection law.

The key is to start the assessment process early so you can make sure any problems are found (and hopefully fixed) as soon as possible in any project – be this implementing a new system, designing a new app or creating new processes.

When is a DPIA mandatory?

When considering new systems, technologies or processes a DPIA should be conducted if these might result in a high risk to the rights and freedoms of individuals. A DPIA may also be conducted retrospectively if you believe there are inherent risks.

It’s mandatory, under the GDPR to conduct a DPIA in all of the following scenarios:

  • 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
  • processing on a large scale of special categories of data or of personal data relating to criminal convictions and offences
  • a systematic monitoring of a publicly accessible area on a large scale

Each EU regulatory authority has published their own list of other scenarios in which a DPIA would be mandatory. You can find the UK Innformation Commissioner’s Office’s in its DPIA Guidance. This includes;

  • use innovative technology (note the criteria from the European guidelines)
  • process biometric data or genetic data (note the criteria from the European guidelines)
  • match data or combine datasets from different sources
  • collect personal data from a source other than the individual without providing them with a privacy notice (‘invisible processing’) (note the criteria from the European guidelines)
  • track individuals’ location or behaviour (note the criteria from the European guidelines)
  • profile children or target marketing or online services at them – it’s also worth checking the new ‘Children’s Code’ aimed at protecting children online

When a DPIA is not mandatory… but a good idea

The ICO says it’s “good practice to do a DPIA for any other major project which requires the processing of personal data.” Here are some examples of where it might be advisable to conduct a DPIA, if your processing;

  • would prevent or restrict individuals from exercising their rights
  • means disclosing personal data to other organisations
  • is for a new purpose (i.e. not the purpose the data was originally collected for)
  • will lead to transfer of personal data outside the European Economic Area (EEA)
  • involves contacting individuals in a manner which could be deemed intrusive.

What the ICO expects you to do

The ICO DPIA guidance has a handy checklist of areas to focus on:

  • provide training so staff understand the need to consider a DPIA at the early stages of any plan involving personal data
  • make sure existing policies, processes and procedures include references to DPIA requirements
  • understand the types of processing that require a DPIA, and use the screening checklist to identify the need for a DPIA, where necessary
  • create and document a DPIA process
  • provide training for relevant staff on how to carry out a DPIA

How to build a robust DPIA process

So how do you go about fulfilling the ICO’s expectations above? Here are some steps to take.

A. Getting Board / Senior Management buy-in

Growing awareness and buy-in from across the organisation is crucial. It can be helpful to highlight why DPIAs are a good thing, for example;

    • they’re a warning system – they alert compliance teams, and the business as a whole, of risks before they occur. Prevention is always better than cure
    • by identifying risks before they’ve an adverse impact, DPIAs can protect you against potential damage to your brand reputation, e.g. from complaints or enforcement action
    • they help management make informed decisions about how your processing will affect the privacy of individuals
    • they show you take data protection seriously and provide evidence, should you need it, of your compliance

Training is also important, I’ll come on to this in a bit, but first you need to make sure your process is fit for purpose….

B. Creating a screening questionnaire

Create a quick set of questions for business owners or project leads to use, which help to identify if a DPIA is required or not.
These can ask about the type of personal data being used, whether it entails any special category data or children’s data, what the aim of the project is and so on.

The answers can be assessed to judge whether a more detailed assessment is really required or not. (It can also show where more training might be needed, if people struggle to answer the questions).

C. The DPIA itself

You need to develop a robust process for conducting a DPIA. The ICO has a template you can use, but it’s good idea to adapt this to suit your business. Make sure it’s easy to understand and not full of data protection jargon.

These are the core aspects it needs to cover:

    • describe the processing you are planning to do – it’s nature, scope, context and purposes
    • assess its necessity and proportionality
    • identify and asses any risks
    • identify solutions and integrate into a plan
    • sign off and record outcomes
    • implement risk control plans
    • and finally, keep your DPIA under review

Let’s look at these seven key stages in a little more depth…

1. Describe your processing

These are some of the type of questions you’d want answers to (this is not an exhaustive list):

    • how is personal data being collected/used/stored and how long it is retained for?
    • what are the source(s) of the personal data?
    • what is the relationship with individuals whose data will be processed?
    • what types of personal data does it involve, does this include special category data, children’s data or other vulnerable groups?
    • what is the scale of the activity – how many individuals will be affected?
    • is the processing within individuals’ reasonable expectations?
    • will data be transferred to a third party and is this third party based outside the EEA?
    • what risks have already been identified?
    • what are the objectives? Why is it important to the business and / or beneficial for individuals?

2. Necessity and proportionality

Consider the following questions (again, this is not an exhaustive list):

    • what is the most appropriate lawful basis for processing?
    • is there another way to achieve the same outcome?
    • have you ensured that the minimum amount of personal data is used to achieve your objectives (i.e. data minimisation)?
    • how can you ensure data quality and integrity is maintained?
    • how will you inform individuals about any new processing?
    • how will individuals’ rights be upheld?
    • are any processors used and if so how will you ensure their compliance?
    • how will international transfers be protected, what safeguard mechanisms will be used?
    • who will have access to personal data, does this need to be restricted?
    • where will data be stored and how will it be kept secure?
    • how long will data be retained and how will data be destroyed when no longer required?
    • have the relevant staff received appropriate data protection training?

3. Identify and assess the risks

Identify any privacy issues with the project and associated risks. These may be risks to the individuals whose data is being processed, compliance or commercial risks.

Is there potential for harm, whether this be physical, material or non-material? A DPIA should ideally benchmark the level of risk using a risk matrix which considers both the likelihood and the severity of any impact on individuals.

You don’t have to eliminate all risks, but they should be documented, and any residual risks need to be understood and, if appropriate, accepted by the business.

If you identify a high risk that you cannot mitigate, you must consult the ICO before starting the processing.

4. Identify solutions and integrate into a plan

Develop solutions which will eliminate or minimise privacy risks and then consider how these solutions impact on the project.

It can be helpful to use the established ‘four strategies for risk management’ (the 4Ts), i.e.

    • Treat the risk, i.e. adopt measures to minimise or eliminate risk
    • Transfer the risk, e.g. outsource the processing
    • Tolerate, e.g. accept risk if its within the organisations accepted level of risk
    • Terminate it, i.e. stop that specific processing or change the process in such a way that the risk no longer exists

5. Sign off and record outcomes

Someone must sign-off that the DPIA is complete and be accountable for any residual risks. It’s a good idea to log residual risks in your Risk Register.

6. Implement risk control plans

7. And finally, keep your DPIA under review

There’s also lots of useful content on this in the ICO’s DPIA Guidance.

D. Awareness and Training

Once you have your questionnaire and DPIA process ready to go, it’s time to make sure people know about it! If people aren’t aware they’ll be busy doing fabulously innovative things, not considering the potential data protection issues and impact on people’s privacy.

Making sure your teams know what a DPIA is, in simple layman’s terms, is an important step – building an understanding about why it’s important and the benefits to the business as a whole.

Creating short, easy to understand, guidelines and raising awareness via other means helps reinforce the message that DPIAs are a good thing and people need to think data protection in their day to day work.

It’s also important to develop people’s skills. After all the DPO (or team/person responsible for data protection) can’t do this single-handed. You need key people to know;

    • what a DPIA entails
    • how to answer the questions
    • what are the types of risks to look out for
      and
    • what type of solutions will mitigate any identified risks

Holding workshops with relevant staff to discuss how you conduct a DPIA, and / or perhaps run through an example, can help improve people’s skills. My key tip would be to try and not over-complicate things and to keep it straightforward.

In summary, whether you are required by law or not to complete a DPIA they are a useful way to make sure data protection is considered from the outset, with no nasty surprises just before your project launches!

“But it’s essential that we go live on Friday!” If I had a penny for every time I’ve heard this one. If only they’d known, or thought of, speaking to the people responsible for data protection.

Often a DPIA won’t required, but there’ll be times when it’s mandatory or just a very good idea.

 

Data Protection team over-stretched?  We can review your existing DPIA process or help you to develop one. We can also do remote DPIA workshops for key members of your teams – Get in touch

Data Protection by Design: Part 2 – How to approach it

September 2020

How to implement Data Protection by Design 

Following my colleague Phil Donn’s popular article on Privacy By Design (Part 1), I’m delving into the detail of what to consider when you are developing new applications, products and service and the how to approach the assessment process.

Good privacy requires collaboration

As a reminder, Data Protection By Design requires organisations to embed data protection into the design of any new processing, such as an app, product or service, right from the start.

This implies the DPO or Privacy team need to work with any project team leading the development, from the outset. In practice, this means your teams need to highlight any plans at the earliest stages.

A crucial part of a data protection or privacy role is encouraging the wider business to approach you for your input into changes which have implications for privacy.

Building strong relationships with your Project and Development teams, as well as with your CISO or Information Security team, will really help you make a step change to embed data protection into the culture as well as the processes of the organisation.

What are the key privacy considerations for Data Protection by Design?

Here are some useful pointers when assessing data protection for new apps, services and products.

  • Purpose of processing – be very clear about the purpose(s) you are processing personal data for. Make sure these purposes are both lawful and carried out fairly. This is especially important where any special category data or other sensitive data may be used.
  • End-to-end security – how will data be secured both in transit (in and out of the app, service or product) and when it’s at rest?
  • Access controls – check access to data will be restricted only to those who need it for specific business purposes. And make sure the level of access (e.g. view, use, edit, and so on) is appropriate for each user group.
  • Minimisation – collect and use the minimum amounts of personal data required to achieve the desired outcomes.
  • Default settings – aim to agree proactive not reactive measures to protect the privacy of individuals.
  • Data sharing – will personal data be shared with any third parties? If so, what will the lawful basis be for sharing this data?
  • Transparency – have we notified individuals of this new processing? (Remember, this may include employees as well as customers). If we’re using AI, can we explain the logic behind any decisions which may affect individuals? Have we told people their data will be shared?
  • Information rights – make sure processes are in place to handle information rights. For example, can data be accessed to respond to Subject Access Requests? Can data be erased or rectified?
  • Storage limitation –appropriate data retention periods should be set and adhered to. These need to take into account any laws which may apply. To find out more see our Data Retention Guidance.
  • Monitoring – what monitoring will or needs to take place at each stage to ensure data is protected?

The assessment process

If there’s likely to be high risk to individuals, you should carry out a Data Protection Impact Assessment. This should include an assessment covering the requirements above.

Many organisations use a set of screening questions to confirm if a DPIA is likely to be required and I would recommend this approach.

In most cases it will also be appropriate for the Project team to consult with their CISO or Information Security Team. It’s likely a Security Impact Assessment (SIA) will also need to be carried out.

In fact, adopting a joint set of screening questions which indicate if there’s a need for a security assessment and/or a DP assessment is even better!

Embrace the development lifecycle

The typical stages involved when developing a new app, product or service are:

Planning > Design > Development > Testing > Early life evaluation > Production

Sometimes these stages merge together, it’s not always clear where one ends and another starts, or they may run in parallel.

This can make the timing of a data protection assessment tricky, particularly if your business uses an Agile development methodology, where the application design, development and testing happen rapidly in bi-weekly ‘sprints’.

I find when Agile is used the answers to certain data protection questions are not necessarily available early on. Key decisions affecting the design may be deferred until later stages of the project. The final outcomes of the processing can be a moving feast.

I always take the data protection assessment process for new developments step by step. Engaging with the Project team as early as possible and starting with the privacy fundamentals.

For example, try to establish answers to the following questions:

  • What data will be used?
  • Will any new data be collected?
  • What are the purposes for processing?
  • What will the outcomes look like?
  • How will individuals be notified about any new processing?
  • Is the app, service or product likely to enable decisions to be made which could affect certain individuals?

An ongoing dialogue with the Project team is helpful. This can be scheduled in advance of key development sprints and any budget decisions which could affect development.

This way the more detailed data protection requirements can be assessed as the design evolves – enabling appropriate measures and controls to protect personal data to be agreed prior to development and before any investment decisions.

Let me give you an example…

I recently helped a to carry out a DPIA for a new application which aimed to improve efficiency by looking at operational workflow data, including certain data on employees who carried out specific tasks.

When we started the design was only partially known, it wasn’t yet agreed whether certain components were in or out of scope, let alone designed. Therefore data protection considerations such as the minimisation of data (to include only that necessary for the processing), appropriate access controls and specific retention periods had not and couldn’t be decided.

We worked through these items as the scope was agreed. I gave input as possible designs were considered, prior to development sprints. We gradually agreed and deployed appropriate measures and controls to protect the privacy of individuals.

Too often in my experience the privacy team is called in too late.  This only leads to frustration if privacy issues are raised in the later stages of a project.  It can cause costly delays, or the poor privacy team is pushed into making hasty decisions. All of which is unnecessary, if teams know to go to the privacy team from the outset.

It can take time and perseverance to get your colleagues on board.  To help them to understand the benefits of thinking about data protection from the start and throughout the lifecycle of projects. But once you do, it makes your business operations run all the more smoothly.

 

Can we help? Our experienced team can support you with embedding Data Protection By Design into your organisation, or with specific assessments –  contact us