Why does a registry need extra care?
A registry lists real people, often at their most vulnerable. It may show who receives aid, where they live, and sometimes their health, ethnicity or status. In the wrong hands, that information can lead to theft of aid, discrimination, pressure or physical danger.
A registry also does good. It helps you plan, avoid gaps, follow up, and show who you reached. The aim is to get the benefits while keeping the risks low.
What data should you collect?
Start from what you will use. For each field ask: what decision does this help, and can we do without it?
| Field | Usually needed? | Care level |
|---|---|---|
| Unique ID number | Yes, to avoid repeats | Medium |
| Name | Often | Medium |
| Sex and age band | Often, for disaggregation | Medium |
| Location | Often, at a coarse level | Medium to high |
| Household size | Often | Low |
| Disability status | When it guides service | High |
| Ethnicity, religion, political views | Rarely; avoid unless essential | Very high |
| Phone number | Only if you will contact people | High |
Highly sensitive items need a clear purpose and tighter access, or should not be collected at all. Our article on disaggregating by sex, age and disability helps you decide what breakdowns you really need.
How do you set up the registry step by step?
- Define the purpose. Write down why you keep it and what it is not for.
- Choose the minimum fields. Remove any you cannot justify.
- Explain to people. Say in their language what you collect, why, and who sees it. Record their agreement as your policy and local law require.
- Assign unique IDs. An ID lets you work with less personal detail.
- Set access by role. Few people need to see names and contact details.
- Store it securely. Use protected systems, not loose files on personal devices or messaging apps.
- Set retention. Decide how long you keep it, and who deletes it.
Who should see the registry?
Apply the “need to know” rule.
- Registration staff add and correct records.
- Program staff see what they need for their activity.
- MEAL staff see data for monitoring, often without names.
- Managers see summaries.
- Partners and donors see aggregated figures unless a clear agreement allows more.
Log who can see what, and review the list when people change roles or leave. Remove access straight away when someone leaves.
How do you handle sharing, errors and requests?
- Sharing. Have a written agreement that states the purpose, the fields, the protection and the deletion date. Check local law on sharing personal data.
- Corrections. Let people ask for errors to be fixed, and do it.
- Removal. Decide how you respond when someone asks to be removed, within the limits of law and your donor rules.
- Repeats. Check for duplicate records. Unmatched duplicates inflate your totals. See why reach totals may count the same person twice.
When should you delete the data?
Keep data only as long as you need it for the stated purpose and for any legal or donor retention rule. Then delete it or make it anonymous, so no one can tell who it describes. Write the retention period and the deletion step into your policy, and assign an owner. Old data you forgot about is a risk with no benefit.
A short example shows the “minimum data” rule in use. A project gives seeds to farming households. The team first thinks of collecting name, age, sex, ethnicity, religion, phone number, land size and household income. They then ask what each is for.
- The seed list needs an ID, household size and village.
- The monitoring plan needs the sex and age band of the household head, for disaggregation.
- Land size is useful to decide the seed amount, so it stays.
- Ethnicity, religion and income do not guide any decision, so they go.
- Phone number is kept only for households that agreed to follow-up calls.
The registry is now smaller, quicker to fill in, and less risky. If it were lost, it would reveal far less about the people in it. Review the field list each year and remove anything that has stopped being useful.
Where EMPOBase fits
EMPOBase has a Beneficiary registry in its Field Reporting module, and access depends on organization and permission checks. Data is hosted on Google Cloud in the Singapore region, uses HTTPS/TLS and Google-managed encryption at rest, and is never resold; see the security page and privacy page for details. EMPOBase totals are counts of records, and nothing deduplicates beneficiaries. The choice of fields, the consent wording and the retention period remain your decisions, under your local law.