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

Simon BlanchardSeptember 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

Dashcams and GDPR: Assessing the privacy implications

Simon BlanchardAugust 2020

7 point privacy guide for dashcams

The use of dashcams by taxi firms, business vehicle fleets and others is on the increase. Their use is encouraged by insurers and they are seen as an effective way of combating accident insurance fraud.

As dashcams are highly likely to capture images of people, companies installing them need to take stock and consider data protection law. This is personal data and you should consider the potential privacy impacts on those caught on camera, much in the same way as you would do when using CCTV.

Here’s my 7 point privacy guide for anyone using or preparing to install dashcams.

Confirm what you’re using cameras for. You need to start with a clearly defined purpose (or purposes) for the images you wish to capture. For example to enable us to investigate alleged accidents for insurance purposes.
Create a policy. Your ‘Dashcam Privacy Policy’ should make it clear what specific purposes these images are used for and identify the lawful basis for any processing of personal data images. You should make sure the processing is necessary and limited to those purposes. A policy should also explain what measures and controls are in place to protect individuals whose images are captured.
Brief your drivers. Put simply drivers who operate the dashcams and anyone else who may use the images should fully understand how the cameras should be use and ow the data collected should be handled.
Notify the public. You should consider putting clear signs on vehicles which have cameras. In a similar way to how you would tell people CCTV is in operation. and declare the capture of dashcam images within your company’s privacy notice. In a similar way to how you would tell people CCTV was in operation.
Make sure images are transferred and stored securely. Many modern dashcams used by vehicle fleets provide the capability to schedule image downloads daily to a central image library for storage. These transfers must be secure, as must the location where the images are stored. Access should be restricted, given only to those who are authorised to use the images for the purposes you have specified.
Decide how long to keep the recordings. One of the core data protection principles is not to keep personal data for longer than you need it. You may only need to keep most images for a very limited period, in case an accident is reported to you. Some claims may come in weeks after the event – so your own experience needs to dictate what is a reasonable period to hold on to recordings. If no accident is reported within the agreed period you should destroy the images. When an accident is reported you may need to retain a specific section of dashcam footage related to the accident or alleged accident whilst the claim is investigated, or if legal hold is required. You should then delete it after a suitable period when its no longer necessary.
You might need to carry out a Data Protection Impact Assessment. If you think the processing of personal data by your dashcams might potentially result in a high risk to individuals, you should conduct a DPIA.

If your vehicle fleet includes heavy goods vehicles (HGVs) of over 12 tonnes gross vehicle weight, which operate within the Greater London area, you should look ahead to complying with the forthcoming Direct Vision Standard.

This new safety standard was created to improve the safety of all road users, including pedestrians, cyclists and motorcyclists. Depending on your specific vehicles, you might be required to fit blind spot cameras which, like dashcams, is likely to capture images of people. The new standard is expected to come into force around 1 March 2021, at the earliest.

Meeting the data protection requirements for business use of dashcams doesn’t need to be onerous, but shouldn’t be overlooked.

RoPA – Five tips for keeping your Records of Processing Activity up to date

Simon BlanchardJuly 2020

One of the more onerous obligations under GDPR was the requirement for many organisations to maintain a Record of Processing Activities (RoPA). I stress the word ‘maintain’, as this isn’t a one-off exercise.

Even smaller organisations still have certain record keeping responsibilities, which should not be overlooked.

The specific requirements for record keeping are detailed and it’s an area many businesses have found challenging, especially keeping records up to date.

Here’s my quick 5-step guide to keeping your RoPA fresh and complete.

1. Why? – The need for ongoing updates

Keeping your records updated is really important. It’s a good idea to enlist the support of your Board as you’ll need help from all business function heads to tell you about their changes to processing, notify you of new data service providers and to keep the RoPA refreshed over time.

Failure to do so can lead to a loss of understanding about the true breadth of your processing, resulting in to uncertainty when you most need to refer to your records. After all, if you don’t know about certain processing or hold any record of it, how can you possibly help the business to protect that data?

For example, your RoPA should be the first place to look if you suffer a data breach, helping you to identify;

the categories of individual
sensitivity of the data
what it’s used for
who the data owners are
who it was shared with
what safeguards should have been in place to protect it… and so on.

It can also be helpful to reference your RoPA when handling individual rights requests.

If requested you might need to make your records available to the ICO, so you’d want to know they are in good shape. Getting behind, letting them get out of date makes the job of getting them back into order all the more difficult.

2. Who? – Is your list of data owners / stakeholders up to date?

