Data protection by design and default – what does that mean really? It’s an obligation in GDPR, but it can still be confusing to get to the heart of what ‘data protection by design and default’ really means, and what you need to do as a result. It’s often used as a proxy for ‘do a DPIA’ but it’s so much more than that. I’ve seen it described as building or baking in data protection from the start. That’s more accurate but still leaves the question “yes but what does that actually mean?” What does GDPR say? It helps to go back to the source, not just article 25 GDPR (1) and (2) but also recital 78. These tell you what the legislators were concerned about, namely implementing the principles. They specifically call out the following. Data minimisation Purpose limitation Retention Wide disclosure / accessibility of the data Transparency Making sure individuals know what’s going on Allowing organisations to set up and improve security measures. Both the article and the recital mention pseudonymisation as one way to implement the data minimisation principle. It’s an example though, not a mandatory requirement. The end of recital 78 seems to be directed at those producing software and systems, as well as public tender processes. My take on this is that the legislators were keen to make sure that organisations needing to comply with GDPR didn’t fall at the first hurdle due to a lack of thought for data protection compliance in systems and software. Their expectation is clear for those designing these things for organisations, and I think their hope was that it would lead to software and systems producers having to raise their game to stay competitive. How to put data protection by design and default into practice To put this obligation into practice, people often jump to PETs (privacy-enhancing technologies, not Charlie the golden retriever). There have been loads of studies, reports and articles on a range of specific technical measures, too much to go into here. In reality, and in my experience, these more sophisticated methods and third-party software solutions tend to only be available to those with deep pockets and an internal tech team. The reality for many organisations is to embed DP compliance into processes and policies. When I work with clients on this, I tend to start by looking at how things get done in their organisation. How do you go from “I’ve had a great idea” to “it’s gone live today”? Where are the gatekeepers and / or the decision makers for ideas and projects? How do you manage and record the different steps, phases or tasks needed? How do you identify who needs to be involved, and then involve them? Once you understand the process and who’s involved, look at what already exists. Many organisations use certain tools to project manage, to assign tasks to people, to report and manage bugs or other issues and so on. Many organisations already have a form or process to suggest ideas, ask for approvals, and to get items on the to do list. I have found an effective approach is to build on what is already there. No-one will thank you for introducing a new 4-page form on data protection stuff. No-one will fill it in. Where are the points in the processes, or on the forms, or in the tool template to add the DP stuff? Can you add in questions, checklists, templates, approval points and the like? Examples of data protection by design and default solutions Speaking of checklists and templates, one of the most effective DP by design ‘solutions’ was where the organisation created a ‘standard build template’ that incorporated key DP principles. So anytime anything needed building or expanding, the build requirements already included things like specific security measures, elements of data minimisation and controls for the end users. With another organisation there was a two-part solution. One part was for those developing the idea and deciding on the data collection. This involved adapting their project documentation to include key elements from a DPIA and a way to check each data field requested was actually necessary, as well as identify where it might be sensitive or need greater care. The other part was a checklist for those implementing the new thing that set out some core requirements such as the ability for the end user to take certain actions with their data, and what settings or controls had to be off by default. This approach also encouraged better communication between the two groups, as they worked together on which solutions would best implement the core requirements. Think of the people Getting to a practical implementation of DP by design and default involves taking a people-centred approach. Both in terms of collaborating with the relevant people internally, as well as thinking about impacts on and risks to the individuals whose personal data you are doing things with. You also need to consider your organisation’s position on DP compliance. The law might want everyone to do the gold standard, but that’s not the reality we live in. How far you go in implementing DP by design and what your measures look like will be influenced by things like your organisation’s risk appetite, their approach to risk management, any relevant vision or principles they have, or any frameworks or internal committees in place covering compliance, ethics, and so on. Your colleagues can also be a great asset. Your business development people will have information on what corporate customers are asking for, your end user support people will have intel on what the users complain about. How far do these overlap and where do they conflict? For example, I have seen the same transparency issue in multiple organisations where both corporate customers and end users want to understand how the product or software works. The corporate customers need to do compliance diligence, and the end users want to know if they can trust the organisation with their data. Producing something for both audiences on how it all works not only helps implement the transparency point of article 25, it also checks if different parts of the organisation have the same understanding of how it works, and flags up discrepancies. Sometimes, doing something because it leads to a good consumer experience or higher levels of satisfaction gets you to the right place, and can be an easier sell than labelling it a ‘DP compliance requirement’. Some organisations have the resources to do user research and surveys, and the results of these can be very useful to the DP people. If you can work with and understand the objectives and the pain points of colleagues (such as those managing infrastructure, information security, compliance, risk management, customer support and even the executive team), you’ll be in a good place to see where you slide in your DP stuff, and piggyback on other initiatives. This is one area of GDPR that takes an outcome-based approach. And the joy that is that it is scalable and adaptable to each situation, and to each organisation’s resources and capabilities. So by focusing on the required outcomes, and putting people at the centre, achieving data protection by design and default can be a lot easier than it first appears.

