IGO Guidance notes for completing the DPIA2 1) Benefits of

DPIA 2 Form – Version 1

1

IGO Guidance notes for completing the DPIA2

1) Benefits of doing a DPIA2: If you are doing a DPIA 2 it is because the new process / system / capability is likely to include some ‘high risk’ processing of personal data and therefore a DPIA2 assessment of data protection compliance is required under the Data Protection Act 2018 and GDPR. So sometimes we have to do one but why is it so important? The whole aim of the DPIA process is to help ensure that any new IT systems / capabilities or significant business process changes will use personal data in a compliant and lawful way. The DPIA2 process includes an assessment on the initiative early on in the project to identify if any changes that need to be made to the way people or systems use personal data. In most DPIA2’s there will be a data protection compliance shortfall and you will plug this gap by agreeing mitigating actions with the Project Manager (PM). IGO’s must track any agreed actions with the PM as the project continues to ensure they are all completed by the necessary deadline and before the ‘go live’ date. The successful tracking of action completion is critical otherwise the DPIA has been ineffective as the new process / system / capability will still not be data protection compliant. Therefore the timing of starting and signing off the DPIA2 form is equally important as it should be early enough for any mitigating actions to be put into place. Completing the DPIA2 form after the project has gone live will nearly always be too late to have any effect. Each project will be different and so you will need to discuss timings and deadlines for DPIA2 completion with the PM.

2) Timeliness: Because the DPIA2 Process can take a number of weeks to complete we will aim to meet the following targets for timeliness. Once it is confirmed a DPIA2 is needed and is now due: ** IGMs – you will need to agree what you want these target timeframes to be and tweak below

Within 1 week: to book (not hold) a DPIA2 meeting in the diary and have issued the DPIA questionnaire (if you are going to use it).

Within 2-3 weeks: to hold the first / main DPIA2 meeting with the PM (and anyone else they need to bring).

Within 1 month from the first DPIA2 meeting have completed the final draft of the DPIA2 (there may be times where you have to hols additional meetings to resolve issues that this becomes difficult).

Within 2 weeks of final draft to have gained JIMU and DPO sign off.


2

Within 2 weeks of JIMU / DPO approval to have gained sign off from remaining signatories (IAO, SRO and final DPO sign off).

Between sign off and go live – track completion of actions as per agreed trigger points.

3) Key stakeholders involved in the DPIA2 process: Getting the DPIA2 process completed will involve different key stakeholders with differing priorities:

Business Lead / Owner: their focus is to get their new process / capability / system in use as quickly as possible, with minimum disruption / effort. They will have a longer term interest in the initiative but they will likely be doing this on top of their day job. They will be open to supporting GDPR compliance but if it conflicts with how they would like the system to be used or requires more of their resource, it may be more challenging for you to ensure your views and data protection requirements are incorporated at the right time. You may need to be more proactive driving this work through, escalate if needed and try to make solutions to the data protection problems as pragmatic as possible.

Project Manager: There are 2 types of PMs. Projects delivering new IT systems or

very technical solutions will usually be assigned an ICT Project Manager. Projects involving process changes or predominantly ‘business change’ will be allocated a PM from the Change Teams. Progress from all projects (ICT or Change Team) are monitored through Programme Boards.

They are solely committed to the delivery of the project. You will have their full focus and commitment and energy but this will only be for the life of the project. This is a short term but very effective window to work in but when the project is delivered they will have no responsibility for any outstanding actions. The PM is focussed on 3 things: delivering the process / system / capability in the scope that was agreed; delivering it on time, delivering it on budget. If you are suggesting any actions that will increase the projects scope, cost more, or cause delays - it may be more challenging for you to ensure your views and data protection requirements are incorporated. You may need to be more proactive driving this work, escalate if needed and try to make solutions to the data protection problems as pragmatic as possible, particularly around timescales. You can help your PM by making sure the DPIA is carried out early enough in their project time line and highlight any subsequent data protection actions as early as possible. You won’t be helping them if you are nervous of raising issues and wait until the last minute to do so. Don’t forget some projects (particularly ICT) will be delivered by one project to both forces – so we need to make sure we don’t duplicate IG effort on these.

Project Board / Senior Responsible Officer: they exist to ensure that the project

is delivered on time, on budget and in scope but they are also there to manage risks


3

associated with the project. They may have a broader organisational view of risk for the force and may help a Project Manager see a broader picture. The Senior Responsible Officer is the person in the business who is ultimately accountable for the delivery of the project and will chair the Project Board. They will have a longer term interest of the risk and viability of the ultimately delivered process / system / capability.

Data Protection Officer (DPO) and Information Asset Owner (IAO): These two

roles come into play towards the end of the DPIA2 process when you are ready to get it signed off. They will ultimately accept whether they are happy with the mitigating actions and any residual risk. The DPO will accept any data protection compliance residual risk and actions. The IAO will accept any business delivery residual risk and actions.

4) How Projects work – the main phases and when we IG fits into it: It is important to do the DPIA2 at the correct time to be at its most effective. Ideally by the time that you do the DPIA2 the project should know WHAT they want to do and HOW they want to do it. On some very large projects or some projects with ‘Discovery’ phases, the project may only know WHAT they want to do initially (and not HOW they will do it). **Gunny to add a paragraph here about when to use a DPIA 1 form – when you can’t do a DPIA2 because it is too early.

5) How to complete the DPIA2 process: The Project Manager (PM) will be responsible for ensuring that the DPIA2 is completed. If it is a smaller local initiative and there is no Project Manager it will be the relevant specified Business Lead who is responsible. Getting ready for the DPIA2 and gathering the information you need: You will have completed a DPIA1 form and decided that a DPIA2 is needed. If a DPIA is necessary, the next step will be to arrange a meeting with the project manager to ensure you have discussed key information at the early stage. It will be beneficial for the PM to bring along any persons they feel are necessary to provide context and specific technical information regarding the processing. Prior to this meeting, send out the ‘DPIA Questionnaire’ so you can begin any necessary initial research. This questionnaire is optional and you can choose to use it where it will help you prepare for the meeting in advance. A good place to start in the DPIA 2 meeting would be to get the PM to explain the current process and the system which is used. Get them to explain the new process and system and pick out any key differences. You will still need to assess where there are data protection compliance gaps in the new process and system and explain them to the PM.


4

Ideally you should start discussing possible solutions to the compliance gaps with the project manager straight away however there may be some more complex compliance gaps you need to go away and think about or get advice on. Keep the PM in the loop so that the DPIA does not get pushed to one side. These compliance gaps and solutions will become the ‘risks’ and ‘actions’ in the DPIA2 and will need to be agreed by all signatories eventually. Once you have gathered the information from your meeting with the PM you will need to complete the DPIA2 between you. Although the PM is responsible for making sure a DPIA2 is completed where needed it will be the IGO’s that will complete a large proportion of the document and own the responsibility for making sure it is ‘fit for purpose’ and gets it eventually signed off by the necessary signatories. The responsibility for completing the various sections of the DPIA2 form is as follows:

