What counts as sensitive program data?
Sensitive data is information that could cause harm if it reached the wrong person. In program work this often includes:
- names linked to a need, such as a health condition or displacement,
- photos and video of people,
- GPS coordinates of homes or shelters,
- identity documents and registration numbers,
- safeguarding, protection and complaint records,
- case notes and referral details,
- staff health and disciplinary records.
A name alone may look harmless. A name plus a location plus a vulnerability can put someone at risk. Think about harm to the person, not only about rules. A useful test is to ask what would happen to the person if a neighbor, an official or an armed group saw the record. If the answer is serious, treat the record as restricted.
How do you classify data?
Use three or four levels and keep them simple.
| Level | Example | Basic handling |
|---|---|---|
| Public | Published reports | Share freely |
| Internal | Meeting notes, budgets | Staff only |
| Confidential | Beneficiary lists, staff files | Named roles only |
| Restricted | Safeguarding cases, protection data | Very few people, logged access |
Write the level in the policy, and train staff to ask one question before they share: “What level is this?”
What should you do before you collect?
Most protection is decided at collection.
- Ask what you need. For each field, name the decision it supports. Remove fields with no answer.
- Prefer codes to names when a code is enough for the work.
- Explain to people in their language what you collect, why, who sees it and how long you keep it.
- Think about location. A coarse location, such as a village, may do the job better than exact coordinates.
- Plan for refusal and for children. People must be able to say no without losing help, unless the data is truly needed. Ask whether a guardian must agree for a child, and keep photos of children to a minimum.
A short example helps. A country office runs a cash program in two districts. The first form asks for full name, ID number, phone, home GPS point and household health details. After review, the team finds that the payment only needs a name, a phone number and a district. They drop the rest. Fewer fields means a smaller leak if something goes wrong, and less to protect, store and delete.
How do you store and share it safely?
- Limit access by role. Give sensitive records only to the roles that need them.
- Keep one master copy. Copies on laptops, phones and email multiply the risk. Our article on data protection basics covers the wider picture.
- Avoid email attachments and chat apps for sensitive files. A shared, controlled space lets you remove access later; an attachment cannot be taken back.
- Remove names before analysis when you only need counts.
- Check what you publish. A public page, report or map can reveal more than you meant. Review it before it goes out.
- Protect devices. Use a screen lock, and report lost phones at once.
- Plan for staff turnover. When someone leaves, remove their access to sensitive records first, before other accounts.
- Talk about it. Short team sessions, with real examples, change habits better than a long policy nobody reads.
What about data you share with partners and donors?
Decide in advance what each partner receives. Write it in the partnership agreement: which fields, for what purpose, how long, and what happens at the end. Share the minimum, preferably summaries or coded data. When an auditor or donor needs to see records, give scoped access for a fixed period and remove it afterwards, which is safer than sending files. See our article on giving auditors access.
When should you delete?
Set a retention time for each level and review on a fixed date each year. At the end of a project, remove personal details that no one needs, and keep only what donors and local law require. Record the deletion, with the date and the person who did it. Treat paper copies and exported spreadsheets the same way; they are the files most often forgotten. Laws differ by country, so check the periods with a qualified adviser.
Where EMPOBase fits
EMPOBase holds records such as a beneficiary registry, incident reports and Safeguarding & PSEA cases, and you control who sees them with roles and permissions. Private uploads need authorization before a time-limited download link is made. Treat beneficiary names, photos, GPS points and identity documents as sensitive, and confirm the access, retention and redaction controls your program needs. Public sharing features have different access rules, so check what will be visible before you publish. Read more on the privacy page.