The DPIA Process - a step-by-step guide

Do you need to complete a Data Protection Impact Assessment (DPIA)?

A DPIA is a risk assessment to assist you in identifying and managing potential risks associated with the personal data you need to use as part of your processing activity. It’s a working document you should engage with in the early stage of the work you are doing and refer to throughout. A DPIA helps ensure data privacy and data protection rights are designed into activity you are working on, whether you’re considering a new software or conducting a research project involving human participants or implementing a new or revised policy that will impact people. In some circumstances it is a legal requirement to complete a DPIA, to confirm whether you need to complete a DPIA, please complete the DPIA Checklist. In all scenarios, if you will be processing personal data it is good practice to conduct a DPIA. 

The University templates below have been designed to take you through the DPIA process. Begin the process by identifying the need for a DPIA using the checklist and then completing the DPIA template to document, evaluate and mitigate risks in relation to processing personal data.

DPIA step-by-step guide

By following the guidance below, users can ensure that they systematically address all necessary aspects of data protection and compliance within their DPIA. If any questions arise during the process, users should not hesitate to reach out to their Data Co-ordinator (sign-in required) for assistance.

1. Project Overview

Purpose: Outline the overall objective of the project and why it is being undertaken. This section should give a clear picture of the project's goals, its importance, and how personal data will be used.

2. Data Collection

Purpose: Identify the data to be collected, its source, and the justification for its use. You should include:

  • The types of personal data to be collected (e.g., name, DOB, email address).
  • Whether it will involve ‘special categories’ of personal data e.g., data about health, race and ethnicity, religious or philosophical beliefs, biometric data, political opinions etc.
  • If personal data will be pseudonymised or anonymised to protect people’s privacy
  • The necessity of collecting personal data and if the project goals can be met without it.
  • Whether the personal data includes sensitive categories (e.g., data about children or vulnerable groups).
  • The methods of data collection and sources.
  • Any international data transfers and compliance with relevant regulations.

3. Data Usage

Purpose: Describe how the collected data will be used and who will have access to it. This section will include:

  • The specific purposes for which the data will be used.
  • Identification of individuals or groups with access to the data.
  • Any third-party data sharing and reasons for it.
  • Plans for repurposing the data in the future.

4. Data Storage

Purpose: Explain the storage solutions and retention period for the data. This section will cover:

  • Where the data will be stored (i.e., in what country or countries, on the University network or a collaborative partners network etc).
  • How long the data will be retained.
  • Security measures to protect the data (e.g., encryption, access controls, training, policies etc).
  • Measures to ensure data quality.
  • Procedures for data disposal when no longer needed.

Personal data stored within decommissioned or legacy systems remains subject to UK data protection law. Even when a system is no longer actively used, organisations retain legal responsibilities for any personal data it still contains, meaning it must continue to be protected, processed lawfully, and retained only for as long as necessary. Projects that replace or upgrade systems therefore need to plan carefully from the outset how data will be securely migrated, archived, anonymised, or deleted. Failing to address this can leave sensitive information exposed in forgotten databases, backup files, or old servers. Robust decommissioning processes, secure storage arrangements, and clear accountability are essential to ensure that personal data remains protected during and after system retirement.

If the system being decommissioned includes personal data, your DPIA will need to record:

  • What personal data is stored in the system you are decommissioning, who it relates to, and if it includes any sensitive special category data?
  • Clear decisions and details on what will happen to personal data in the old system, e.g. whether it will be migrated to a new system, archived, securely deleted, or a combination; and
  • Security measures that will be applied to protect the data, along with evidence of data transfer or destruction.

If you are migrating personal data, only migrate what is genuinely needed in the new system and delete redundant, obsolete, and trivial data (ROT) beforehand.

You may archive personal data if there is a regulatory requirement, a genuine organisational need, or where technical limitations prevent immediate deletion. Archived data must be clearly separated from live systems, access must be strictly restricted, the data cannot be used for any purpose and must be placed beyond use (though it may still be subject to subject access requests). All retained systems or databases storing archived personal data must remain patched and secured against new security vulnerabilities. It must remain protected until final deletion. Archiving data held in decommissioned systems is a managed interim solution. The project must include a clear plan to delete the data once it is no longer necessary to retain it, and this should be recorded in your DPIA.

5. Consultation

Purpose: Identify stakeholders and outline the consultation process. This section will include:

  • Key stakeholders and their roles.
  • Engagement with Data Co-ordinators and other experts.
  • Permissions required from Data Owners or Stewards.
  • Involvement of Data Processors (i.e., an organisation or individual who processes personal data on your behalf and based on your instructions).
  • Consultation with information security experts or other relevant parties.

6. Data Subject Rights

Purpose: Ensure that individuals are informed about data processing and can exercise their rights. This section will cover:

  • Communication methods for informing individuals about data processing (e.g., privacy notice).
  • Methods for individuals to access, correct, or delete their data.
  • Contact points for questions, complaints, or data subject rights requests.
  • Opportunities for individuals to object to data processing.
  • Assessment of power imbalances between data controllers and data subjects.
  • Procedures for managing data rights in AI-related projects.

7. New or Innovative Technologies

Purpose: Describe the use of new technologies and associated security measures. This section will include:

  • Details of any new or innovative technologies used (e.g., AI, IoT).
  • Specific security measures for these technologies.
  • Confirmation of a Software Risk Assessment (SRA) if applicable.

8. Compliance

Purpose: Establish the legal basis for data processing. This section will cover:

9. Review and Monitoring

Purpose: Outline the process for ensuring ongoing data protection compliance. This section will include:

  • Identification of a senior person with a good working knowledge of the data processing activity responsible for compliance.
  • Procedures for reviewing and updating the DPIA, especially when new risks are identified or processing changes.

10. Risk Assessment – Identify and Score Risks

The DPIA risk assessment helps identify, assess and manage data protection risks by evaluating their likelihood and the severity of their impact to prioritise medium or high risks, and plan effective mitigations that can be designed into the data processing activity to reduce, manage or remove those risks.

Purpose: Assess potential risks associated with data processing. This section will involve:

  • Identifying and summarising potential risks to individuals, their data protection rights, and privacy. Think about what could go wrong, such as data breaches or unauthorised access.
  • Using a risk matrix to score the risks based on likelihood and severity of harm.  For each risk, estimate how likely is it to happen. Use a scale (e.g., 1 to 3) where 1 is remote likelihood or minimal harm and 3 is high likelihood or high harm.  Calculate the risk score by multiplying the likelihood score by the severity score for each risk.  This gives you the overall risk score e.g.
Risk Likelihood of harm Severity of harm Overall risk score
Risk 1 Remote (1) Significant (2) Low (2) - No mitigation required
Risk 2 Possible (2) Significant (2) Medium (4) - Plan mitigation
Risk 3 Probable (3) Significant (2) High (6) - Plan mitigation

11. Risk Assessment - Identify Measures to Reduce Risk

Purpose: Implement measures to mitigate identified risks. For any risk with an overall risk score of 4 (e.g., medium or high) or over, this section will include deciding on:

  • Strategies to reduce or eliminate medium and high-risk scores.
  • Preventative measures, contingency plans, or other risk mitigation techniques.
  • Evaluating the effect on risk and classifying the residual risk as low, medium, or high.

This risk matrix should be regularly reviewed and risks updated to ensure it remains accurate and relevant.