Two Questions Rather Than One Label
First ask whether information concerns an identifiable person. Then ask what harm its exposure or use could cause in this context. Removing a name answers neither question by itself.
The ICRC Handbook, third edition, sections 2.2-2.3 distinguishes identifiable people, pseudonymized records and anonymized data. A code replacing a name does not establish anonymity. The OCHA Data Responsibility Guidelines 2025, Annex A, printed pages 40-41, also distinguishes non-personal data in a sensitive context. Operational information can create group or safety risks without naming anyone.
Classify the Fictional File
This invented exercise concerns a temporary service in an unnamed fictional area. The entries illustrate reasoning. They are not actual records, a validated sensitivity scale or a safe-publication checklist.
| Proposed Entry | Identifiability Question | Separate Harm Question |
|---|---|---|
| A person's name and requested appointment | The entry directly concerns a recognizable individual | Could exposure reveal a private service use, enable unwanted contact or affect access? |
| Participant code, exact appointment time and small settlement | Could someone with a schedule, local knowledge or another file connect the record to a person? | A code does not remove possible harm if the record remains linkable |
| Weekly total for a large service area | Does the level of detail still allow identification when combined with other information? | Could a pattern reveal a sensitive movement or a group receiving a stigmatized service? |
| A repair contractor's warehouse opening hours | Is any individual identified or indirectly identifiable in the actual entry? | Could publication expose supplies, staff routines or a facility to theft or attack? |
| A general description of how an appointment system works | Check whether examples, screenshots or hidden details expose anyone | A safe explanation may answer the question without transferring the original file |
Do not turn this table into a declaration that all totals are safe or all operational data are secret. The answer depends on detail, context, combination with other data, likely recipients and consequences. A large area can still contain a small identifiable subgroup. A precise location may be unnecessary even when a count is useful.
Why Aggregation Can Still Leave a Problem
Suppose an invented table contains a total for a whole area and separate totals for every settlement except one. A reader may be able to derive the omitted settlement's figure by subtraction. Hiding one cell is not enough if surrounding information reconstructs it. This is a reasoning example, not a recommended disclosure-control technique or a universal minimum group size.
The team should state what an outsider could combine, what remains uncertain and who has the expertise to assess disclosure risk. Do not test identifiability by uploading a real file to an unapproved external service. Make a safe synthetic example if you need to explain the issue.
Turn Classification Into a Working Decision
For each proposed use, record the necessary fields, audience, purpose and applicable organizational classification. Ask the responsible data and protection roles to resolve ambiguous personal or sensitive information. If the purpose can be met with a broader explanation or an independently checked aggregate, compare that option with sending the underlying records.
Keep a separate permission question beside the classification. A file can contain low-sensitivity information and still have use or license restrictions. A sensitive file does not become shareable because a partner already has a login. See access, reuse and publication.
Use the privacy and data-risk screen to record the proposed flow and unresolved review. Classification supports a decision; it does not provide a legal basis, a security certification or permission to publish.