Make sure you have a complete list of who is accountable for each of the personal data assets in your organisation? For example, employee & recruitment data, customer data, supplier data, financial data, etc. They need to understand their role in record keeping.

No DPO, or data protection team can do this on their own, they need the support of others.

3. What? – Make sure you’re capturing all the right information

Check you’re capturing all the RoPA requirements, which are slightly different if you act as a controller or processor (or both). If you need to check take look at the ICO’s guidance on documentation.

4. How? – Regular engagement with your stakeholders

Building a good two-way dialogue with your data owners & other stakeholders is essential not only for record keeping but many other data protection tasks. They will be close to coalface in terms of what data they have, what it’s used for and what measures they use to protect it.

5. When? – New processing

Have you updated records for all the new processing and changes to processing you’re aware of? You should be updating them whenever you identify new processing or changes to processing, including when you carry out a DPIA or LIA. Good stakeholder relations can really help you with this.

I hope this helps you with ways to keep your own records up to speed. I do find sharing the message about how helpful the RoPA can be if you suffer a data breach can motivate others to support you in this important task. Good luck!

If you need some practical advice in creating, maintaining or reviewing your Record of Processing Activities GET IN TOUCH

Data breaches: 10-point checklist for risk assessments

Philippa DonnJune 2020

What is it with airlines? An ever-growing list have suffered data breaches, the numbers affected are huge and class actions are underway. The risks these breaches pose for the thousands affected will clearly vary depending on the nature of the breach and the personal information involved.

This raises burning questions for others (thankful at this point it isn’t them in the spotlight), such as;

How do you assess the actual risk to people when a data breach happens?
When should you notify the ICO (or other relevant Data Protection Authority)?

The Information Commissioner’s Office (ICO) is not interested in hearing about every little incident, if it’s unlikely there’s any risk to people. In the early days of GDPR, the UK regulator clearly indicated there had been a degree of over-reporting. However, it’s a delicate balance, you don’t want to fail to report a data breach when you should have reported it.

How do you assess if a data breach is likely to represent a risk?

Each incident needs to be considered on a case by case basis, taking into account all relevant factors. No two incidents are likely to be the same (unless you failed to address something crucial the first time around).

Once you have established the facts (the what, when, who, how, where) and made sure the breach is still not ongoing, you then need to balance the severity of the potential impact on those affected with the likelihood of this occurring.

10 questions to ask when carrying out an assessment of risk from a data breach

Can individuals be identified? If so, how easily?
Does the breach involve information relating to children or vulnerable people?
Is / was the data easily accessible or would it require a degree of specialist knowledge to access it?
What kind of risks does the type of data involved pose? Often a combination of data such as an email address and password will pose more risk.
Even if the data appears to be fairly innocuous, could it be used maliciously to cause harm?
Is some or all the data already publicly accessible? Would people have wished their details like name and address to be kept private? (For example, the New Years honours list breach in which private home addresses were made public).
Are you aware the data is in the hands of someone or an organisation who could or intends to use it maliciously?
Is a high volume of records affected, meaning a high number of people could be impacted?
Does the breach reveal highly sensitive information (even for a low number of people) which could cause harm?
What is the nature of your business and does this impact on the severity and likelihood of damage being caused?

This is by no means an extensive list of questions, and the importance of certain questions will vary depending on the nature of your business and the nature of the incident you are assessing.

It is good practice to use a risk matrix, with a scoring system of likelihood against severity, so you can evaluate the level of risks identified. This provides evidence of how you went about your assessment. You will be looking for risks which could adversely affect individual, such as causing:

Physical harm
Financial loss
Identity theft/fraud
Psychological distress
Humiliation or reputational damage

It is useful to reference the European level Guidelines on Notification of a Personal Data Breach. In particular, Section IV provides helpful pointers on how to assess ‘risk’ and ‘high risk’.

If your breach involves special category data or financial details of individuals, the risks may be more obvious and the decision to notify or not will be more-clear cut.

The key to any assessment is that it needs to be fluid, including regular ‘check-ins’ with colleagues as your understanding of the situation evolves and answers to your questions are provided.

This has to be done super fast. If you judge that it is a breach that is notifiable to the ICO – it is likely to represent a risk to individuals – you need to report it within 72 hours of becoming aware. And you need to consider whether the risk is serious enough for you to also tell the individuals affected.

Because you have to act so quickly, the benefit of having a robust plan and assessment process in place can’t be underestimated.

Your people can be your biggest asset or risk with data, so it also pays to make sure your staff understand the risks which can arise when handling data, the role they play in protecting data from a breach and what they must do if they suspect one may have occurred.