Data Protection Impact Assessment – How to make it useful

A Data Protection Impact Assessment (DPIA) is a practical risk assessment used to identify and reduce privacy risks before a product, system, process or supplier arrangement goes live. Under the GDPR, organisations must carry out a DPIA where planned processing is likely to result in a “high risk” to individuals’ rights and freedoms.

In practice, this is often the case when a project involves new technology, large-scale data use, monitoring, profiling, sensitive data, children’s data, or decisions that may materially affect individuals.

A good DPIA is not just a compliance document. It is a decision-making tool. Used properly, it helps legal, product, security, procurement and management teams make better design choices, evidence accountability, and avoid late-stage blockers.

Reading time: 7 min.

What is a Data Protection Impact Assessment?

A Data Protection Impact Assessment, or DPIA, is an assessment that evaluates risks when processing personal data. When considering a new use of personal data or before you change existing IT systems or processes, a DPIA will help you identify, analyse and minimise any potential data protection risks.

DPIAs are required by the GDPR

Any solutions developed and put on the market must be designed with data protection in mind, and its default setting must be privacy-friendly (this follows from Article 25 GDPR). DPIAs are one way of operationalising this obligation. DPIAs are defined in Article 35 of the GDPR. It also states that you must perform DPIA in certain situations. In general, the duty to perform a DPIA is connected to the general duty to manage risks in processing personal data.

Recital 84 states that the controller is responsible for performing a DPIA. It states that when undertaking a project, you should take the DPIA into account. It also states that the basic purpose of a DPIA is to “evaluate, in particular, the origin, nature, particularity and severity” of risk in relation to a particular high-risk project.

The rights of individual subjects are paramount in the GDPR. The purpose of a DPIA is to protect these rights. This includes both directly concerned rights, like privacy, and other fundamental rights, such as liberty and religion.

DPIA as a live tool/regular reassessment

It is important to note that using DPIAs is not merely to “tick a box” for GDPR compliance. Effective use of DPIAs enables you to identify risks and manage them at an early stage. It is a tool for decision-making. This benefits both your organisation and the individuals whose data you process.

Carrying out a DPIA is an ongoing process. It is not a one-time exercise. Therefore, it is important to review the DPIA regularly and keep it updated to the current status of your systems and use of personal data.

When must you perform a Data Protection Impact Assessment?

You must perform a DPIA when planning a project with high risks. The planned processing must, according to Article 35, be “likely to result in high risk”. If such risks are present, a DPIA is mandatory. In the following, we explain when you must perform a DPIA. In particular, we take the WP29 Guidelines on DPIAs into account.

What types of processing are relevant?

A DPIA may concern either a single data processing operation or a set of similar processing operations. It is vital that this set of operations shares similar high risks. Furthermore, the nature, scope, context and purpose of the operation are relevant.

One example of when this might be reasonable is given in recital 92. It might, for example, be reasonable and economical to do a single DPIA when several controllers plan to introduce a common application.

Another example would be if a public transport company were to implement video surveillance in all their buses. A single DPIA can cover this.
It is, however, important to include a justification for conducting a single DPIA in the documentation.

What are “high risks”?

When deciding whether to perform a DPIA, the level of risk a project entails is relevant. According to Recital 90, you should, once again, consider the nature, scope, context and purpose of processing. Furthermore, you should consider the sources of the risk. You use this to evaluate the “particular likelihood and severity of the high risk”. In addition, the WP29 guidelines and Article 35(3) provide a more detailed list of criteria you should consider. If your operation contains any of these criteria, you likely need to perform a DPIA:

• Evaluation or scoring (like profiling and screening of customers);
• automated decision-making with legal or similar significant effects;
• systematic monitoring;
• a large scale of sensitive data or data of a highly personal nature (including data relating to criminal convictions);
• data processed on a large scale;
• systematically monitoring a publicly accessible area on a large scale;
• matching or combining datasets;
• data concerning vulnerable data subjects (recital 75 of the GDPR);
• innovative use or applying new technological or organisational solutions; and
• prevents data subjects from exercising a right or using a service or a contract.

It is important to note that the criteria above are not exhaustive. Rather, they are a guideline for when you must perform a data protection impact assessment.

Situations where you must/must not perform a DPIA