Data Governance Quick Guide Taking control of our data In essence Data governance is a framework of management practices which makes sure data is used properly in line with our organisational aims, the law and best practice. Think of it as embedding Data Protection by Design and by Default across the organisation. It means business objectives can be met without taking unnecessary risks with data. Data governance helps us to: protect the business and those whose data we process: customers, employees, etc. reduce our organisational risk profile educate our people, by providing policy & guidance to them on how to use data in the safe and appropriate ways build in an ethical approach build our reputation, customer trust and enhance the value of our data assets support our teams’ innovation with use of data. The 6 data governance steps 1. Data discovery It’s vital to identify data assets held across the business understanding how personal data is being gathered, stored, used and shared. It can be helpful to map where the data is located on systems, and document it. Most medium to large businesses will need to do this anyway to create and maintain an Information Asset Register (IAR) and Records of Processing Activity (RoPA). 2. Policies & standards If our people don’t know how we expect them to behave when handling other people’s data, we can’t expect them to make a great job of it. Are your policies and procedures all up to scratch? Having a straight-forward, easy to understand and practical Data Protection Policy is a good place to start (alongside relevant training). The importance of well-crafted easy to use policies shouldn’t be underestimated. 3. Stakeholder accountability We need to identify key stakeholders within the business. Likely to be heads of key functions, such as HR, Operations, Sales & Marketing, and so on. It’s good to establish data roles and responsibilities, so people are clear what aspects they and others are responsible for. Who has the authority to make decisions about certain data? 4. Risk assessment process Businesses should have risk assessment procedures to discover, assess, prioritise and take action to mitigate data risks. A governance programme helps teams to identify and assess both existing and emerging risks, so they can be efficiently assessed and mitigated. Think of data like a balance sheet: it has great potential to create value, but also carries risks and liabilities. The aim of a data governance programme is to protect both the business and those whose data we process from harm which may arise. For example, things like inaccurate data, unlawful or unfair processing or using people’s data in ways they would not expect or want. For certain projects it will be necessary to conduct a Data Protection Impact Assessment (DPIA). 5. Technical and organisational measures (TOMs) Once privacy risks have been identified, we need to consider what measures could be put in place to tackle them. You may choose to mitigate them internally with new procedures or security measures, or perhaps work with a third party to adopt technical or operational measures. Privacy Enhancing Technologies – how they can help Organisational measures include making sure there’s good awareness about data protection across the business, and employees receive appropriate training. 6. Executive oversight Risks should be reported up the line to make sure the Senior leadership team has proper oversight and the opportunity to take appropriate action. If your organisation has a Data Protection Officer (DPO) this reporting will be part of the formal accountabilities for their role. But remember not all businesses need to have a DPO. Should we appoint a DPO? Overcoming cultural challenges Data protection and privacy professionals face a cultural challenge to win hearts and minds. I have sometimes heard legal or privacy teams described as ‘the department of no’. That’s not how we want to be seen! Smart businesses are realising the value of taking privacy seriously. We should help our business colleagues to balance the needs of commercial and operational functions with legal & ethical requirements. We shouldn’t just explain what the law requires. We must go further and help them our colleagues to find practical solutions. Collaboration and mutual understanding are essential ingredients for successful data governance.

