Separating personal data from management reporting

Give managers the measures they need, not the personal records used to calculate them. Start with the management question, build a reporting view at the least detailed level that answers it, and keep identifying fields and record-level access in a separately controlled path.

Decide what the report needs to show

For each question, record the decision it supports, the reporting period, groups compared and the smallest useful level of detail. A service manager might need weekly case volumes by team. That alone does not require names, contact details or individual case notes in the management model.

List direct identifiers and fields that might identify someone in combination. A customer ID, precise location, rare job role or narrow date range can make a row recognisable to a reader who has other information. A person may remain reasonably identifiable after names are removed; a small aggregate or combination of filters can pose the same problem.

Build a separate reporting product

One pattern pairs a restricted operational dataset for authorised case work with a management dataset of approved measures and only the dimensions needed for decisions. Document that dataset's population, exclusions, refresh point and owner. Keep any key that reconnects rows to a person out of the general view unless the connection has an approved purpose.

For a workforce report, a manager might see monthly staffing totals by function while an authorised HR analyst uses a separate restricted dataset to investigate a particular record. Those uses need different audiences and controls. Whether the Privacy Act applies to a particular employee record practice requires its own assessment; an exemption does not itself make broad access a sound reporting choice.

A separate model reduces routine exposure only if its other access routes respect the boundary. Check who can build from it, open detailed tables, receive scheduled output and export records. Hiding a personal field on a report page does not remove it from the underlying model.

Review identification risk in the output

Before releasing the view, examine plausible filter combinations in the intended audience's context. Could a team, date and unusual event identify one person? Could someone match the result with a roster or another available dataset?

If so, consider broader periods or groups, fewer dimensions, suppression of risky breakdowns or a narrower audience. No universal cell size resolves every case.

Record the audience and output reviewed. Revisit the decision when a field, filter, join or audience changes. A view suitable for one management group may be unsuitable for wider distribution. Separating datasets does not by itself make the management output de-identified.

For entities covered by the Australian Privacy Act, the Australian Privacy Principles govern relevant uses and disclosures of personal information and require reasonable security steps.

Australian Privacy Principles: Key Requirements