← Resources

Release review · Experiment #001

How should you assess identification risk before sharing record-level data?

By Nakato editorial · Published 2026-10-07 · Prepared with AI · Reviewed 2026-10-07 · Codex automated source review. No human or legal review represented.

Assess the proposed release, its recipient and its intended task together. Inventory direct identifiers and combinations that could distinguish a person; consider information available for linkage; then test both the transformation and the recipient's required analysis. Record the remaining risks, controls and review decision before delivery. A removed name or a successful utility test alone does not establish that a release is anonymous.

What release are you actually reviewing?

Create one review record for a specific dataset version, intended recipient and purpose. State which fields the recipient needs, how delivery will work, who can access the result, and whether onward sharing is permitted. If the recipient, scope or access conditions change, reopen the assessment.

NIST SP 800-188 asks government agencies to consider goals, disclosure risks and the sharing model before choosing de-identification. Its models include published data, synthetic data, query interfaces and protected enclaves. This article adapts that technical framing for a release review; it does not declare any route legally sufficient.

Sources: NIST · De-Identifying Government Datasets: Techniques and Governance

Which details could identify someone together?

Start with obvious identifiers, then inspect combinations and narrative context. A job role, location, event date and unusual history may deserve review together even when each field seems ordinary. Ask what the intended recipient could link to its own holdings or accessible information. Record uncertainty rather than assuming that untested combinations are safe.

NIST IR 8053 reports that some de-identified data has been re-identified. That supports checking residual identification risk; it supplies no universal threshold and no guarantee about this dataset.

Sources: NIST · De-Identification of Personal Information

How can you compare privacy changes with task utility?

Write the recipient's task and acceptance criteria before choosing a transformation. Keep a change log explaining what was removed, grouped or substituted and why. Run the intended analysis on an appropriately controlled reference and the proposed release. Examine errors at the level that matters to the task, including small groups or unusual cases where relevant.

Treat utility and identification risk as separate review questions. A useful output can still expose information; an aggressively transformed output can fail the intended task. Document both decisions, the test version and the reviewer responsible for accepting the remaining uncertainty.

What would a hypothetical release review look like?

Illustration only: imagine a recipient needs monthly service-demand totals by broad region. The proposed records contain a person's name, exact appointment date, small locality and free-text notes. No real customer data or measured outcomes appear in this example.

Candidate A removes names but retains precise dates and narrative details. The review asks whether the remaining combinations are linkable. Candidate B groups dates to months, broadens geography and reviews narrative details. The task review asks whether these changes still support monthly regional totals and whether exceptions need a restricted route.

Neither candidate is approved by this illustration. The next step is a documented test on the actual release and recipient context. Grouping can lose detail; retaining detail can preserve risk. The example's contribution is the paired decision record, not a claimed risk reduction or benchmark score.

What belongs in the delivery decision?

  • dataset and transformation versions
  • recipient and permitted task
  • direct and contextual identifier inventory
  • linkage assumptions and unresolved risks
  • utility method and acceptance criteria
  • access and onward-sharing controls
  • named decision owner
  • review date and triggers for reopening.

If the evidence cannot support the proposed delivery, narrow the fields, task or recipient access, choose a different sharing route, or defer release. Keep the reason visible. This is an editorial workflow recommendation, not a certification that a dataset is anonymous or a finding that Nakato meets a particular standard.

What changes when the release has a UK context?

UK note: the ICO's anonymisation guidance assesses identifiability in the circumstances of the release, including potential singling out, linkage and inference. As checked on 7 October 2026, the page says it is under review following the Data (Use and Access) Act. Recheck it before relying on a UK legal interpretation. These UK concepts are not presented as US legal requirements.

Sources: ICO · How do we ensure anonymisation is effective?

What can this checklist establish?

It can make the review assumptions, proposed controls and unresolved questions inspectable. It cannot establish an unmeasured privacy outcome, prove regulatory compliance or compare vendors. No Privacy Index score, Presidio benchmark, product performance figure or customer result is used here. The underlying sources have different dates and scopes, and the worked example is hypothetical.

Which sources and limitations apply?

Where can you explore the next decision?