Are we conducting too many DPIAs – or not enough? How to decide when to conduct Data Protection Impact Assessments Make no mistake, Data Protection Impact Assessments (DPIAs) are a really useful risk management tool. They help organisations to identify likely data protection risks before they materialise, so corrective action can be taken. Protecting your customers, staff and the interests of the business. DPIAs are key element of the GDPR’s focus on accountability and Data Protection by Design. It’s not easy working out when a DPIA is necessary, or when it might be useful, even if not strictly required by law. Businesses need to be in control of their exposure to risk, but don’t want to burden their teams with unnecessary work. So it falls to privacy professionals to use their judgement in what can be a delicate balancing act. Lack of clarity around when DPIAs are genuinely needed could lead businesses to carry out far more DPIAs than needed – whilst others may carry out too few. When are DPIAs required? We should check if a DPIA is required during the planning stage of new projects, or when changes are being planned to existing activity. Where needed, DPIAs must be conducted BEFORE the new processing begins. DPIAs are considered legally necessary when the processing of personal data is likely to involve a ‘high risk’ to the rights and freedoms of individuals. What does ‘high risk’ look like? Why types of activity might fall into ‘high risk’ isn’t always clear. Fortunately the ICO have given examples of processing likely to result in high risk to help you make this call. Regulated sectors, such as financial services and telecoms, have specific regulatory risks to consider too. Give consideration to the scope, types of data used and the manner of processing. It’s wise to also take account of any protective measures already in place. In situations where the nature, scope, context and purposes of processing are very similar to another activity, where a DPIA has already been carried out, you may not need to conduct another. Three key steps for a robust DPIA screening process 1. Engage your key teams In larger organisations, building good relationships with key teams such as Procurement, IT, Project Management, Legal and Information Security can really help. They might hear about projects involving personal data before you do. Make sure they’re aware when a DPIA may be required. This means they’ll be more likely to ‘raise a hand’ and let you know when a project which might require a DPIA comes across their desk. In smaller businesses there may still be others who can help ‘raise a hand’ and let you know about relevant projects. Work out who those people are. 2. Confirm the businesses appetite for risk Is your organisation the sort which only wants DPIAs to be carried out when strictly required by law? Or perhaps you want a greater level of oversight? Choosing to carry out DPIAs as your standard risk assessment methodology for any significant projects involving personal data – even if they might appear to involve lower levels of risks to individuals. Logic says you’ll never be 100% sure unless you carry out an assessment and DPIAs are a tried and tested way to give you oversight and confidence. But this approach requires more time, resources and commitment from the business. You need to strike the right balance for your organisation. 3. Adopt a DPIA screening process If you don’t currently use a screening process, you really should consider adopting one. It’s a quick and methodical way to identify if a project does or does not require a DPIA. You can use a short set of standard questions, which can be provided for stakeholders to complete and return or discussed in a call. So the question ‘Is a DPIA needed or not?’ can be reached rapidly and with confidence. Personally I prefer to arrange a short call with the stakeholders, using my screening questionnaire as a prompt to guide the discussion. Don’t forget to keep a record of your decisions! Including when you decide a DPIA isn’t necessary. Try not to burden colleagues with unnecessary assessments for every project, if there really is minimal risk. This is unlikely to be a well-received approach. Raise awareness and have a built-in DPIA screening process to make sure you catch the projects which really do warrant a deeper dive.  

