A Pre-Publication Privacy Checklist for Database Research Datasets

Our CIKM 2015 programme listed security and privacy among the Database Track topics. Publishing research data raises a specific question within that broader field: can another researcher reuse the material without learning private facts about individuals? Database security and privacy meet here, but they address different risks. Access controls may protect a working database while a released extract exposes identifying combinations of fields. This checklist is an editorial decision aid for researchers preparing supporting data, not a new CIKM submission policy.

Identify the ways a record could reveal someone

Begin with direct identifiers such as names, personal email addresses and account numbers. Then inspect quasi-identifiers: information that may identify a person when combined with other sources. Dates, small locations, job descriptions and uncommon events can matter even when no name appears.

Free-text notes and query logs deserve a separate inspection. A search string might contain a phone number or a reference to someone's health. Persistent user IDs can also link activity across records. Inspect export headers and metadata as well as visible columns. Shared codes across separate extracts may reveal more when records are joined.

Consider a fictional row describing a person aged 47, living in a small postcode area, with a rare occupation and an exact event date. No individual exists in this example. Yet a publicly available news report might allow someone to connect those attributes to a real person in a genuine dataset.

Choose a release model that fits the risk

There is no automatic requirement to publish raw person-level records for work to be reproducible. The right format depends on what another researcher must check and how much identifying detail the analysis needs.

Before publishing, compare these options against the scientific purpose. This is a governance decision as well as a technical one:

• a public, de-identified dataset where residual identification risk has been assessed;
• a synthetic dataset for exercising code, with limitations about representing real distributions stated clearly;
• a controlled-access environment that allows approved researchers to analyse protected records;
• aggregate tables or a query interface with safeguards when record-level release is unnecessary.

The final NIST guidance on de-identifying datasets, SP 800-188 published in September 2023, discusses these different sharing models and the need to evaluate disclosure risk. It addresses US government practice; its method choices can inform research governance without automatically establishing the law elsewhere.

Test what remains identifiable

Removing a name reduces one risk but does not establish anonymity. Hashing an identifier may still permit records to be linked together, and a poorly protected mapping can reconnect a pseudonym to a person.

Encryption helps protect stored or transmitted data; authorised access to decrypted records still requires privacy decisions.

Assess whether uncommon combinations identify small groups, whether external datasets could provide missing links and whether repeated releases make the records easier to connect. Document the threat assumptions and who performed the assessment. Assess plausible external registers, likely recipients and the consequences of mistaken assumptions. Revisit the assessment when new linked data appears.

Australia's privacy regulator explains why re-identification risk depends on context and available external information. That is useful methodological guidance, although Australian legal obligations must be checked for the specific project and jurisdiction.

When uncertainty remains substantial, narrow the fields or change the access arrangement. A label such as 'anonymous' should follow evidence of acceptable residual risk, not the completion of a one-click transformation.

Record who may use the data and why

Researchers building on our 2015 conference proceedings may need to inspect earlier methods or reproduce reported findings. Supporting material should therefore come with enough explanation to use it appropriately, even where the underlying records cannot be openly distributed.

Keep release notes short enough to read and detailed enough to audit. State data origin, collection permissions, processing steps, known omissions, permitted uses and restrictions. Identify the person or committee responsible for approving access. Explain how long protected records will remain available and how requests or corrections will be handled.

If code or aggregate results can reproduce the central finding, release those materials separately from sensitive records. Document dataset and code versions so later users do not accidentally compare results produced from different extracts. A data dictionary can describe the meaning and transformations of fields without disclosing protected values. If an independent reviewer needs access to original records, give that reviewer a controlled route rather than distributing a private copy by email. Test the release package itself for hidden worksheets and temporary files.

Make the final decision explicit

Before release, a researcher and an authorised data steward should review the actual material, not just a project description. Use a short go/no-go gate to expose unanswered questions:

• have we searched structured fields, free text and logs for sensitive content?;
• are the proposed users and scientific purpose defined?;
• have we considered linkage with information outside the dataset?;
• can a safer access model preserve the research objective?;
• are permissions, retention and approval responsibilities documented?;
• can someone reproduce the reported method without uncontrolled disclosure?

A failed check calls for further review, revision or a restricted release. It does not necessarily prevent research from being examined. Clear decisions about access and residual risk make a dataset more credible than a public download accompanied by unsupported assurances of anonymity.

24th ACM International Conference on Information and Knowledge Management (CIKM 2015)
Oct 19-23, 2015 in Melbourne, Australia