Trigger, Decide, Evidence: A DPIA Reassessment Matrix for UK Change Control
Photo: Internet Archive Book Images, No restrictions, via Wikimedia Commons
A data protection impact assessment is often treated as a gate that is passed once and then filed. In practice, the risk profile of a service changes when a vendor is added, an AI feature is switched on, a data-sharing arrangement is revised, retention is extended or a system is migrated. Without a change-control route, the DPIA describes the service as it was at approval, not as it operates.
The decay problem
Change control usually focuses on cost, delivery and security. Privacy reassessment is often triggered by memory or by the presence of a DPO in a project meeting. The result is predictable: some changes receive a fresh assessment, others receive a note in a ticket, and many receive nothing. The organisation cannot easily show why a decision was taken or who accepted the residual risk.
A trigger matrix does not replace judgement. It gives teams a consistent starting point and a record of the decision. The matrix should be embedded in the change process, not kept as a separate privacy document.
A trigger matrix for common UK change events
| Change event | Typical examples | Default DPIA decision | Sign-off route | Evidence |
|---|---|---|---|---|
| New vendor or processor | Cloud analytics, payment provider, outsourced contact centre | Screening review; refresh if new data categories, purposes or transfers are introduced | DPO and business owner | Vendor risk assessment, updated ROPA, screening note |
| AI feature or model change | Automated triage, recommendation engine, generative assistant | Refresh required before deployment | DPO, product owner and information security | Updated DPIA, model description, oversight plan |
| New data-sharing arrangement | Charity partner, research body, group company | Refresh required | DPO, legal and business owner | Data-sharing agreement, DPIA addendum, ROPA update |
| Retention change | Extended customer history, new archive, reuse of old data | Screening review; refresh if retention is extended or data is reused | DPO and records manager | Retention schedule, DPIA addendum |
| System migration | Platform replacement, hosted service move, access model change | Refresh required if data flows, access or location change | DPO, IT owner and security | Migration plan, data-flow map, DPIA refresh |
The matrix should be reviewed annually and whenever a new class of change emerges. It is deliberately simple: teams need to be able to apply it under delivery pressure and explain the outcome to an auditor.
From trigger to decision
The matrix produces one of three outcomes. First, no change to the DPIA may be appropriate where the change is administrative and does not alter processing, risk or data flows. The decision should still be logged. Second, a screening review may be needed where the impact is unclear or limited. The reviewer records the questions asked and the conclusion. Third, a DPIA refresh is required where the change introduces new purposes, new data categories, new recipients, new transfers, new automated decision-making or a material change in risk.
A refresh does not always mean starting from scratch. It may be an addendum, a revised section or a reissued assessment. What matters is that the current version reflects the current processing and that the rationale for the decision is retrievable.
Worked example: AI-assisted triage
A customer service team proposes an AI-assisted triage feature within an existing platform. The feature will score incoming enquiries and route them to specialist queues. The change ticket is raised by the product owner. The data governance lead applies the matrix and identifies two triggers: AI feature and vendor product change.
The screening review asks whether the feature introduces profiling, whether it affects vulnerable customers, whether the vendor processes personal data outside the UK and whether human reviewers can override the routing. The conclusion is that a DPIA refresh is required because the feature changes how decisions about service priority are made and introduces a new vendor model.
The refresh is signed off by the DPO, product owner and information security. Evidence includes the change ticket, the screening note, the updated DPIA, the sign-off record and a monitoring plan for the first three months. The next review date is set for six months or earlier if the model changes.
Ownership: a RACI-style model
| Activity | Change initiator | Product owner | DPO | Data governance lead | Information security |
|---|---|---|---|---|---|
| Raise change request | R | A | I | I | I |
| Apply trigger matrix | C | C | C | R | C |
| Approve screening outcome | I | A | R | C | C |
| Refresh DPIA | C | R | A | C | C |
| Sign off residual risk | I | A | R | C | C |
| Record evidence | C | C | C | R | C |
| Review monitoring | I | A | C | R | C |
R = responsible, A = accountable, C = consulted, I = informed. The model should be adapted to the organisation's size, but the principle is that the business owns the change and the DPO owns the privacy judgement.
Evidencing reassessment decisions
Maintain a DPIA change log. A useful minimum data set includes the change reference, the trigger row applied, the decision, the rationale, the sign-off, the date and the next review date. Report quarterly on the number of triggers received, refreshes completed, overdue actions and any changes that were screened out. This turns the DPIA from a one-off document into a live governance instrument and gives the board a proportionate view of privacy risk in change.
The matrix should be tested periodically against real change tickets. If teams are bypassing it, the problem is usually the process rather than the principle. Make the route short, the decision options clear and the evidence requirements realistic. A DPIA that is reassessed at the right moment is more valuable than a longer assessment that is never revisited.