Body worn cameras and privacy implications Is your use of body worn cameras reasonable and proportionate? Wearable technologies such as body worn cameras (‘bodycams’) and other recording devices are often used for public safety and security purposes. An obvious example is by the Police and other public services. They can also used for recreational pursuits. The use of these devices has increased significantly over recent years as the technology advances in leaps and bounds, and prices fall. Bodycams can pose a real challenge from a data protection perspective due to their portability. When a bodycam is in use, it effectively becomes a mobile surveillance system which is highly likely to capture images or audio of individuals. This should be regarded as personal data. Businesses using these devices need to be mindful of relevant data protection requirements. We need to bear in mind, when bodycams are combined with the use of facial recognition technology to uniquely identify individuals (e.g. for safety and security purposes), the data protection concerns increase. If you are actively processing special category data, such as biometric data used within facial recognition systems, you need to identify a suitable condition under Article  9, UK GDPR. Eight key privacy principles and obligations for bodycams Fair and lawful processing – you must be able to demonstrate your use of bodycams is both fair and legal. The necessity must be carefully considered. The potential for bodycams to be intrusive means meeting a relatively high threshold to demonstrate your use is genuinely necessary. Limited purposes & data minimisation – cameras should only record the minimum amount of personal information necessary for specified purposes. Transparency – did you clearly tell people before you began recording? Are they aware of their rights? Information security – Any recordings must be stored securely. If video footage is stored on the device itself, or on a memory stick (even temporarily) there’s an additional risk of loss or theft of personal data. Restricted access – clearly defined rules should be in place covering who can access recordings and for what purposes. Sharing – the disclosure of images and information should only take place when it’s necessary for specified purposes, or for law enforcement. And checks should be in place before disclosing to law enforcement or other agencies. Storage limitation – data on individuals (including video & audio) must be retained only for the minimum amount of time required, and then deleted. Individual rights – you must be able to respond appropriately to any privacy rights requests from individuals (such as the right of access or right to erasure). Carrying out an impact assessment In most situations it would be wise to conduct a Data Protection Impact Assessment (DPIA) to formally assess and document your approach and how you will meet the data protection obligations. The DPIA will need to consider each of the relevant principles and evaluate if measures and controls in place are adequate to protect individuals whose personal data may be captured. Other considerations The ICO published ‘Guidance on video surveillance’ earlier in 2022. This covers the processing of personal data by video surveillance systems by both public and private sector organisations. Their scope for surveillance systems includes CCTV, ANPR, bodycams, drones (UAVs), facial recognition technology (FRT), and also dashcams and smart doorbell cameras. They pick up on many of the points I’ve summarised above. The Biometrics and Surveillance Camera Commissioner published a draft update to its ‘Surveillance camera code of practice’ in August 2021, which is still out for consultation. The draft code includes twelve guiding principles for surveillance system operators however, as you may anticipate, many of these overlap with the privacy principles I’ve picked out above. I’ve highlighted some other areas covered in this draft code: There must be clear responsibility and accountability for all surveillance camera system activities including images and information collected, held and used. Clear rules, policies and procedures must be in place before a surveillance camera system is used, and these must be communicated to all who need to comply with them. Surveillance camera system operators should consider any approved operational, technical and competency standards relevant to a system and its purpose and work to meet and maintain those standards. There should be effective review and audit mechanisms to ensure legal requirements, policies and standards are complied with in practice, and regular reports should be published. When the use of a surveillance camera system is in pursuit of a legitimate aim, and there’s a pressing need for its use, it should then be used in the most effective way to support public safety and law enforcement with the aim of processing images and information of evidential value. Any information used to support a surveillance camera system which compares against a reference database for matching purposes (for example, ANPR or facial recognition) should be accurate and kept up to date. I hope you found this article useful. If you’d like to know more please just drop us a line and arrange a chat.