Some examples of when you must perform a DPIA are helpful for understanding. One example is gathering public social media data to generate profiles. That includes evaluation and scoring, large-scale processing, combining datasets, and processing sensitive data. A DPIA is likely needed.

Another example includes companies monitoring employees’ activities (such as their workstations, internet activities and so on). This is systematic monitoring and data concerning vulnerable data subjects. A DPIA is likely needed.

It is impossible to list all situations where a DPIA is not needed. However, some examples of exceptions are helpful for understanding the main rule for DPIAs. When, for example, an online magazine uses a mailing list to send daily news to its subscribers, a DPIA is unlikely to be needed.

You must evaluate what is “likely to result in high risks” on a case-by-case basis. It is sometimes also required to perform a DPIA for ongoing processing operations. This is particularly relevant when risks change. Likewise, you can use the criteria above to determine when this is the case. You must make the determination on a case-by-case basis.

Before carrying out a DPIA

As discussed, a DPIA is primarily intended to be performed before a processing operation. You should do it as early as possible in the process. It is advisable to start it even though some of the processing is not yet determined. You can still update the DPIA throughout the preparation of the project and onwards.

Keep in mind that the needed parts of a DPIA can differ on a case-by-case basis. You might require additional steps for your intended processing.

To prepare for a DPIA, you must identify the need for one. The aspects discussed above can help you with this. When you have determined that you need to perform a DPIA, you can continue with the steps below. The steps below are based on the WP29 guidelines and the ICOs template for DPIAs, and are a good baseline for a DPIA. (Note that the UK is no longer a part of the EU, but has similar rules for data protection in the UK GDPR.)

A practical DPIA methodology – the short version

A useful DPIA should answer six questions:

1. What are we doing?
   Describe the product, process, system, supplier or change. Identify the personal data, data subjects, data flows, systems, recipients and storage locations.
2. Why are we doing it?
   Explain the business purpose, legal basis, expected benefits and intended effect on individuals.
3. Is it necessary and proportionate?
   Assess whether the same objective can be achieved in a less intrusive way. Consider data minimisation, retention, access rights, transparency, user control and purpose limitation.
4. What can go wrong for individuals?
   Identify risks from the perspective of the data subjects, not only the organisation. Consider unauthorised access, excessive monitoring, inaccurate decisions, loss of control, discrimination, exclusion, security incidents or unexpected secondary use.
5. What controls reduce the risk?
   Document technical, organisational and contractual measures. This may include access controls, encryption, logging, retention limits, human review, supplier terms, user notices, opt-outs, testing, training and escalation routines.
6. Who decides, and what happens next?
   Record the residual risk, decision, owner, required actions, review date and launch conditions. If high risk persists despite mitigation, consider whether prior consultation with the supervisory authority is required under Article 36 of the GDPR.

Methodology for a Data Protection Impact Assessment – the long version

Describe the intended processing

The first part of the DPIA is to describe the intended processing. You should answer the following questions.

• What is the nature of processing?
  • How do you collect the data?
  • What is the source of the data?
  • What personal data are you receiving?
  • Who has access to, receives or otherwise processes the data?
  • Will you share the data with others?
  • Are any likely high-risk processes involved?
• What is the scope of processing?
  • How much data will you be processing?
  • How often will you process the data?
  • For how long will you keep the data?
  • How many data subjects are affected?
  • From which geographical area does it originate? How large is it?
• What is the context of processing?
  • What is your relationship to the data subjects?
  • How much control will the subjects have?
  • Are particular vulnerable groups involved (e.g. children, patients)?
  • Are there prior concerns for processing?
  • Which assets are you relying on for the processing (hardware, software, networks etc.)?
  • Where do you store the data?
  • Are you complying with any codes of conduct (Article 40)?
• What is the purpose of the processing?
  • What do you want to achieve with the processing?
  • What are the benefits for you and others?
  • What is the intended effect on data subjects?

Furthermore, you should describe the processing operation itself. It can be helpful to refer to other documents, such as a project plan or proposal.

Assess the necessity and proportionality.

The second part of the DPIA is assessing the necessity and proportionality of your intended processing. The main question you must answer is, “What measures have you taken to comply with the GDPR?”

