Skip to content

Privacy Impact Review

Pre-disclosure review — instantiates Role-Scoped Disclosure Minimization

A pre-release assessment that maps what a source record actually contains and what a recipient could infer or re-identify from a proposed disclosure, before the disclosure is designed.

A Privacy Impact Review is the assessment step that runs before any shaping is chosen: it inventories what the source record actually holds and reasons about what a recipient could infer from a proposed disclosure — not just which fields are obviously sensitive, but what the released subset gives away indirectly and what it becomes when joined with data the recipient already has. Its defining move is to look at disclosure as an inference problem, not a field-selection problem: the risk isn't only the columns you send, it's what those columns reveal in combination and in context. The review produces no shaped data and enforces nothing; it produces the understanding — the map and the risk findings — that tells the shaping mechanisms what to remove, mask, or coarsen.

Example

A transit agency proposes to share a year of tap-in/tap-out records with a university mobility-research group. Before any file moves, a privacy impact review maps what the dataset holds — card ID, station, timestamp, fare — and asks what a recipient could infer. The finding: origin-destination-time triples are near-unique, so a regular commuter's daily pattern can single them out, and joined with the university's separate residential dataset the trips could be pinned to home addresses. That inference analysis reshapes the release before it's built — pseudonymize card IDs, coarsen timestamps to the hour, suppress rare trips — rather than discovering the exposure after a leak. This is the "assess before you share" logic of a formal data-protection impact assessment.[1]

How it works

  • Map the source. Inventory every field the record actually contains — including derived and free-text fields — so the assessment reasons about the real payload, not the intended one.
  • Model the recipient. Establish who receives it, for what, and crucially what other data they already hold that the disclosure could be joined against.
  • Test for inference and side channels. Ask what the proposed subset reveals indirectly — quasi-identifier uniqueness, re-identification by linkage, timing or ordering leaks — beyond the obviously sensitive fields.
  • Hand findings to the shapers. Output a risk map that tells redaction, masking, or the role view exactly what to remove, coarsen, or suppress, and re-run when the dataset, recipient, or purpose changes.

Tuning parameters

  • Trigger threshold — which disclosures require a review (all of them, or only new, high-risk, or bulk ones); a low bar catches more but taxes routine sharing.
  • Depth — a lightweight screening questionnaire versus a full assessment with re-identification testing; depth catches subtle inference but costs time.
  • Recipient-context scope — assess the fields in isolation versus modelling what the recipient can join them against; only the latter catches mosaic risk.
  • Bindingness — an advisory finding versus a gate that can block or reshape the release; only a binding review actually changes the outcome.
  • Refresh — one-time at design versus re-review when the dataset, recipient, or purpose changes.

When it helps, and when it misleads

Its strength is that it catches the exposures field-level rules miss — the ones that live in combinations and in the recipient's context, where a set of individually innocuous fields re-identifies someone once joined. Because it runs before design, its findings can reshape the disclosure while that's still cheap. Its failure mode is the check-the-box review performed after the decision, to bless a release already chosen — the archetypal running-it-backwards, where the assessment rationalizes rather than tests. It also misleads when it assesses only the fields present and ignores what they can be joined against, or treats a one-time sign-off as permanent as the data and recipients change. The discipline is to run it early enough to bind the design, to model the recipient's outside data explicitly, and to give the review real authority to send a disclosure back.

How it implements the components

  • source_record_map — the review's first product is a true inventory of what the record holds, the baseline every shaping decision is measured against.
  • inference_and_side_channel_review — its core analysis is what a recipient could deduce or re-identify from the proposed disclosure, directly or by linkage, beyond the fields' face value.

It assesses and advises; it does not enforce the shaping — the role window is Role-Based View, removal is Field-Level Redaction, value substitution is Tokenization or Masking — nor record the disclosures that actually occur (Disclosure Audit Log).

Notes

A review is only as useful as its authority: findings that don't bind the design are advice a deadline can overrule. It is deliberately an input — it names the risk but changes nothing by itself — so its value depends on being wired to the shaping mechanisms that act on its map, and on running before the disclosure is committed rather than after.

References

[1] A Data Protection Impact Assessment (DPIA), required under GDPR Article 35 for high-risk processing, is the real institutional form of this review: a structured, before-the-fact analysis of a proposed data use and its risks to individuals, done while the design can still change. ↩