Ransomware attack leads to £98k ICO fine Solicitors firm failed to implement ‘adequate technical and organisational measures’ Are you using Multi-Factor Authentication? Are patch updates installed promptly? Do you encrypt sensitive data? Reports of cyber security incidents in the UK rose 20% in the last 6 months of 2021. These figures from the ICO, combined with the heightened threat in the current climate, provide a stark warning to be alert. The ICO says; “The attacks are becoming increasingly damaging and this trend is likely to continue. Malicious and criminal actors are finding new ways to pressure organisations to pay.” Against this backdrop the ICO has issued a fine to Solicitors’ firm following a ransomware attack in 2020. The organisation affected was Tuckers Solicitors LLP (“Tuckers”) which is described on its website as the UK’s leading criminal defence lawyers, specialising in criminal law, civil liberties and regulatory proceedings. While each organisation will face varying risks, this case highlights some important points for us all. Here’s a summary of what happened, the key findings and the steps we can all take. For increasing numbers of organisations this case will unfortunately sound all too familiar. What happened? On 24 August 2020 Tuckers realised parts of its IT system had become unavailable. Shortly after IT discovered a ransomware note. Within 24 hours it was established the incident was a personal data breach and it was reported to the ICO. The attacker, once inside Tuckers’ network, installed various tools which allowed for the creation of a user account. This account was used to encrypt a significant volume of data on an archive server within the network. The attack led to the encryption of more than 900,000 files of which over 24,000 related to ‘court bundles’. 60 of these bundles were exfiltrated by the attacker and released on the ‘dark web’. These compromised files included both personal data and special category data. The attacker’s actions impacted on the archive server and backups. Processing on other services and systems were not affected. By 7 September 2020, Tuckers updated the ICO to say the servers had been moved to a new environment and the business was operating as normal. The compromised data was effectively permanently lost, however material was still available in management system unaffected by the attack. Tuckers notified all but seven of the parties identifiable within the 60 court bundles which had been released, who they did not have contact details for. Neither Tuckers, nor third party investigators, were able to determine conclusively how the attacker was able to access the network in the first place. However, evidence was found of a known system vulnerability which could have been used to either access the network or further exploit areas of Tuckers once in side the network. What data was exfiltrated? The data released on the ‘dark web’ included: Basic identifiers Health data Economic and financial data Criminal convictions Data revealing racial or ethnic origin This included medical files, witness statements and alleged crimes. It also related to ongoing criminal court and civil proceedings. Tuckers explained to the Regulator, based on its understanding, the personal data breach had not had any impact on the conduct or outcome of relevant proceedings. However, the highly sensitive nature of the data involved increased the risk and potential adverse impact on those affected. Four key takeaways The ICO makes it clear in its enforcement notice that primary culpability for the incident rests with the attacker. But clear infringements by Tuckers were found. The Regulator says a lack of sufficient technical and organisation measures gave the attacker a weakness to exploit. Takeaways from this case: 1) Multi-Factor Authentication (MFA) Tuckers’ GDPR and Data Protection Policy required two-factor authentication, where available. It was found that Multi-Factor Authentication (MFA) was not used for its ‘remote access solution’. The ICO says the use of MFA is a relatively low-cost preventative measure which Tuckers should have implemented. The Regulator concluded the lack of MFA created a substantial risk of personal data on Tuckers’ systems being exposed to consequences such as this attack. Takeaway: If you currently don’t use MFA, now would be a good time to implement it. 2) Patch management The case reveals a high-risk security patch was installed in June 2020, more than FOUR months after its release. The ICO accepts the attacker could have exploited this vulnerability during the un-patched period. Considering the highly sensitive nature of the personal data Tuckers were handling, the Regulator concludes they should not have been doing so in an infrastructure containing known critical vulnerabilities. In other words the patch should have been installed much sooner. Takeaway: Make sure patches are installed promptly, especially where data is sensitive. 3) Encryption During the investigation Tuckers informed the ICO the firm had not used encryption to protect data on the affected archived server. While the Regulator accepts this may not have prevented the ransomware attack itself, it believes it would have mitigated some of the risks posed to the affected individuals. Takeaway: There are free, open-source encryption solutions are available. Alternatively more sophisticated paid for solutions are available for those handling more sensitive data. Also it’s worth checking you’re adequately protecting archives to the same standard as other systems. 4) Retention The enforcement notice reveals some ‘court bundles’ affected in the attack were being stored beyond the set 7-year retention period. Takeaway: This again exposes a common issue for many organisations. Too often data is held longer than is necessary, which can increase the scale & impact of a data breach. Our comprehensive Data Retention Guidance is packed with useful tools, templates and advice on tackling how long you keep personal data for. What else can organisations do? Clearly, we can’t be complacent and shouldn’t cut corners. We need to take all appropriate steps to protect personal data and avoid common pitfalls. Here are some useful resources to help you: Cyber Essentials – The enforcement action notes that prior to the attack Tuckers was aware its security was not at the level of the NCSC Cyber Essentials. In October 2019, it was assessed against the ‘Cyber Essentials’ criteria and failed to meet crucial aspects of its requirements. Cyber Essentials was launched in 2014 and is an information security assurance scheme operated by the National Cyber Security Centre. It helps to make sure you have the basis controls in place to protect networks/systems from threats. Cyber Essentials – gain peace of mind with your information security National Cyber Security Centre ICO Ransomware guidance – The ICO has recently published guidance which covers security policies, access controls, vulnerability management, detection capabilities and much more. DPN Data Breach Guide – Our practical guide covers how to be prepared, how to assess the risk and how to decide whether a breach should be reported or not. You can read the full details of this case here: ICO Enforcement Action – Tuckers Solicitors LLP

Data Breach Guide How to handle a data breach Our practical, easy-to-read guide takes you through how to be prepared for a breach, and how to assess the risks should you suffer a personal data breach. This data breach guide covers: Common causes of breaches Data incident and breach planning How to assess the risks Breach reporting checklists How technology can help

