A council publishes a breach log that redacts names but leaves unique case IDs that readily re-identify individuals when combined with other public records. How should this disclosure be assessed?
Select an answer to reveal the explanation.
Short Explanation
Blacking out the name but leaving a unique case ID is like hiding the name tag and shouting the locker number. If people can still be picked out, you haven't really anonymised the story. Re-identification risk still matters for 'redacted' releases.
Full Explanation
Publishing a breach log that redacts names but leaves unique case IDs can still identify individuals when those IDs are linkable to other public records. Re-identification risk from residual identifiers means the disclosure can remain a confidentiality and security problem even after names are removed. Anonymisation requires that persons are not identifiable by reasonably available means—not merely that given names are blacked out.
Any redaction of given names does not automatically make a publication anonymous and risk-free. Unique case IDs can themselves be personal data when they single people out. Article 15 does not require controllers to publish live identifiers in public breach logs; access rights and public transparency reports are different exercises.
Exam caveat: anonymisation is a linkability risk assessment, not a find-and-replace of first names. Operational check: apply true anonymisation, aggregation, or strong pseudonymisation with controlled keys before public release; review join paths against other municipal open-data sets; legal and privacy review public incident summaries. Civic transparency about breaches should illuminate institutional learning without creating a second disclosure harm to the same residents.