What is a data processing agreement?
A data processing agreement, or DPA, is a contract about personal data. It is signed between the organization that decides why and how data is used (often called the controller) and the company that handles the data for it (the processor).
When you use cloud software for staff records or beneficiary lists, your NGO is usually the controller. The vendor is the processor. The DPA sets out what the vendor may and may not do with your data.
Terms differ by country and law. Treat this article as a plain guide, not as legal advice. Some laws use other words, such as “data controller” and “data processor”, or “data handler”. The idea is the same: one party decides, and the other acts on its behalf.
A DPA is not needed for every tool. A calendar that holds no personal data does not need one. A system that holds staff files, beneficiary lists or complaint records does.
Why does an NGO need one?
Handing data to a vendor does not hand over your responsibility. You remain accountable to the people in the data, to regulators where they apply, and to donors. A DPA lets you show that you chose a vendor with care and that the vendor accepted clear duties.
Many donors and partners ask for a DPA, or for proof that your suppliers have signed one. It is much easier to collect it at the start than to chase it before an audit. Our article on data protection basics lists other steps to take alongside it.
What does a DPA usually contain?
| Part | What it answers |
|---|---|
| Subject and purpose | What data, about whom, and why the vendor processes it |
| Instructions | The vendor acts only on your documented instructions |
| Security | What measures protect the data |
| Staff | Duty of confidentiality for people with access |
| Sub-processors | Which other companies handle the data, and how you are told of changes |
| Transfers | Whether data leaves a country or region, and on what terms |
| Breach notice | How fast the vendor tells you about a breach |
| Help with requests | How the vendor helps you answer people’s requests |
| End of contract | Return or deletion of data |
Not every DPA looks the same. Use the table as a reading guide. Some vendors put these parts in a main contract and some in a separate document. Either way, make sure the pieces are signed and kept together.
A few terms deserve a second look. “Sub-processor” means another company the vendor uses to run the service, such as a cloud host. “Transfer” means data going to another country, including viewing it from abroad. “Breach” means loss, theft or exposure of data. If the DPA uses these words without defining them, ask for a plain explanation.
What should you check before you sign?
- Does it match what the vendor does? Compare the purposes in the DPA to the real service.
- Is the security description specific? “Appropriate measures” alone is weak. Look for named controls.
- Is there a list of sub-processors? You need to know who else is involved.
- Is the breach notice time written down? Hours or days, not “promptly”.
- Is the exit clear? You should be able to export data and have it deleted, with a stated timeline for backups.
- Are AI features covered? If the service sends data to an AI provider, the DPA or its list should say so.
- Is the location stated? See what data residency means.
If a clause is unclear, ask the vendor to explain it in writing, and keep the reply with the contract. If you can, ask your legal adviser or a trusted partner to read the DPA once. A short review before signing costs less than a dispute later.
What do you keep doing after signing?
Signing is not the end. Put these tasks in your calendar:
- Save the signed DPA with the service contract and its date.
- Check the sub-processor list once a year, and read notices of change.
- Review the DPA when you add a new type of data, such as health or child protection records.
- Check the exit terms before the contract ends, and plan the export early.
Your board or a donor may ask for the file. A folder with the contract, the DPA and your notes answers that in minutes.
Where EMPOBase fits
EMPOBase makes DPA terms available on request, along with a sub-processor list and security questionnaire responses. Use the privacy route for DPA terms and the security route for technical controls. EMPOBase is hosted on Google Cloud in the Singapore region, does not sell customer data and does not use customer content to train models. AI features can send prompts and selected context to an AI provider, so ask us to confirm the processing arrangements for your use. See the privacy page or contact us to request the DPA.