This question has two main parts. The first concerns the measures you are taking to ensure proportionality and necessity. This includes answering the following questions:

• What is your legitimate purpose? Specify and express it explicitly!
• What is your lawful basis for processing?
• Is your process adequate, relevant and limited to necessary data? Is there another way of processing?
• Are you limiting your storage duration?
• Are you limiting so-called “function creep”?

The second one concerns the measures you are taking to protect the rights of data subjects. Here are some examples of such measures:

• Providing information to the data subjects;
• ensuring the right…
  • …of access and data portability;
  • …to rectification and erasure;
  • …to object and restrict processing;
• having a working relationship with the processors and ensuring their compliance;
• safeguarding when performing international transfers; and
• performing prior consultation in accordance with Article 36.

Risks are identified and managed

The third part of a DPIA is to manage the risks that you have identified. The following questions help identify and manage risks.

• What is the origin, nature, particularity and severity of the risk(s)? (Examples of risks are illegitimate access, undesired modification and disappearance of data. Other risks can, of course, exist. It is important to identify in particular the severity of the risk from the data subjects’ perspective.)
• What is their potential impact on the rights and freedoms of data subjects? This, in particular, concerns certain events, such as data loss and unauthorised access.
• What threats could lead to the realisation of the relevant risks?
• What is the likelihood of harm? Remote, possible or probable?
• What is the severity of harm? Is it minimal, significant or severe?
• How big is the overall risk? Low, medium or high?

When identifying the relevant risks, you must identify measures to reduce them. The following questions are helpful.

• What measures have you envisaged to treat the risks that you have identified?
• What is their effect on the risks? Are they eliminated, reduced or accepted?
• Are there any residual risks, and if so, are they low, medium, or high?
• Has the measure been approved?

Consultation, recording the outcome and repeating

It is also important to consult the interested parties and the relevant stakeholders. When appropriate, you must also seek the views of data subjects and their representatives. Both of these things should be done as needed throughout the process. In addition, consulting relevant experts may be necessary to perform your DPIA. If you choose not to consult any interested party, document why this is justified.

It is vital to seek your DPO’s advice and involve them in the DPIA. If you, for any reason, do not follow your DPO’s advice, you must document this clearly. You must also document the reason for not following your DPO’s advice and who decided not to follow their advice. To learn more about DPOs, you can read our article Data Protection Officer (DPO) guide.

In addition, the steps discussed above must be documented clearly. Furthermore, it is important to document who approved the measures and any residual risks.

It may be necessary to repeat the DPIA steps as the project progresses. Therefore, it is also important to document who will review the DPIA.

If you identify a high risk, you should mitigate it using appropriate measures, as discussed above. If mitigation is not possible, you should consult the relevant supervisory authority. When assessing what appropriate measures you can perform, available technology and the cost of implementation should be considered.

What is the DPIA threshold analysis?

Not every project requires a full DPIA. A DPIA threshold assessment is a short documented screening exercise used to decide whether the planned processing is likely to result in high risk.

It should briefly describe the processing, the categories of personal data, the individuals affected, the scale of the processing, the technologies used, the key risk indicators and the conclusion. If a full DPIA is not required, the organisation should still record why.

This is particularly useful for product changes, new vendors, analytics features, employee monitoring tools, customer scoring, integrations, platform migrations and new uses of existing data.

A good threshold assessment is short, factual and repeatable. It should help teams decide whether to proceed with ordinary privacy review, carry out a full DPIA, or escalate the issue for legal, security or management input.

A mature organisation would automatically reflect on the need for a more thorough impact assessment when changing its products or processes. This reflection should always be documented. The risk consists of (i) the actual and relevant risk of something going wrong while using personal data and (ii) the potential consequences to the concerned individuals.

On one axis, there is the risk of the event materialising, from negligible to high, and on the other axis, there is the event’s impact, from negligible to high.

Is the DPIA confidential?

The DPIA is as much a process as it is a final document. While identifying risks and mitigating the harm to data subjects, the drafts contain highly sensitive classified information. It is important to keep this documentation confidential and to follow your organisation’s procedures for processing this information. It is often not wise to email this documentation, but preferable to share it in a dedicated file share with restricted access on a need-to-know basis.

