Data protection in a resettlement register: obligations nobody assigned

A PAP register holds, for several thousand people, their names, household composition, exact location, income, land claims, identity documents, photographs, often biometrics, and the amount of money each is about to receive. It is one of the more sensitive datasets any project assembles, and it is routinely emailed as a spreadsheet.

The obligations exist whether or not anyone assigned them

Most jurisdictions in the region now have data protection legislation with the familiar structure: a lawful basis for processing, purpose limitation, data minimisation, accuracy, retention limits, security obligations and breach notification, with a supervisory authority and penalties.

A resettlement register is squarely within it, and the obligations sit with the implementing agency as data controller regardless of who built the system. Confirm the applicable law and any registration requirement early — this is one of the few compliance areas where the timeline is set by someone else's process.[2]

The register is not a project deliverable that happens to contain names. It is thousands of people's personal data that happens to be useful to a project.

Concrete harms, not abstract ones

• Targeted theft. A list of who is being paid what, and when, is an operational document for anyone inclined to rob them.
• Family conflict. Publishing what an individual received can expose them to claims from relatives, and in some settings to violence.
• Opportunistic claims. Detailed asset records circulating locally invite fabricated competing claims.
• Retaliation. Grievance records identifying complainants, if visible to the people complained about, end the mechanism's usefulness immediately.
• Political exposure. In some contexts a list of who lives where, with ethnicity or origin recorded, is dangerous in ways that have nothing to do with the project.

Disclosure versus privacy

Resettlement has a genuine tension here. Public display of the draft register is one of the strongest anti-fraud and inclusion mechanisms available — communities correct omissions and identify ghosts. It also publishes personal data.[3]

The workable resolution is to split what is displayed from what is held. Display names and parcels, which is what allows objection and correction. Do not display amounts, income, household composition or identity numbers. Disclose the individual entitlement privately to the person it concerns. That satisfies both the objection process and the duty not to expose people by publishing what they are about to receive.[4]

Practical minimums

1. Role-based access. Enumerators should not see payment data; payment staff should not export identity records; grievance handlers should see complainant details only for their own cases.
2. No bulk export to personal devices. The most common breach in this field is a full copy of the register on a consultant's laptop.
3. Encryption in transit and at rest, including on field devices, which are lost and stolen routinely.
4. Access logging, so that who read what is answerable.
5. Explicit consent for photographs and biometrics, recorded, and with a practical alternative for anyone who declines.
6. A retention position that survives project closure — the register must be kept long enough to answer a complaint years later, which is a lawful purpose, and that period should be stated rather than indefinite.

What to tell people at enumeration

A short, plain statement, in the local language, given verbally as well as on the form: what is being collected, why, who will see it, how long it will be kept, and how to ask for a correction. It takes a minute and it is the part of a data protection regime that the people concerned actually experience.[1]

It also has a practical benefit. Households that understand why detailed income questions are being asked answer them more accurately, and the baseline the whole monitoring framework depends on gets better.