Data Protection by Design: Part 3 – Data Protection Impact Assessments 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 1 – The Basics Data Protection by Design and by Default – What does it mean?  You might hear the terms ‘privacy by design’ and ‘data protection by design and by default’ being used when discussing data protection. We’re frequently told to think privacy first, by considering data protection at the outset of any project and embedding it into policies and processes. That’s all very well, but what does ‘Data Protection by Design’ really mean (and why is it also called ‘Privacy by Design’)? Do you need to be concerned about it? And how do you approach it in practice? When you delve into the detail, this stuff quickly becomes complex. I’m going to try and avoid ‘privacy speak’ and jargon as much as I can and give an overview of how it all started and where we are now. What is Privacy/Data Protection by Design? Data Protection by Design (and also ‘by Default’) are terms ushered in by GDPR. But the concept’s not new; the roots lie in Privacy by Design which has been around for some time. The brains behind Privacy by Design is Ann Cavoukian (a former Information and Privacy Commissioner for the Canadian province of Ontario). The concept was officially recognised as an essential component of fundamental privacy protection in 2010. Cavoukian’s approach led to a new way of integrating privacy into products, business processes and policies. At its core it’s all about incorporating privacy measures at the design stage of a project or policy, rather than bolting them on afterwards. The basis of this approach is to allow businesses to protect data and privacy without compromising commercial effectiveness right from Day One. I’m sure practitioners in other fields, for example Health and Safety or HR, will be familiar with this approach too. Privacy by Design is based on seven principles designed to embed privacy into a project’s lifecycle. For more detail take a look at the IAPP’s Privacy by Design the foundational principles. Fast forward to GDPR… In the past, Privacy by Design was considered a great approach to take and adopted by many businesses worldwide – but it wasn’t mandatory. What’s different now is GDPR has made it a legal requirement. GDPR also gave us the new term Data Protection by Design and by Default. This means organisations who fall under the scope of GDPR are obliged to put appropriate technical and organisational measures in place. These are commonly referred to as TOMs. ICO guidance explains why, ‘businesses have a general obligation to implement appropriate technical and organisational measures to show that you have considered and integrated the principles of data protection into your processing activities.’ You need to make sure data protection principles, such as data minimisation and purpose limitation, are implemented effectively from the start. Crucially, such measures also need to focus on protecting people’s privacy rights. The ICO has produced detailed guidance on the topic, to help you navigate how to consider data protection and privacy issues at the start of your projects, products and processes. As an aside, this doesn’t mean everything grinding to a halt, claiming ‘I can’t do that because of GDPR’! The more familiar you become with the basic principles, the easier it is to explain and incorporate them into your business. That’s not to say it’s always a piece of cake – sometimes it isn’t – but neither does it have to be the ball and chain some make it out to be. Do you need to worry about this stuff? There’s a short answer to this question – Yes! It’s a legal requirement under GDPR, albeit some organisations will take this very seriously and others will take a laxer approach. How to make a start This is a topic that can feel overwhelming to begin with. It’s common to think, “how on earth do I get everyone across our business to think about data protection and consider people’s privacy in everything we do?” Here are a few tips on organisational measures; Benefits – think about how this approach is good for business and for your employees. It’s not just about trying to avoid data breaches, it’s about being trustworthy, taking care about how you handle and use people’s information. Privacy can be a brand asset; it can save costs and improve the bottom line. Increasingly organisations want to work with partners who can demonstrate sound privacy credentials. In many instances some of the most sensitive data your handle will be that of your employees. You all have an interest in making sure you handle everyone’s personal data in a secure and private way. Collaborate with InfoSec – The two disciplines of privacy and security are intrinsically linked. Businesses are most successful at protecting personal data when the Info Sec and Data Protection teams are joined up, working in tandem. Innovation – gone are the days when data protection was the place where dreams went to die! Sure, there are checks and balances that need to be considered when a great idea has privacy risks. When this happens, it’s up to the data protection team to be as innovative as their colleagues in helping that idea flourish. You never know – your approach to privacy can add value to a project, not diminish its effectiveness. Awareness – think about fresh ways to get the message across – data protection matters. This is a balancing act, because we wouldn’t want to scare people to the extent they worry about the slightest thing. Try to explain that once data protection principles are embedded, much of it is common sense. DPIAs – data protection impact assessments are one of the most important tools in your data protection by design toolbox (you don’t have one?). DPIAs are like a fire alarm – are your developers busy creating the most fabulous app ever? The DPIA should alert them to issues which, if ignored, might be project-breaking to fix later. As an aside, many DPIA templates I’ve seen are unduly complex and impossible for most staff to even attempt. So, try and make this an easier process – jettison the jargon and ask straight-forward questions. Data Governance – I apologise, this really is the dreariest of terms. Nonetheless, it’s seriously worth developing a governance framework across your business which sets out who is responsible, who is accountable for your data and how the data is used. It can help to make sure processes and policies are robust and kept up to date. Training – there’s nothing more empowering than effective training; making sure your people understand data protection principles, what privacy risks might look like and understand how it’s relevant to their job. Once this stuff is explained simply and effectively, it’s amazing how quickly this falls into place. There’s an old saying: “What’s the best way to eat an entire elephant?” The answer is, “by breaking it into pieces first.” You know your business – all you need to do now is break down the data protection stuff into manageable chunks as you apply them to your projects. The first couple might be tricky, but after that? There’s no substitute for getting stuck in and applying the principles to real-world problems. And the good news is there’s plenty of advice, training, templates and guidance available.