When to consider a data protection impact assessment

A data protection impact assessment helps identify and reduce risks to people before processing begins. Consider it early where a proposal is likely to create high risk, including through scale, sensitivity, monitoring or novel use. Record the screening decision even where a full assessment is not required.

Describe the purpose, necessity, alternatives, people affected and possible harm. Consult relevant staff and others where appropriate, then assign mitigation actions. A DPIA should influence the design; it is not simply a form completed after the supplier has been selected and implementation finished.

Screen the proposal while changes are still affordable

Start before the business signs a supplier contract or commits to a technical design. Describe the objective in ordinary language and identify the people who could be affected. New technology is not the only risk indicator: scale, sensitivity, systematic monitoring and consequences for individuals can matter. Use the ICO's screening guidance and record why a full DPIA is or is not required for the particular proposal. ^[1]

Avoid describing the objective as install the chosen product. That makes alternatives difficult to consider. An employer's real objective might be reliable workload planning rather than continuous screenshots of staff activity. Once the purpose is clear, compare less intrusive approaches and the evidence supporting the claimed benefit. The assessment should be able to change the proposal, including a decision that the planned collection is unnecessary.

Describe risks from the person's perspective

Map collection, use, sharing and retention, including supplier and administrator access. Then consider concrete harms: inaccurate decisions, exposure of sensitive information, loss of control or unfair exclusion from a service. Distinguish likelihood from severity. A low probability event with serious consequences may still need substantial attention, while a business inconvenience is not automatically the same as a risk to individual rights.

Identify who may be particularly affected and how they can challenge errors or obtain assistance. If a system produces scores or recommendations, explain who checks them and whether the check can meaningfully change the result. A human who simply approves every output without reviewing evidence does not provide the same safeguard as a trained decision-maker with time and authority to intervene.

Test mitigation rather than listing promises

For each risk, identify a measure, responsible owner and evidence that it works. Access restrictions should name the roles and review process. Data minimisation should identify fields or collection stages removed. A statement that staff will receive training needs a description of the actual decision or behaviour being taught. Separate measures already implemented from those merely proposed for a future release.

Consult relevant technical, operational and privacy staff, and consider consultation with affected people where appropriate. Record disagreements and the reasons for the final decision. If the DPIA identifies high residual risk that cannot be reduced, the ICO guidance addresses the need for prior consultation before processing begins. ^[1] Do not treat a management signature as permission to ignore that unresolved issue.

Carry conditions into procurement and launch

Turn approved safeguards into requirements for the supplier and implementation team. Check whether the purchased plan supports them and whether the settings can be enforced centrally. Link the DPIA to Data processing contracts with suppliers for supplier terms and Employee privacy information where the proposal affects staff. Keep an explicit list of conditions that must be met before real information enters the system.

After launch, test whether the actual processing matches the assessed design. A later feature, integration or broader audience may change the risk. Set review triggers around those changes rather than assuming the original DPIA covers every future use of the product. Keep incident and complaint information available to the reviewer because real experience may reveal harms not anticipated during procurement.

For Data processing agreement review, provide the project brief, data map, screening result and proposed safeguards. Ask for a focused review of necessity, risk and unresolved legal questions. Include the intended launch date so conditions can be incorporated into the delivery plan. The useful outcome is a documented decision supported by workable controls, not a lengthy form completed after the design is already beyond challenge.

Record a launch decision with unresolved conditions

A project can receive conditional internal approval while still needing a particular access control or supplier answer. Give each condition an owner, a completion criterion and a clear consequence if it remains unresolved. Avoid a sign-off page that appears to approve the whole project when an essential mitigation is only planned.

Before launch, compare the delivered system with the design assessed in the DPIA. A late decision to retain raw recordings or connect a wider dataset may change the risk analysis. Keep the resulting decision with the assessment and explain whether further review is needed. The project manager should know which changes can be handled routinely and which require renewed consideration before processing begins.

Illustrative scenario

An employer considers software that scores worker activity from detailed monitoring data. Before purchase, it assesses the need for the scoring, less intrusive alternatives, accuracy and consequences for staff. The review may change the proposal or stop it, rather than merely adding a privacy notice to the original plan.

Preparation checklist

• Screen the proposal before procurement or launch.
• Describe people, information, scale and potential consequences.
• Assess necessity, alternatives and mitigation measures.
• Record approval, unresolved risks and review triggers.