One DPIA Review Has Two Mitigation-and-Release Approval Links: Select Authority Before Processing

A duplicate mitigation-and-release approval link is a control problem. The repair is not to pick the newest record or keep both links because each looks valid. Select the approval that covers the exact processing change and its mitigations, then remove the extra edge from the DPIA review.

Keep the affected processing paused while the authority is unclear. The Irish Data Protection Commission describes a DPIA as a way to identify and mitigate data-protection risks early and to make informed decisions about whether those risks are acceptable. That makes scope and recorded reasoning more useful than a link count.

Which approval governs a DPIA review with two valid links?

The governing approval is the one whose recorded decision applies to the same processing change, risk assessment and mitigation set, together with release conditions as the DPIA review. Validity alone is insufficient. A signed approval for a different purpose, dataset, recipient group, retention period, or processing version does not release this change.

Start with the review record. Identify the proposed processing change and the risk record it evaluates. Then test both approval records against those objects. If neither approval covers the current scope, do not select one by inference. Return the DPIA to the privacy approver for a new or amended decision.

The Information Commissioner's Office frames a DPIA process around describing processing, assessing necessity and proportionality, identifying risks and mitigating measures, and concluding the DPIA. Use those elements as the authority test rather than a generic approval status.

• Match the approval to the exact processing-change ID and version.
• Match the approval to the reviewed risk IDs and recorded residual-risk conclusion.
• Match the approval to the mitigation IDs and their conditions and effective dates.
• Confirm the privacy approver had authority for the relevant decision.
• Confirm no later change invalidated an earlier scope or condition.

How should you document the release-authority decision?

Create one release-authority dossier for the repair. It should make the selection reproducible by someone who did not perform the original review. Record both observed links before removing either one, including why the non-selected edge does not govern the current release.

Do not rewrite history. Preserve the removed edge in the audit trail with its original approval ID, relationship type, removal time, remover, and reason. The current DPIA review should show one selected authority, while the change record should retain evidence that the duplicate relationship was investigated.

What applicability tests should decide between the links?

Run the same test against each approval. First, compare scope: personal-data categories, people affected, sources, systems, recipients, geographies, purposes, retention, processing operations, and other material scope details. A broad title or shared project name is not enough.

Next, compare the risk and mitigation chain. The selected approval must reference, or clearly encompass, the risks assessed in the DPIA review and the safeguards required before release. If a mitigation changed after approval, treat the old approval as potentially inapplicable until the responsible privacy approver confirms otherwise.

Finally, compare decision conditions. An approval may authorize a pilot, a limited recipient group, a fixed retention setting, a geographic restriction, or an unmet condition. Keep the release paused when those conditions are unresolved. The Data Protection Commission notes that a DPIA can identify safeguards and support decisions about the acceptability of privacy risks, while residual high risks without mitigating safeguards require consultation with the Commissioner.

• Processing scope: Does the approval name or encompass the exact change?
• Risk scope: Does it address the risks still present after the change?
• Mitigation scope: Are the listed safeguards implemented and evidenced?
• Decision scope: Are all approval conditions met and still current?
• Authority scope: Did the named approver have responsibility for this decision?

Which processing actions must pause or be replayed?

Pause any collection, enrichment, outreach, retention, or sharing action that relied on the ambiguous release decision. Do not assume that a completed operational step becomes authorized because one of two records was valid. The point of the replay is to test the action against the selected approval and its conditions.

For collection, confirm the approved data categories, source, purpose, notice path, and related collection controls. For enrichment, confirm the approved inputs, matching logic, added fields, recipients, and related enrichment controls. For consent-based business outreach, confirm the approved audience, purpose, contact route, suppression handling, and related outreach controls. Do not use the repair as a basis to expand outreach or remove platform controls.

For retention and sharing, retest the approved retention rule, deletion path, recipient, transfer context, access controls, and related sharing controls. The NIST Privacy Framework describes privacy risk management as an enterprise activity for protecting individuals' privacy while organizations build products and services. Use the repaired record to connect the decision to the operating controls that execute it.

• Replay a pending action before it starts if its approval reference changed.
• Reassess a completed action when it ran under an ambiguous release decision.
• Record the affected processing decision ID, result, reviewer, and timestamp.
• Escalate an unresolved residual high risk to the appropriate supervisory-consultation process.

How do you close the repair without creating a new gap?

Remove only the extra approval relationship after the dossier identifies the selected authority. Do not delete the approval record itself unless a separate retention and records process requires it. The repair should reduce relationship ambiguity while keeping the decision history intact.

Run a residual-risk retest after the relationship change. Confirm that the selected approval still covers the current processing version and both that each required mitigation is in place and that the privacy approver accepts the recorded conclusion. If the retest changes the risk conclusion or exposes a missing safeguard, keep the affected processing paused.

The European Commission's Article 29 Working Party DPIA guidelines are dated October 13, 2017. CNIL also states that a privacy impact assessment is required where processing is likely to result in high risk to individuals' rights and freedoms. These sources support a risk-led review process, not a shortcut based on duplicate record links.