An approved DPIA may need to be shared with a supervisory authority if requested. Customers, partners or controllers may also ask to review relevant parts of a DPIA as part of procurement, audits or contractual governance. For that reason, organisations should write DPIAs so they are robust, accurate and shareable where appropriate, while still protecting sensitive technical, security and commercial information.

Who should conduct a DPIA?

The most useful DPIA is one that is owned by the team closest to the change. In practice, this means that the product, system, process or procurement owner should normally initiate and drive the DPIA, supported by legal, privacy, security, procurement and other relevant stakeholders.

For technology businesses, the product manager often has a particularly important role. The product manager is usually the person best placed to connect the business objective, user impact, technical design, supplier dependencies, data flows and launch timeline. This makes the product manager a natural coordinator of the DPIA process, even if legal or privacy specialists support the analysis.

The role should not be to “outsource” privacy risk to legal. Rather, the product manager should help ensure that the right questions are asked early, that the relevant teams contribute, and that agreed mitigations are actually reflected in product design, vendor selection, documentation and go-to-market planning.

Ideally, the DPIA should be integrated into ordinary business and development processes, including:

• product discovery and feature design;
• change management and release planning;
• procurement needs analysis and RFP processes;
• vendor onboarding and security review;
• business case development and management approval; and
• post-launch monitoring and lifecycle management.

This makes the DPIA part of how the organisation makes decisions, not a separate legal exercise added at the end.

Who signs off on a DPIA?

Accountability for the DPIA rests with the controller. Internally, sign-off should follow the organisation’s governance model and delegated authority.

In practice, the product, system or process owner should normally own the DPIA and the implementation of agreed measures. Legal, security, privacy and procurement should support the assessment. The DPO, when appointed, should advise on the process and outcome but should not be treated as the business owner of the risk.

Where residual risk remains high, or where the processing is strategically important, sign-off should be escalated to an appropriate management forum, such as a privacy, security, compliance or risk committee.

In mature organisations, or when the DPIA concerns a critical element, the product owner initiates and provides an action plan for successful implementation, while the compliance board accepts or rejects the risks. The compliance committee should have representation from the highest level of management (i.e., the board) and reflect the organisation’s strategic objectives. Hence, many compliance committees have representations from sales, product, CEO, and CFO. The CIO, Head of HR, and Head of Legal are invited on a need-to-know basis. The DPO or senior privacy counsel serves as an advisor on the DPIA process and provides a recommendation to the compliance committee on adopting the proposed use of personal data and managing any residual risks.

What is the risk of not performing a DPIA?

Failing to carry out a DPIA when one is required creates several risks.

The point is not to produce paperwork for its own sake. The point is to make sure the organisation has understood the risk, made informed decisions and can explain those decisions if challenged.

2026 update: EU DPIA template

In 2026, the European Data Protection Board published a draft DPIA template for consultation. The aim is to make DPIA documentation more consistent across the EU and to help organisations structure and evidence their assessment process.  

The template does not change the legal test under Article 35 GDPR, but it is a useful signal of what regulators expect to see in a mature DPIA process: a clear description of the processing, necessity and proportionality assessment, risk assessment, mitigation measures, stakeholder involvement, final decision and follow-up actions.

For organisations operating across several EU markets, aligning internal DPIA templates with the emerging EDPB structure is likely to make future reviews, audits and regulator interactions easier.

Making DPIAs operational

The best DPIA is the one done early enough to matter, or maintained and updated when necessary throughout the product’s/system’s/process’s life cycle management.

For technology businesses, DPIAs should be built into the ordinary way products, systems and supplier arrangements are developed. They should sit close to product development, procurement, security review, contract negotiation and management sign-off.

That does not mean slowing projects down. A well-run DPIA process should help teams identify the real issues quickly, agree proportionate controls and document the decision in a way that can withstand customer, board or regulator scrutiny.

At Sharp Cookie Advisors, we help technology-focused businesses design DPIA processes that are practical, commercially aware and aligned with GDPR expectations. We support clients with DPIA threshold assessments, full DPIAs, supplier and product reviews, high-risk processing assessments, DPO and management briefings, and remediation plans where privacy risks need to be reduced before launch.

The goal is not paperwork. The goal is better decisions, fewer surprises and a defensible route to market.