Project Manager / Business Lead: o Section 1: Outline of the project, objectives and benefits o Section 2: Describing the intended use of the personal data (part a – their

best endeavours, IGO may need to add more detail if necessary and / or tweak).

o Section 3: Consultation

Information Governance Officer: o Section 2: Describing the intended use of the personal data (parts b & c).

Section 4: Assessment of data processing compliance o Section 5: you will write the risks. Together with the PM you will agree the

mitigating actions which you will add to this section. o Section 6: you will organise the signing of the DPIA2 by all required the

signatories

6) Completing the DPIA2 Form:

The following detailed guidance notes will assist IGOs completing the DPIA2 form. Each numbered section of the DPIA2 has a corresponding numbered guidance section relating to it within this guidance section. The section numbers in DPIA Report and Appendix A guidance will match. The guidance is extensive to provide wide ranging support, however, not all parts of the guidance will be relevant to every project. Consider the elements that relate to your individual project. NOTE: In the main DPIA report there is text shown in blue which are quick tips to help you remember what sort of information is required. All blue text is guidance and should be removed for the DPIA once you have completed you working draft copy.

________________________________________________ Part 1. Outline of the project, objectives, benefits and purpose: (PM to complete)


5

At a high / summary level explain what type of personal data processing is involved along with the primary (and any secondary) objectives of the project. You may find it helpful to refer to your Project Charter or Business Case for a brief / summary explanation. If this is not a new process but a change to an existing project, system, technology then describe the current process and how the proposed changes will affect this The PM should document, only at a high level, explain what the purpose of the project is and what will be achieved. This could include the benefits for: the force, data subjects or society as a whole. You do not need to explain here how the data will be used. This section just sets the scene. An example could be:

The new Genesis system will improve the way public authorities work together to support the police in their efforts to expediently locate missing persons and reduce the risk of them coming to harm. Genesis will be cloud hosted enabling all public authorities to rapidly share relevant information about a missing person enabling the police to make a more complete risk assessment about the necessary resources they need to deploy in order to locate the person quickly. Genesis enables partner public authorities to identify those persons who are most likely to repeatedly go missing and put into place effective multi agency preventative interventions. The benefits of implementing Genesis will be:

o more effective deployment of police resources and earlier location of missing persons,

o earlier identification an intervention for those persons needing further support,

o and costs savings for police due to deploying resources more efficiently and preventing further persons going missing.

________________________________________________

Part 2. Describe the intended use of personal data: By the time the reader has read Part 2 they should know in reasonable detail how the personal data will be used in the initiative. You should be able to describe WHAT will happen to the personal data and HOW the processing will take place. Imagine the reader is a relative novice about the business process and data protection and that the only information they have is what you will eventually put in the DPIA2. In this section DO NOT stray into saying how the system is compliant – you are only describing how the data will be used. Leave the compliance bit until Part 4. There are 3 sections (a-c) to this part, all of which will need to be completed. Some tips are in red text within the DPIA template.

a) Describe the nature of the processing: The PM will complete this section with their best endeavours BUT it is likely you will have to ‘beef up’ the information to make sure it covers a full description of the processing. This is the telling the main story about how the data will be used. Include the below headings in bold as they


6

are common to most uses of data BUT the examples given below in italics won’t apply to every project and won’t cover every scenario. Eg:

o Collecting – if you are collecting data for the first time how do you collect it and from who. If it is a secondary use of data the force already has, what was it originally collected for and how is the secondary use different and are the data subjects likely to expect it.

o Use: what are you using it for and how will you use it. Are you exploiting any new technologies (eg drones) or using any novel types of processing. Is it a new use of the data for that department?

o Storage: where will the data be stored? Is it digital if so is it on the force network or will be hosted externally (eg in the cloud) and if so where. If it is hard copy is it paper, disc, microfiche, USB. Again will it be stored on force premises either locally, at our REC or CAF or by a 3rd party storage company. How will it be stored: for frequent or infrequent retrieval; packaged securely; inaccessible to certain staff eg: high security levels.

o Sharing: are you giving force data to another organisation either as data sharing data from one data controller to another or providing it to a 3rd party supplier from Data Controller to Data Processor. How does the provision take place – do we provide a report with the data or do they have access to our system and can collect it themselves. Is it a joint shared system used by Joint Data Controllers? What will the other organisation do with the forces data?

o Security: who will have access to the data, does access need to be restricted to certain groups of people? This may vary depending on whether the data is a digital format (accessed via systems or mobile data devices) or whether it is in a physical format paper, discs, USBs. Will the data be encrypted at rest and during transit? Will the end point devices be secure or encrypted (eg force issued mobiles). If the initiative involves lots of sharing will a there be a secure method of data transfer?

o Deletion: are there any steps in the plan to delete the data when it is no longer needed. If the data is shared is there any requirement placed on the recipient as to when the data should be deleted?

o New technologies: add here ONLY if the initiative uses new to society technologies such as: facial recognition, artificial intelligence, profiling etc.

o Novel types of processing: add here ONLY if the initiative includes processing which is new and novel to the force but not necessarily to society eg: drones, video conferencing etc.

o Screening Criteria from DPIA1: (IGO to add) whatever DPIA1 criteria was that caused you to be doing a DPIA2 have you made sufficient mention of it. For example if it is: monitoring, tracking, automated decision making, or profiling – have you made sufficient mention of the inherently privacy intrusive nature of the processing.

b) Describe the scope of the processing (IGO to complete this section) This section aims to expand the story about how the data will be used by explaining how much, for how long, sensitivity, types of data subjects. Provide information


7

under the below list of headings although it is likely that this section won’t be as comprehensive or detailed as section a) above.

the type of personal data; the volume and sensitivity of the personal data; whether processing includes children or vulnerable individuals the duration of the processing; the geographical area covered eg: Force wide, LPA, county; data ownership (as data controller) at various stages, any data processors.

Eg: The processing will be of personal and special category data and some limited criminal data where it might help locate the missing person. This will involve about 1,500 data subjects across the whole force area per year and will be adult or children who are likely to be vulnerable to an extent due to their going missing. The data will be most frequently used whilst attempts to find the missing person are made and any safeguarding measures are put into place and then retained for a 6 years to understand patterns of person who go missing more frequently. The data will be stored in the Genesis system and accessed by all partner organisations as Joint Data Controllers and hosted by and external supplier as the data processor.

c) Describe the bigger picture in which the processing is taking place: This should include internal and external factors which might affect the data subject’s expectations or the impact of the data processing. Provide information under the below list of headings although it is likely that this section won’t be as comprehensive or detailed as section a) above. Some examples are shown below in italics: For example:

the source of the data and the relationship with the Data Subjects; has the data come directly from the data subject or provided by someone else. If provided by someone else (ie: partner organisation) does the data subject know. What is the balance of power like between the data subject and data controller – is it very one sided (eg: such as employer and employee, a public authority and the citizen).

the extent to which individuals have control over their data; is consent is the lawful basis for processing it would indicate genuine freedom of choice and control. Does the data subject have to agree in order to access the services they want or enter into a contract? Will the data controller process the data anyway even against the data subjects wishes (the police often do this with offender data) and if so is any detriment warranted? If the data subject changes their mind do they have control to stop processing (eg: consent or performance of a contract).

the extent to which individuals are likely to expect the processing; if the data subject

provided the data then they are likely to expect the processing to some degree. If the data is collected from someone other than the data subject (partner or victim) has anyone told the data subject or would they reasonably expect it. Do we have to tell them (not always if it would prejudice our policing aims). Regardless of where the data is collected from would the data subject reasonably expect it?


8

any current issues of public concern; any obvious privacy intrusive aspects? Eg:

facial recognition technology processing images of mostly well behaving law abiding citizens to catch a relatively few offenders. Drones flying over peoples back gardens may capture citizens enjoying their private life in a location where they have a reasonable expectation of privacy.

Whether you have considered and complied with any relevant Codes of

Practice. There may be existing industry standards, codes of practice or certification schemes where adherence to them provides assurances that good standards will be applied. Eg: use of CCTV cameras in line with the Surveillance Cameras Code of Practice ensure a consideration of privacy and proportionality or use. Certification to security standard ISO 27001 will guarantee a level of security. A USA company registered with the Privacy Shield programme for processing data in the USA will guarantee adequate safeguards for transferring data outside the European Union. In reverse that the solution may need to meet a particular standard or Code of Practice. Eg: if doing a DPIA on the use of CCTV, ANPR, BWV or dash cams that you will need to flag that any solution will also need to meet the Surveillance Cameras Code of Practice.

_____________________________________

3. Data Subject Views: (PM to complete) The PM will need to complete sections a) – c). If the new process or system is likely to be particularly privacy intrusive, a big force wide initiative, use new state of the art technology or be processing police employees data then you may expect some consultation with the data subjects. If the data subjects are public the consultation will likely have been managed by Corporate Communications – eg: the initial introduction of officer worn BWV. If it is a new process or system that affects HC / TVP staff significantly then there may have been some consultation with the staff associations such as Unison and the Police Federation. It is likely that the PM will provide only basic information you may need to encourage them to expand if you feel there were some key areas they consulted on but haven’t been included. The header sentences are there as prompts only to the project manager and should be substituted with the actual text to be used. a) Describe the approach that was taken when seeking the views of the individuals

whose information is being processed: The success of a new staff survey to run over 3 years was dependant on good participant levels from staff and their trust in what would happened to the data. We consulted with officer and support staff ‘staff associations’ to better understand and address any potential concerns staff may have.


9

b) A summary of the views of those individuals: Feedback from staff associations were that participants would want reassurances that they could participate anonymously if they did not want to be identified.

c) The above views were taken into consideration and measures to support them

have been included in the planned data processing activities. These concerns were taken into consideration. Where participants were happy to be identified we used a pseudonymisation tool to allow a comparison of their results over 3 years but without identifying them. For those who did not want to provide any identifying information whatsoever, they could leave the field blank but we would not be able to compare results across the years.

________________________________________________

4. Data protection compliance – assessment of necessity and proportionality of personal data processing. (IGO to complete) IGOs will need to complete all of the principles in Part 4 and along with Part 2 this is the most important section of the form to complete. Part 2 of the DPIA2 has described how the data will be processed and you will need to translate this into how the intended use meets the requirements listed against each principle in Part 4. The Principle headings will remain in the document but the bulleted prompts which are shown in red will need to be deleted once you have added the relevant text to replace them. Most will be relevant to your new process or system but not necessarily all. There may be several ways in which we might be doing activities which helps the force comply with GDPR and DPA18. There may also be some areas where there are gaps and IG identifies we need to do more. Any of these measures that help the new process / system be compliant should be added to the relevant principle in Part 4. These can include:

Activities that the force is already doing as normal every day procedure and will continue to do in relation to new process or system. Eg: the data is stored and transferred around the internal HC/TVP IT network and so is protected from cyberattacks and compromise OR sending data to recipients internally by email which is encrypted by default.

Activities that the force is not currently doing but the project had already

identified as necessary work to and has factored it into the project plan. Eg: determining role based user access and permissions for a new IT system OR providing users of a new system with classroom training and a user guide. As well as including these in the relevant principle of Part 4 you will also capture these in a separate list so completion can be tracked. More on that list in Section 5a.

Activities that the force is not already doing but you recommend that they

should in order for the new process or system to be compliant with GDPR / DPA18. Eg: there is no automated retention capability in a new IT system and you recommend that a capability is developed. In the relevant principle of Part 4 you


10

will need to explain the compliance gap and what activities will close it. These will go on to form the risks and actions later in the DPIA2. More on that in Part 5b.

In the below section you will see the constituent ingredients that you will need provide information for and may be in blue text in Part 4 of the DPIA2 template. To help you distinguish what is a prompt and what is guidance the following tips will help. The prompt (text you must include) will be in normal bold text. The guidance on what to provide will be in italics.

Principle 1 - Personal data shall be processed lawfully, fairly and in a transparent manner in relation to individuals.

Information is being processed under Law enforcement / GDPR / GDPR & Law Enforcement rules (delete what is not applicable). It is important to establish which legal framework the processing will need to satisfy.

This could be one of the following: Law Enforcement Processing: where the processing is carried out by the Police

or another competent authority AND the processing is for the specific law enforcement purpose “prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against the prevention of threats to public security”. Note this is a narrower purpose than the MoPI Policing Purpose and does not cover processing for prevention of offences unless it is for public security (ie: larger scale public order, national security) and civil offences. This processing is governed by Part 3 of the Data Protection Act and not the GDPR. Schedule 7 and 8 of the Data Protection Act will also apply.

GDPR Processing: any processing that doesn’t fall under the above Law

Enforcement purpose will fall under the GDPR. There will still be some parts of the Data Protection Act that will also apply (Part 2, Schedule 1(special category lawful bases, and Schedule 2 exemptions).

Law Enforcement and GDPR Processing: the movement of processing between

GDPR and Law Enforcement rules could happen in either direction but where it does you will need to be aware of when the rules change. EGs:

o Law Enforcement to GDPR: usually when police are sharing information collected in the investigation of an alleged offence to a partner that is not a competent authority (listed n Schedule 7 of the DPA). Also the sharing of police data to another organisation for research purposes. Where you are stepping down from Law Enforcement rules to GDPR rules you will need to carefully check that there is a clear MoPI Policing Purpose for the further use for the Law Enforcement data.

o GDPR to Law Enforcement: usually where the police receive information form non competent authorities for the purpose of the investigation of an alleged offence.


11

Principle 1: Use of personal data is fair, lawful, and transparent:

a) Lawful basis for the processing of personal data is stated as follows: Personal data: Special Category data: Criminal data:

You will need to look at the legislation itself to establish which lawful basis is the closest fit to the data processing in your initiative. You should only chose one for each type of data and where you look will depend on whether you are operating under GDPR or Law Enforcement (LE) regimes.

Personal data: o GDPR: Article 6 o LE: Data Protection Act 18, Part 3, section 31.

Special Category Data:

o GDPR: Article 9 and if one of the following (9: b, g, h, I, j) then in addition you will need an additional one from Data Protection Act 2018 Schedule 1, Parts 1-3.

o LE: Data Protection Act 18, Schedule 8

Criminal Data: o The police as a Competent Authority will not need a condition to process

criminal data – ie: we don’t need to justify it. o If you are sharing criminal data with a partner under GDPR then you will

need to check that they meet a condition from Data Protection Act 18, Schedule 1, Parts 1-3.

Few general notes:

Nearly all of the lawful bases (except consent) have the word necessary in the wording. This means that even if the reason for the process satisfies a lawful basis; unless it is necessary for you to use personal data to achieve the purpose you cannot satisfy the lawful basis. Similarly it the way you chose to do that processing uses more personal data than necessary then you cannot satisfy the lawful basis IF it has necessary in the wording. Data minimisation – ‘no more than necessary’ is the approach to take.

If you are relying on consent as your lawful basis to process personal data; does it

meet the new consent standards (freely given, specific, informed, and unambiguous)? How will you help people withdraw their consent if they wish to?

As well as satisfying a lawful basis as stated above the processing must be lawful in more general terms. For example: if the processing breaches the Human Rights Act, a Duty of Confidentiality, contract law, or is the police acting beyond its lawful powers then the processing will fail Principle 1 as it will be inherently unlawful (even if you have the correct lawful bases).


12

b) Explain how individuals will be made aware of the processing:

All data subjects have a right to be provided with set information about how we use their data. As a default we have a Privacy Notice on the force website that data subjects can go and view but we should always consider whether there are any practical and achievable ways to proactively provide it to them.

You will especially need to consider this if the force is not receiving the data from the data subject themselves (how will they know we have their data) – eg: data received from a partner. There is an exemption from having to tell people but this cannot be used in a blanket nature. We can only use it where telling the individual would prejudice our ability to prevent and detect crime (ie: a suspect in a crime).

If the processing is not likely to be expected by data subjects.

It is a system where we are asking the data subject to provide data themselves –

can we use a specific privacy notice at point of input.

If we are speaking to the data subject or sending a letter can we use that as an opportunity to provide a link to our website Privacy Notice or hand out a leaflet …?

Principle 2: Use of personal data is for a specified, explicit and legitimate purpose and not re-used for a purpose that is in-compatible with the original purpose:

If collecting personal data for primary use, explain how you have targeted only the information required.

If re-using personal data for further use, explain how this secondary use is compatible with the original reason you collected it

This Principle has 2 parts:

1) If your initiative project involves collecting data (rather than re-using data you already have) then you will need to make sure you are only collecting what you need and that you are using for a specific purpose.

2) If your project involves the re-use of personal data already held by the force (i.e.:

you are not collecting it before use), you must check that the secondary use is not incompatible with the original reason you collected the personal data. In making this assessment you can consider the following:

o any link between the reason for initial collection and the intended further use;o the context in which the data was originally collected (in particular the

balance of power in the relationship between the individual whose data it is and the force (data controller);

o the nature (sensitivity) of the data – does it involve special categories of data or criminal data;

o the possible consequences to the individuals whose data it is, from the


13

intended further processing; o the existence of appropriate safeguards which may include,

pseudonymisation, encryption. Further processing for archiving purposes in the public interest, scientific or

historical research purposes or statistical purposes will not be considered to be incompatible with the initial purposes.

If you collected the personal data under the Law Enforcement rules (Part 3 Data

Protection Act 2018) and the secondary use is not for the Law Enforcement Purpose (under GDPR rules) - the secondary use of personal data must be authorised under law. Authorised by law can mean: legislation, Statutory Code of Practice, Royal Perogative, Common Law, Court Order. For operational policing processing the most straight forward way to meet ‘authorised by law’ is to check that your secondary processing clearly meets a MoPI Policing Purpose:

o protecting life and property; o preserving order; o preventing the commission of offences; o bringing offenders to justice; o any duty or responsibility of the police arising from common or statute

law. A common example of the collection of personal data under the Law Enforcement regime but further processed under GDPR is when you share operational policing information with a non-Competent Authority. Note for processing to take place under the Law Enforcement regime it must meet the law enforcement purpose AND be carried out by a Competent Authority (as listed in Schedule 7 of the Data Protection Act 18).

Principle 3: Use of personal data is adequate, relevant and no more than necessary:

Explain how the amount of personal data you intend to use is enough to be understood by the audience but no more than the minimum needed to achieve your purpose:

This is often referred to as ‘data minimisation’ and is a golden thread running through data protection. It links into the word ‘necessary’ that can be found in many of the lawful bases you will look at for Principle 1. We should be processing no more data than we need to even if it takes a bit more effort to make that happen. Consider the following:

Is the quality of the information good enough for the purposes it is used for? Is the information easy for the audience to understand (are there too many

acronyms that mean if you share it with another organisation they won’t understand it)

You should only use the minimum amount of personal data that is necessary to


14

achieve your objective. You must consider: o can I achieve my objective by only using anonymised data or

pseudonymised data; o if the use of personal data is necessary; what personal data could you not

use, without compromising the needs of the project (the use of personal data should not be a ‘nice to have’)?

If the processing is predominantly information sharing be aware that any blanket sharing will not meet principle 3. Blanket sharing is where we do not consider each request on a case by case basis OR do not have any criteria that has to be met before sharing is justified.

Principle 4: Personal data must be accurate and kept up to date:

Explain how accurate recording of data will be achieved and how it will be kept up to date, where necessary:

Explain any mechanisms that will allow you to amend or append data that is found to be inaccurate (ie: DQ errors in recording):

Explain any mechanisms that will allow you to restrict data if accuracy is contested.

How are you ensuring that personal data obtained from individuals or other organisations is accurate? There is a greater expectation that if the data subject is providing you their own personal data, that they have provided accurate data. If you receive it from someone other than the data subject is it necessary to check that the data is accurate where it is possible to check (often time we have to take the data quality in good faith

Does any part of the process make it unlikely that good data quality and accuracy will be achieved? If so how can this risk be removed; process checks, guidance?

If you are procuring new software does it allow: o Validate some of the very important data fields to ensure users record data in

the correct format. o It is possible to amend or append data when necessary? What processes will

this entail? o Is any metadata or audit data produced by the system accurate (ie; time date

stamps, which user did what, geographical location mapping) If you identified inaccurate data for correction, would you be able to identify who the

data had been shared with so you could make those organisations aware of the error if it is important that you do so?

If the accuracy of personal data were contested by the individual do you have the ability to restrict the use of the data whilst the dispute is being resolved? The law says if you do correct the data then you must tell any recipients you have shared it with. Would it be possible to do that – would you know who it had been shared with?

If your project involves integrating or sharing of data sets how will accurate data be ensured by design and once in regular use?

Law Enforcement Processing Only: If you are implementing a new IT system for


15

recording operational policing data which comes under the Law Enforcement Regime the there are some extra requirements. Does the system have the following required functionality:

o does it have any capability to distinguish factual data from opinion, so far as the context of the data requires (eg: witness statements are opinion. BWV footage is fact)?

o does it have the ability to categorise the types of individuals where possible: victim, witness, suspect, convicted, other (eg: how a person is linked to a particular record or event / occurrence)?

Principle 5: Personal data must be kept in an identifiable format for no longer than necessary:

Data held in the new IT System – explain how any automated and / or manual capability to delete data will be used to comply with MoPI retention rules or the NPCC Retention Schedule.

Data held in an unstructured manner (paper, word / excel files etc) - explain how you will use any automated and / or manual capability to delete data in line with MoPI retention rules or the NPCC Retention Schedule.

Personal data can be processed / retained for no longer than necessary in an identifiable format. Anonymising data means that the GDPR / Data Protection Act 18 no longer apply and then there are no restrictions on how long the data should be kept. That said there will be a cost to store data so it will still be necessary to establish the minimum amount of time the business needs to keep it for.

Consider the following:

Most data used by the police service will have a retention framework that can be

applied. o The retention of data used for operational policing will be governed by the

MoPI Retention Schedule (can be found in APP Information Management). The retention of operational and non-operational data is governed by the National Police Chiefs Councils National Retention Policy. The NPCC Retention Policy will be very helpful to tell you how long to retain non-operational data for. If you look at the NPCC Retention Schedule for the retention of operational policing data it will refer to the MoPI Retention Schedule. You should adhere either the MoPI Retention Schedule or NPCC Retention Schedule however if the record type you are looking for is non-operational and is not covered by the NPCC Retention Schedule you will have to establish the minimum retention period with the business.

The archiving or logical deletion of digital data / records does not count as deletion.

The ICO recognises that not all older IT systems can delete data but where there is no deletion capability the data must be put beyond operational use. This means you would never ever use it again which would be very hard to ensure in reality.


16

Moving forward more and more of our new IT systems are hosted in the cloud where we pay the cloud provider for the storage of the data. This is a strong financial driver to ensure data is not kept longer than necessary and deletion functionality is sufficient.

Deletion of data will occur in 2 main ways and you will need different capabilities to

deal with each: o Adhoc deletion: this happens as a result of a data subject exercising their

data rights and asking for their data to be deleted. If we agree to delete, it will require a system user (with special deletion privileges) to delete the specific record in question. This type of deletion must be possible by a user from the application front end and not need specialist ICT knowledge to remove the record from the back end of the database.

o Housekeeping / bulk deletion: this is the risk or time based disposal of large quantities of records that will need automated functionality without a user needing to physically delete each record. It may be appropriate for some record types to be reviewed before deletion but it would be expected that the system automatically triggers records for review at the right time. This capability will usually occur by the system being configured with specific deletion policies that the system runs automatically. If there is no automated capability to manage this type of deletion it will rely upon human resource to manual review the records which in reality the force will never be available - so JIMU will always push heavily for any new systems to have this automated capability.

If storing paper or electronic records outside of an IT system (unstructured

records) have you thought about storing them in a way that makes deletion quick and easy when the time comes? For example filing records in a box or data folder by their deletion date will make deletion quick and easy when that date comes without the need to review the records first.

Personal data processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes may be stored for longer periods subject to implementation of the appropriate technical and organisational measures to safeguard the rights and freedoms of individuals.

Principle 6: Personal data must be protected against unauthorised / unlawful use, accidental loss, damage or destruction:

Explain any technical security measures that will be put in place to protect the data:

Explain how you will make data users (staff) aware of any security measures or procedures they will need to follow.

If this is for Law Enforcement processing, explain how the systems audit


17

functionality will meets each element of the logging requirement.

i. Collection: (minimum = date / time) ii. Amending: (minimum = date / time) iii. Searching: (minimum = date / time / reason for search. So far as

possible = identity of user) iv. Disclosure: (minimum = date / time / rationale for disclosure. So far as

possible = identity of the person disclosing and the recipient) v. Combination: (minimum = date / time) vi. Erasure: (minimum = date / time. Do not keep a copy of the deleted

personal data in the audit log) In all of the above it would be expected that the identity of the user carrying

out the processing activity would be logged however it is not a legal requirement to do so in all cases.

Personal data needs to be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures. In order to ensure the level of security is appropriate you will need to know the volume of data that will be processed and how sensitive the data is. Higher data volumes and sensitivity are likely to require higher levels of security. In reality the Information Assurance Team in ICT will look after assessing and recommending what technical security is required. Information Governance is more likely to make recommendations for organisational security measures such as guidance, policy or system operating procedures. Consider the following:

Do any new systems or processes provide protection against the security risks you have identified?

If you are transferring personal data to other organisations how can you do this securely with encryption?

Has the new IT system been assessed by the Information Assurance Team? If the new initiative involves a 3rd party acting as our Data Processor the Information

Assurance Team in ICT will need to assess the security and reliability of the Data Processor (the Data Controller is required to only use data Processors that can reliably help them comply).

What training and instructions are necessary to ensure that staff know how to operate a new system or process securely?

What risk management procedures / policies will be in place to prevent any breach or damage/loss of data form occurring? Could include human error, hacking, network failure, theft, destruction of hardware etc.

How will the force ensure the Data Processor (if used) will also comply with the data protection legislation – contract clauses are the preferences but failing that a Data Processing Agreement?

Are staff aware of the Security Breach reporting process in force and the need to report breaches urgently? Are any new joiners aware?


18

Law Enforcement Processing ONLY – ‘Logging’ requirement (Data Protection Act 18 – section 62): If you are implementing a new IT system for recording law enforcement processing it must have the following required functionality:

o ability to log time / date / user (system audit capability) for the following data activities: recording, amendment, searching, combining / merging, deletion;

7. Personal data will be processed in accordance with the individual’s data protection rights:

Explain, where relevant, how requests from individuals wanting to exercise their rights, will be managed.

JIMU has Public Access Teams that receive and action requests from data subjects who wish to exercise their data rights. If the initiative involves several organisations having shared access and use of a single pot of data in an IT System they will likely be Joint Data Controllers. In this scenario you will need to understand how data subject’s requests will be dealt with if they involve more than one organisations data. Consider the following:

The individuals whose data you are processing have a suite of data protection rights they can exercise. To support the exercise of these rights does your IT system or process allow for:

o easy searching and retrieval of an individual’s records by name, common ID characteristics, or occurrence / event URN;

o amending, appending or deleting inaccurate data and restricting its use whilst accuracy is being disputed, until resolved;

o manually deleting an individual’s record where their right to erasure has been agreed by the force;

o in certain situations provide an electronic copy of an individual’s data; o be able to restrict the use of the data whilst it is being contested by the data

subject. 8. Personal data will not be transferred outside the European Economic Area (EEA) without guaranteed adequate privacy protections:

Confirm whether personal data is being processed outside the EEA and if so


19

where: If yes to a) above - explain which of the formal / recognised ‘adequacy’

measures will guarantee privacy protection. *Note: the preference would be for processing to take place within the UK.

Personal data shall not be transferred outside the European Economic Area (EEA) without adequate privacy protections being guaranteed. IF / WHEN the UK leave the EEA the UK will be classed as a 3rd Country and be outside of the EEA. As a result where we are using Data Processors to host our data (usually in the cloud) there is a strong preference for the location of those data centres to be in the UK (England, Northern Ireland, Wales, Scotland). Where this is not possible then the data centre should be located, or any data transfer / sharing should remain within the EEA. If transfer outside the EEA is necessary then there are avenues to address this –see below guidance:

GDPR_transferring_data_outside_EEA

Transfer does not mean the same as transit. If personal data is just electronically routed through a non-EEA country but the transfer is actually from one EEA country to another EEA country, then it is not a restricted transfer. Eg:

Personal data is transferred from a controller in France to a controller in Ireland (both countries in the EEA) via a server in Australia. There is no intention that the personal data will be accessed or manipulated while it is in Australia. Therefore the transfer is only to Ireland.

Consider the following:

If using a new or a different IT supplier, understand where the system is hosted, the location of servers with cloud hosting, and the location of supplier’s staff that will provide an IT Support service. Providing a support service where the Support Staff are in a country outside the EEA (even if the data is in the UK / EEA) will constitute a transfer outside the EEA.

Does your process involve individuals / users accessing and using personal data via a website where you cannot control their location within the EEA?

If the transfer of the data outside the EEA is part of a police investigation this will be covered by the Law Enforcement regime which has more flexibility for transfers.

Transfer does not mean the same as transit. If personal data is just electronically routed through a non-EEA country but the transfer is actually from one EEA country to another EEA country, then it is not a restricted transfer. Eg:

o Personal data is transferred from a controller in France to a controller in Ireland (both countries in the EEA) via a server in Australia. There is no intention that the personal data will be accessed or manipulated while it is in Australia. Therefore the transfer is only to Ireland.


20

9. The force must be able to demonstrate how they are complying with the Data Protection Act 2018 & GDPR:

Explain data ownership / liability and what subsequent governance

documents will be required (if any) to support the data processing (eg: Information Sharing Agreements, Data Processor contractual clause in commercial contract or DPC, Joint Data Controller Agreements).

Detail, where known, what governance arrangements will be in place to oversee the processing of personal data in a compliant manner when BAU (eg: user group meetings, system stakeholder meetings etc).

The force must be responsible for, and be able to demonstrate, compliance with the data protection principles (1-8 above). You will need to understand the data flows and data ownership at various points through the data flow to understand what governance documents are required. Is any provision of data to another organisation data controller to data controller sharing OR joint data controllership OR the data controller using a data processor. Consider the following:

If your project / process involves the following arrangements you will need additional governance:

o information sharing – will need an Information Sharing Agreement; o use of 3rd party contractors to process force data as a ‘Data Processor’ will

require mandatory clauses in the contract; o shared use / access of data held in a single IT system, by more than one

organisation, – will require Joint Data Controller MoU; o new IT systems might require a System Operating Procedure so that users

understand how to use the new tool and data within it.

The force must keep sufficient records to be able to demonstrate that it is complying with data protection legislation. There will be a degree of corporate governance required around your new initiative’s processing once it has transitioned to ‘business as usual’ and in addition certain types of processing activities will require additional governance:

o has the use / flow of data been captured in the forces Information Asset Register or does the existing entry need updating? Check with the Information Governance Team in JIMU;

o has an Information Asset Owner been assigned to own the process / data once implemented as ‘business as usual’?

o who or what forum will ensure ongoing data protection compliance in BAU?


21

Miscellaneous:

1) Automated Decision Making: Identify whether the processing includes any automated decision making (ADM) as this is limited under GDPR and specific safeguards are required. For ADM to be occurring there are 2 key ingredients:

There is no meaningful human intervention between the processing and the resulting decision being made

The effect of the ADM is either legal or significant If ADM is taking place the following safeguards are required:

The lawful basis for personal data will affect whether automated decision making can take place – you can only carry out ADM with the following lawful bases:

o For the performance of a contract between the data controller and data subject;

o If it is authorised by law; o If the data subject explicitly consents.

The data subject must be made aware that ADM is taking place (proactively) The ADM must be included in the force Privacy Notice Special Category data use must not result in any discrimination The data subject must have the ability to request that a human revisit an automated

decision.

2) Information Governance Officer - DPIA2 Compliance Check List: The below embedded document is a check list that you should completed to ensure you have made full data protection compliance considerations in Part 4 of the DPIA2.

IGO DPIA2

Compliance Check L Part 5. Identifying, assessing and mitigating risks: 5a) Pre-planned data compliance activity: During your meeting with the Project Manager they may well mention some data protection good practice activity that they are already planning to include as part of the project. This is good because if they weren’t planning it we would have asked them to do it anyway. Although they are planning to carry out these activities we will still want to list them in the DPIA2 in the table under 5a) so that we have a record of them and so that we are able to track their completion later on. Because this activity is already planned we will not record


22

it as a risk in section 5b) which will be reserved for new (unplanned) compliance activity we are requiring the project to undertake. Some more common examples of pre-planned data compliance activity are in the table below. Remember to make sure there is a specific owner assigned to each one (this will be someone in the project or business) and also a specific completion date. Activity

No. Data

Protection Principle

Activity (briefly detail the activity) Activity Owner

Activity Due By

1 6 - security Configure role based user access and permissions to limit data to only that which is necessary.

Business Change Manager

End Dec 2019

2 4 – data accuracy

Design and deliver user training for system users – to include specific exercises to emphasise accuracy of searching, data input and data amendment.

John Smith, Training Lead

End March 2020

3

5 – data retention

Legacy data over 6 years old will be identified via a script and not included in the back record conversion / data migration.

Mary Jones, ICT Analyst

End Nov 2019

5b) Risk mitigating actions required to fill further data compliance gaps: Where you have identified a compliance gap in section 4 but there was no pre-planned activity to address it – you will need to show it as a risk and mitigating action in section 5b). Be very aware that you are not generalising data compliance gaps that do not really exist in your project / initiative. For example: poor data quality is a data compliance risk (doesn’t meet principle 4). No data in our police systems is of perfect quality so only include data quality as a risk IF there is a particular problem about the way the information is gathered and input / amended in your initiative that makes poor data quality much more likely to happen. Describe the

problem that is the risk, the vulnerability that creates the problem and the potential impact on individuals.

Likelihood of harm Remote, possible or probable.

Severity of harm Minimal, some impact or severe.

Risk score Low, medium or high.

Agreed action Detail to action that will reduce the risk

Action Owner & due date Name & date

Residual Risk score Low, medium or high.

1 Poor system Possible Some Medium Adoption ICT – Low


23

address data quality caused by handwritten carbonated copies as source data will result in sex offender’s data being sent to the wrong address.

Impact of a new App allowing digital collection of source data.

John Smith by end June 2020

(likelihood is now remote)

Recording the risk: When you are wording the risk make it concise (1 sentence). There should be 3 ingredients in any risk for you to include:

1. Problem – the thing that is not working properly and is creating the risk 2. Vulnerability – this is the particular weakness that makes the problem much more

likely to happen (not just a theoretical weakness) 3. Impact – focus mainly on the consequences on the data subjects. If there is a very

strong organisational impact you may want to list this as well. Example 1):

Poor system address data quality caused by poor initial capture on poorly carbonating paper copies may result in letters containing offender data being sent to the wrong address potentially putting an offender at risk of harm.

o Poor system address data quality = problem o caused by poor initial capture on poorly carbonating paper copies =

vulnerability o may result in letters containing offender data being sent to the wrong

address potentially putting an offender at risk of harm = impact. Example 2):

Over retention of personal data caused by lack of system automated deletion functionality may result in individuals suffering detriment due to police acting on data they should no longer hold.

o Over retention of personal data = problem o caused by lack of system automated deletion functionality = vulnerability o may result in individuals suffering detriment due to police acting on data they

should no longer hold = impact. Make sure that you agree with the Project Manager the person who will be responsible for completing the activity or action – record a name and not a team. You will also need to agree a specific activity or action completion date with the Project Manager. It is not sufficient to put something like ‘before go live’ as a completion date. It should be at least a month and year and the Project Manager will have these dates in their project plan, even if they do slip and change later on. If in the future the dates do slip this can be reflected in the Action Tracker document.


24

Assessing the risk: You will need to make your best assessment in 2 areas: ‘likelihood’ and ‘severity of harm’.

1) Step 1- Rate the ‘Likelihood’: The likelihood of the risk actually happening. For example: every time I cross the road I face a risk that I may get run over. This is fairly unlikely to happen when crossing the road in my village. It may be more likely to happen on a busy town road with an obscured view. It may be very likely to happen if I try and cross the motorway during rush hour. The 3 options to select from are:

o Remote o Reasonably possible o More likely than not

Sometimes it feels like a guesswork but other times you will be able to make a confident guess. In reality the likelihood of your risk will be more commonly: ‘reasonably possible’ or ‘more often that not’.

2) Step 2 – Rate the ‘Impact’ (Severity of harm):

Consider the potential impact on individuals; and any harm or damage that might be caused by your processing – whether physical, emotional or material. In particular look at whether the processing could possibly contribute to:

Some impact:

o loss of confidentiality; o re-identification of pseudonymised data; or o inability to exercise rights (including but not limited to privacy rights); o loss of control over the use of personal data; o inability to access services or opportunities.

Severe:

o discrimination; o identity theft or fraud; o financial loss; o reputational damage; o physical harm.

You will need to try and convert the likely impact into a ‘severity of harm’ rating. The 3 options are:

o Minimal o Some impact o Severe

3) Step 3 – Calculating a Risk Score:


25

Once you know the likelihood rating and the impact (severity of harm) rating you will need to use the below matrix to score the risk as low, medium or high.

Harm does not have to be inevitable to qualify as a risk or a high risk. It must be more than remote, but any significant possibility of very serious harm may still be enough to qualify as a ‘high’ risk. Equally, a high probability of widespread but more minor harm might still count as ‘high’ risk. You must make an ‘objective assessment’ of the risks. The higher the risk score the greater the expectation is to take action to reduce the risk score and risk. Agreeing ‘Actions’ to mitigate the risks: When we talk about managing risks we also talk of ‘treating’ risk. There are 4 ways of treating risk:

o Terminate: completely stop doing the activity that caused the risk in the first place. This approach may be taken when the impact is just too severe to risk it OR if it was a nice to have where it is no great loss of benefit not to do it. Treating risk by termination is relatively uncommon.

o Transfer: this means give the risk to someone else and is usually in the scenario of where you can take insurance out to cover the risk should it happen. Again this is relatively uncommon.

o Treat: this means taking some mitigating action to lower the risk. This where the ‘Actions’ in the table in section 5b) come in. This is the most common way of treating risks.

o Tolerate: this means you accept the risk. It may be the likelihood or severity is so low it’s not worth spending too much time or energy to reduce further. Ultimately there is often a tolerance of residual risk which is where mitigating actions have lowered the risk but not removed it completely and so there is a lowered level of residual risk that must be accepted.

Identifying and agreeing actions to mitigate risks:


26

It’s important to make sure that any action that is agreed actually mitigates the risk in question. Essentially the action has to reduce the vulnerability that caused the risk in the first place. It is surprisingly easy to agree actions that do not actually lower or mitigate the actual risk. Looking at an earlier example of a risk:

Poor system address data quality caused by poor initial capture on poorly carbonating paper copies may result in letters containing offender data being sent to the wrong address potentially putting an offender at risk of harm.

o You could suggest introducing dip sampling quality checks of addresses on the system but this will not reduce the vulnerability or reduce the risk. You will just have more visibility of the risk / problem. To truly reduce the vulnerability and therefore the risk will require a new way to capture the data that doesn’t rely on using poor carbonated copies of the information to then input onto the system. So directly capturing the information in some way via the officer’s mobile device would likely reduce the vulnerability and therefore the risk.

The below list may give you some ideas as to some commonly occurring risk mitigation actions that are taken (not exhaustive). Cost or resource required will of course be a factor in considering pragmatic and effective risk reducing actions.

deciding not to collect certain types of data; reducing the scope of the processing; reducing retention periods; taking additional technological security measures; training staff to ensure risks are anticipated and managed; anonymising or pseudonymising data where possible; writing internal guidance or processes to avoid risks; adding a human element to review automated decisions; using a different technology; putting clear data sharing agreements into place; making changes to privacy notices; offering individuals the chance to opt out where appropriate; or implementing new systems to help individuals to exercise their rights.

Agreed measures will need to be factored into implementation plans and will be the responsibility of either the Project Manager to ensure they are completed, or where there is no Project Manager it will be the Information Asset Owner. Residual Risk Score: The level of risk that is left once you have taken any mitigation actions is called the ‘Residual Risk’ which should also be scored and added to the table in 5b. The residual risk score should be lower that the initial risk score (unless it is agreed no action will be


27

taken). If mitigating actions are taken but the residual risk score is not lower its worth checking that you have got the correct action and it is really lowering the risk You do not always have to eliminate every risk. You may decide that some risks, and even a high risk, are acceptable given the benefits of the processing and the difficulties of mitigation. However, if there is still a high residual risk, you must consult the Data Protection Officer who may refer the DPIA to the ICO before you can go ahead with the processing (this is a legal requirement). Tracking of DPIA2 Activities and Actions: Once you have your DPIA2 signed off you will need to hold the Project Manager (PM) to account to ensure the any pre-planned data compliance activity and DPIA2 actions are completed on time. This is critical! If the actions aren’t completed then all your hard work doing the DPIA will have been wasted and the force will be exposed to data risks. You will ask the PM to update you at pre-agreed points (called ‘trigger points’) with how the completion of those actions are progressing. The aim is to have all the actions completed by the agreed deadline and prior to the project going live (unless you have agreed a deadline post go live). As you are getting the DPIA2 signed off, discuss and agree with the PM the dates of the ‘Trigger Points’ – they should be as follows:

For most projects: Trigger Point every 3 months, the last one being just prior to the project going live.

For rapid projects: taking less than 6 months: Trigger Point every 2 months, the last one being just prior to the project going live.

The below document provides more detailed guidance on Tracking Actions and includes a blank copy of the ‘Action Tracker spreadsheet’ that you will use.

DPIA Action Tracker Guidance for IGOs 0

Part 6. Authorisation of the DPIA and its recommendations: There are several steps to the sig off process that should be followed in the below order. Any signatures do not need to be wet and can be typed into the form and emailed back to you. Step 1) Information Governance Manager Approval:


28

Your line manager will be checking with your regularly along the way as you complete your DPIA2 to help guide you and help make sure that everything that needs to be completed is in there. You will also have been having an ongoing dialogue with the PM to make sure the agreed risks and actions are achievable and that the PM is in principle happy that the DPIA2 is an accurate reflection of the initiative and its compliance. Once you think the DPIA2 is in complete (in final draft status) and ready for sign off (ie: parts 1-5 are complete) then you will have a final check with your line manager. Your line manager will be using a check list to make sure everything is included so it might be useful to use it to ensure you have completed all the necessary tasks:

IGM DPIA2 QA

Check List 041019 Step 2) Senior Information Governance Manager Approval: Either you and your line manager or just your line manager will seek approval from the SIGM of the DPIA2 section 5 ‘Compliance activity and Risk Mitigating Actions’ to ensure they are real risks that are concisely documented and that the actions will reduce the risk and are measurable and achievable. The SIGM will also check that there are specific action owners and action due dates. There are weekly DPIA Review slots with the SIGM you will need to book in advance to ensure this check doesn’t delay any DPIA2 sign off. Step 3) Data Protection Officer verbal approval (JIMU): The IGM (or by exception the SIGM) will briefly explain the initiative and data use to the DPO and forward the DPIA2 for review. The DPO is looking to be comfortable that the residual risks are at an acceptable level and pragmatic solutions; and effectively approve the processing to take place. The DPO will need 1 week to formally and finally review and be happy to sign off the DPIA2 document. However they will only verbally approve at this stage and will formally sign after all other signatories have signed the DPIA2. Step 4) Senior Responsible Officer and Information Asset Owner Sign off: Once signed by the DPO you will need to send the DPIA to the PM so that they can arrange for the following people to sign it off from the business side:

Senior Responsible Officer: this is the person who is accountable for delivering the project. If it is a local project with no Project Manager then the SRO may well be either the Data Guardian or the IAO.

Information Asset Owner: is the person who will own the business process and data processing once the project has been delivered and will own the longer term data compliance risks.


29

Step 5) Data Protection Officer formal signature (JIMU): Once all the other signatories have signed the DPIA2 it should be forwarded to the DPO for them to formally sign. This is a very quick step provided no changes have been made to the DPIA2 by the other signatories. Step 6) Store signed documents: Once the DPIA2 has been signed off by all the DPO, Senior Responsible Officer and Information Asset Owner the DPIA2 will need to be stored. A copy should be stored in Sharepoint for the IG record and a copy should be sent to the PM for them to store as part of their project documentation. Step 7) Accountability Tasks: The following tasks will need to be completed by you and checked as completed by your line manager. Signatures to show completion are included in Part 6 of the DPIA2 form and will likely be completed once the DPIA2 has been signed off (as per step 5) so that it less likely they will be forgotten. Accountability Task IGO to date & sign

when task complete IGM to date & sign when checked complete

Information Asset Register updated

Privacy Notice reviewed to see if new processing needs adding.

Trigger points for action tracking agreed and in DPIA Register

ISA Catalogue / DPC Register updated if any new ISAs / DPCs.


30

Section 6: Completing the DPIA2 Form (Part 6 – Review) There is a new review section in Part 7 of the DPIA2 which will allow us to add some additional information if once you have the DPIA2 signed off, there is a change in scope of the project or a new risk that had not previously been identified. The template is below but allows for a lean approach to adding an update and adding any new risks is they exist. It has a reduced sign off (DPO and Senior Responsible Officer) to avoid having to repeat the full sign off process again. Review Date Reviewing IGO

Reason for Review

Record: Change to processing and effect on data protection compliance:

If there is a resulting new compliance risk and mitigating action, record below.


31

Describe the problem that is the risk, the vulnerability that creates the problem and the potential impact on individuals. .

Likelihood of harm Remote, possible or probable.

Severity of harm Minimal, significant or severe.

Risk score Low, medium or high.

Agreed action Detail to action that will reduce the risk

Action Owner & due date

Residual Risk score Low, high or medium.

Signed / dated DPO: ………………………………………………. Signed / dated SRO: ………………………………………………

Signed / dated IAO: ………………………………………………

Documents

IGO Guidance notes for completing the DPIA2 1) Benefits of