GDPR: Our own journey to compliance – Part 2


whiteboard data flow compressed


Jackie Auld

6th September 2017


You may remember from my first blog in this new series, which charts Northumberland CVA’s journey towards GDPR compliance, that we’d initially identified two equally important action points: carrying out an information audit and bringing our consent requests and privacy notices up to scratch to comply with the new legislation, so here’s a quick update:

  • Consent requests and privacy notices: New compliant versions have now been prepared for paper forms and webpages but are not yet all in place. We have de-activated our online application form for the VCS Assembly and a compliant downloadable form will very soon be in place. We have been very careful to ensure that the information is written in clear and plain language and that it covers everything it should, including the rights of the individual data subject and how they can exercise them easily (
  • Information audit: We’ve updated our retention policy and applied it to the personal data we currently hold. All of our staff members – including myself – are now working towards a deadline to delete or otherwise destroy any out of date or unnecessary personal data they have amassed in both electronic and paper files. Everything that has been deemed necessary to retain, in the interests of delivering our current work, will form part of our next step in the process, conducting the Privacy Impact Assessment (PIA).

Conducting a PIA is a process which helps an organisation to identify and reduce the privacy risks of a project and forms part of the Privacy by Design approach stipulated by the GDPR. Ideally, a PIA should be carried out at the very beginning of any project but if this has not happened, then it can still be done when a project is up and running. The Information Commissioner’s website has a useful document: ‘Conducting Privacy Impact Assessments Code of Practice’, which they say is unlikely to change under the GDPR. In the ICO’s initial document: ‘Preparing for the GDPR: 12 Steps to Take Now’ (now updated), the PIA is covered in Step 10.

As for Steps 1-9, we are continuing to raise awareness (Step 1) through our e-bulletin and through this blog, as well as in staff and trustee meetings. We have now carried out an Information Audit (Step 2) and we are in the process of covering Steps 3, 4 and 7 in our consent requests and privacy notices, although we haven’t yet touched on Step 5, which covers Subject Access requests. We’ve decided to leave that to one side for the moment, along with Step 9 (Data Breaches) to concentrate on once we’ve done our PIA. Since we do not work directly with children, Step 8 is also not a priority at this point. Step 6 is all about identifying and documenting the lawful basis for your processing activity, which we’ll be covering as part of the PIA, although we have already touched on this in our work on consent requests and privacy notices.

The majority of information and guidance on GDPR available to this point has been around the issue of consent, but this is only one of the six lawful bases for processing under the GDPR. Another basis that could be very relevant to the voluntary and community sector is that of ‘Necessary for the purposes of legitimate interests pursued by the controller or a third party’, and whilst official guidance will not be available until well into the New Year, as the Information Commissioner, Elizabeth Denham says, “there is already guidance about legitimate interests under the current law on the ICO website and from the Article 29 Working Party” that is unlikely to change significantly. It’s important to remember though that you cannot apply legitimate interests “where such interests are overridden by the interests, rights or freedoms of the data subject”.

Depending on the sort of work you do, there may be other lawful bases you can apply. For instance, ‘Processing is necessary for compliance with a legal obligation’ is likely to apply when it comes to dealing with HMRC and to comply with employment or safeguarding law etc. And you may use the basis: ‘Processing is necessary for the performance of a contract with the data subject or to take steps to enter into a contract’ if you are taking payment for goods or services or perhaps to cover membership activities – we are exploring this now for our own memberships.

The one big thing you do need to remember though is that, whilst you may rely on ‘legitimate interests’, ‘legal obligation’ or ‘performance of a contract’ as the bases for gathering and processing information in the first place, you would not necessarily then be able to rely on the same bases for any additional processing you might want to carry out for purposes such as sending out e-bulletins, invitations to events, combining datasets etc. To cover such additional activities you would need to obtain separate consent.

So, back to the PIA: there is no legal requirement to carry out a Privacy Impact Assessment unless processing is “likely to result in a high riskalthough in draft guidance the GDPR Article 29 Working Party has recommended that, if in doubt: carry one out.

I can’t think of a VCS organisation in Northumberland that routinely carries out high risk activities as specified in the draft guidance, for example: “systematic and extensive evaluation of personal aspects relating to natural persons, based on automated processing” or “systematic monitoring of a publicly accessible area on a large scale”, although perhaps one or two of you do. And in fact, the WP suggests that even employee monitoring should be subject to a DPIA because it involves systematic monitoring and a vulnerable group (in that there can never be a balance of power in the relationship between the employer and the employee). So if your work includes the matching and combining of datasets, if you work with vulnerable individuals, or you process data which has the effect of refusing people access to a contract or service, then you really do need to cover your work with a PIA, which in GDPR-speak is referred to as a ‘DPIA (Data Protection Impact Assessment)’.

According to the Article 29 WP, a DPIA should be carried out at an early enough stage in a project that recommendations can be acted on, and should then be continuously reviewed. The ‘data controller’ (i.e. your organisation) is ultimately responsible, although it could seek external assistance. A ‘data processor’ may be required to help if it is largely responsible for the processing (This could be any third party processor for your data, and not only the third party fundraisers that have been all over the news). Although not every organisation needs to appoint a ‘Data Protection Officer (DPO)’, if you have one he/she must be involved in this process and must monitor performance of the DPIA (Find out whether your organisation needs to appoint a Data Protection Officer). Also, where appropriate’ the controller should seek the views of ‘data subjects’ (the individuals whose personal data you are processing) by means of a survey or study etc. If you decide not to seek their views, you should document your decision and your reasons for it as part of your DPIA.

Step 1 in carrying out a PIA, according to the ICO guidance under existing legislation, is to identify the need for one. Helpfully, in Annex one of ‘Conducting Privacy Impact Assessments Code of Practice’, the ICO provides a list of screening questions that can help you decide whether a PIA is necessary, which along with a very simple template for carrying out your PIA is available to download in an editable format.

Step 2 asks you to “describe information flows” (PIA) or “describe the processing” (DPIA), which essentially mean the same thing. To do this, you need to explain how the information will be obtained, used and retained. As the PIA Code of Practice explains on pages 12 & 13, this can help you identify and put measures in place to tackle any potential for what they call ‘function creep’ i.e.: any possible unforeseen or unintended uses of the data.

Whilst researching ways other organisations describe information flows, I came across lots of examples of data flow diagrams and I think this is a great method for helping your team and other stakeholders visualise what happens to personal data within your organisation in order to identify where a breach may occur and the best measures to lower the risks involved. According to Wikipedia, “a data flow diagram (DFD) is a graphical representation of the ‘flow’ of data through an information system, modelling its process aspects.”

You can make your diagram as simple or as complicated as you like. You don’t need specialist design skills to create it. Google the term ‘data flow diagram’ and click on ‘images’ to see reams and reams of examples. If you have access to tools like PRINCE2 or Agile software you can use them to create your diagrams. Alternatively, you could use the SmartArt Graphics available in Microsoft programs, or you could simply use pen and paper. The important thing is that you identify every point in your organisation at which a form of processing takes place on the personal data you gather and store as a part of your work.

If the work of your organisation has only one or two strands, it needn’t take a huge amount of time to map your data flows. However, Northumberland CVA has a multitude of different projects and themes of work as well as our core activities and I have found it to be much simpler, in terms of creating a clear visual aid, to tackle each theme/project separately. That means lots of diagrams. At this point in time, I’ve completed three out of a possible six.

Prior to Step 3 you need to think about consultation and the steps you will take to ensure you identify and address any privacy risks. You need to list who is/was involved both internally and externally, and how you will carry out or have carried out your consultation. You can link this to any wider project management processes if you have them. If you’re doing your PIA/DPIA as part of the planning process for a brand new project, you would most likely be carrying out some form of consultation anyway and data protection could easily become part of that. At Northumberland CVA, since our PIAs concerns projects that have been in operation for some time, we are consulting internally at present but will look at carrying out external consultation if and when it becomes necessary.  

Step 3: This is where you list the processing points you have identified in your DFDs and set about identifying the key privacy risks and any associated compliance and corporate risks. An Excel spreadsheet is ideal for this purpose (Quick tip: this is much easier to do, and for others to follow, if you remember to number each processing point on your diagram first).

Step 4 is where you identify and describe any actions you take already or plan to adopt as solutions to reduce the risk of a data breach and this can simply become another column in your spreadsheet, like so:


NCVA Personal Data Flow Risk Chartxx


You’ll notice that I’ve also added columns for identifying the legal basis for processing, for recording who it is who has approved the solutions and the date they have done so. You can format your spreadsheet any way you like. You may find it useful to do what we are doing in colour coding your risk level as red/amber/green for high/medium/low. You may choose to make your spreadsheet simpler than this and perhaps use the editable template in Annex one of ‘Conducting Privacy Impact Assessments Code of Practice’. That’s absolutely fine. We’re completing a separate spreadsheet for each data flow diagram.

Step 5 of your PIA/DPIA is about signing off and recording your PIA outcomes and Step 6 is about integrating them back into your project plan and processes. We haven’t got that far yet, but we’re getting there.

All of these steps follow those listed in Annexes one and two of ‘Conducting Privacy Impact Assessments Code of Practice’. The guidance on conducting a DPIA under the GDPR is not yet set in stone, but is likely to be broadly the same. For many organisations this a huge piece of work and so it makes sense to get as far as we can using the existing guidance so that any changes that do need to be made closer to the deadline of May 25th 2018, if any, are likely just to mean small tweaks here and there.

This is what I’m going to be working on for quite some weeks yet I think. Once finished, we’ll have a detailed data flow diagram for each aspect of our work, accompanied by a separate spreadsheet for each one. But not every organisation will need to split its work up like that. Whatever you decide, do make sure you consider every single point at which you process data. I’ve discovered that carrying out a PIA is a great way to put your processes under the microscope and hunt out every piece of outdated data and every unnecessary and soon to become unlawful processing activity.

I’ll update you on our progress in our next GDPR blog. Please do share your own progress towards GDPR compliance; simply email This email address is being protected from spambots. You need JavaScript enabled to view it., or call me on 01670 858688.

If you’d like to keep up to date with any new developments on GDPR, visit the ICO webpages: