Data Processing Agreement
Last updated: 8 October 2026 · Version: 2026-10-08
This is the further agreement contemplated by clause 6.3 of the Merchant and API Terms. It applies where you give us personal information about your own customers — a recipient's name, address and phone number — so that we can deliver to them.
It is an integral part of the Merchant and API Terms and prevails over them on data protection.
1. Who is who
1.1. For your customers' details that you send us, you are the controller and we are the processor. You decided to collect them and why; we handle them to carry out the delivery you asked for.
1.2. For everything else, we are our own controller. Driver records, the ledger, fraud checks, safety records, the accounts we are required to keep — those are ours, decided by us, and this agreement does not make them yours.
1.3. Where the same information sits in both categories, each of us is responsible for its own use of it.
2. What is processed
Subject matter and purpose — carrying out deliveries you book, keeping you informed about them, keeping your customer informed about theirs, and keeping the records the law requires of a transport operator.
Duration — for as long as you have an account with us, and afterwards for as long as Annex 1 says.
Categories of data subject — the people you send parcels to, and the people at your business who use the portal.
Categories of personal data — name; delivery address and location; phone number; email where you give one; the contents description you provide; the amount to collect where it is cash on delivery; delivery events, proof of delivery and any photograph taken at the door; messages exchanged about the delivery.
Special categories — none are requested and none should be sent. Do not put health, biometric or similar information in a parcel description or a delivery note. If you do, you are the controller of it and you warrant you have a lawful basis.
3. What we will do
3.1. Only on your instructions. We process your customers' details to perform the Merchant Terms and this agreement, and otherwise only on your documented instruction — unless the law requires otherwise, in which case we will tell you before we act on it, unless the law forbids that too.
3.2. Confidentiality. Everybody at Thuma with access is under a duty of confidence, and access is limited to those who need it for their work. Every staff action in our console is recorded against the person who took it.
3.3. Security. The measures in Annex 2, which are the ones actually in place rather than a description of an ambition.
3.4. Sub-processors. The list in Annex 3. We may add or replace one on 30 days' notice to you; if you reasonably object on data protection grounds within that time, we will work with you on an alternative and, failing one, you may terminate the affected service without penalty. Every sub-processor is bound by obligations no weaker than these.
3.5. Your customers' rights. If somebody asks us for their information, to correct it or to have it deleted, and they are your customer, we will point them at you and tell you. We will help you answer, at no charge for a reasonable volume.
3.6. A breach. If we become aware of a personal data breach affecting your customers' details, we will tell you without undue delay and in any event within 72 hours, with what we know, what we are doing and who to speak to. We will not wait until we have the whole picture.
3.7. Deletion or return. At the end of your account, we will delete your customers' details or return them, at your choice, except for what we must keep — see Annex 1. Backups age out on the cycle in Annex 1 and are not restored to serve a request.
3.8. Showing our work. We will give you the information you reasonably need to show your own compliance, and allow an audit no more than once a year, on 30 days' notice, in working hours, at your cost, by you or an independent auditor under confidence — or a recent report where one answers the question.
4. What you must do
4.1. You warrant that you may lawfully give us what you give us, and that your own customers have been told their details will be passed to a delivery provider.
4.2. You will not send us more than the delivery needs. An address, a name and a number make a delivery; a customer file does not.
4.3. Your instructions to us must be lawful. We may refuse an instruction we believe would put either of us in breach, and will say why.
5. Where the data is
5.1. Processing takes place in Amazon Web Services' Cape Town region (af-south-1), in South Africa.
5.2. Some sub-processors in Annex 3 process outside Africa. Where that involves a transfer that requires a safeguard, the safeguard is the relevant provider's standard contractual clauses or an adequacy decision, and we will tell you which on request.
6. Law
6.1. This agreement is governed by the law of Zimbabwe and, in particular, the Cyber and Data Protection Act [Chapter 12:07].
6.2. Where you are established in, or offer goods or services into, the European Union or the United Kingdom, this agreement is intended to meet the requirements of Article 28 of the UK/EU GDPR, and is to be read accordingly.
6.3. If any term here is found unenforceable, the rest stands.
Annex 1 — How long things are kept
| What | How long | Why |
|---|---|---|
| Delivery record (addresses, events, proof of delivery) | 7 years | Transport and tax records |
| Photograph taken at the door | 12 months | Disputes about delivery |
| Messages about a delivery | 24 months | Disputes and safety |
| Cash-on-delivery amounts and remittances | 7 years | Accounting records |
| Portal user accounts at your business | Until removed, then 12 months | Audit of who did what |
| Identity documents and the decisions made on them, where we check a person's identity | 5 years in Zimbabwe and South Africa, 10 years in Zambia | Financial-crime law in each country, which sets its own period |
| Backups | 35 days, rolling | Recovery |
Where a dispute, a claim or an investigation is live, the records relating to it are kept until it is closed.
The identity row is a legal hold and not our choice. It runs from the country whose law applies to the person checked — determined by the phone number they signed up with — and it outlasts a deletion request, including one you make on their behalf. It applies only where we actually check somebody's identity: a delivery recipient is not identity-checked, so nothing in this row touches the people you send parcels to.
Annex 2 — Security measures
The measures in place, in plain terms. The fuller version, kept current, is the Security Overview in the portal.
- In transit — TLS 1.2 or better on every connection, no exceptions for
internal traffic.
- At rest — encrypted database storage and encrypted object storage.
Documents (identity, proof of delivery) live in a private bucket and are reachable only through short-lived signed links.
- Card details never reach us. Card fields are the processor's own frames
on the processor's own domain; no card number touches a Thuma server, log or laptop. Our PCI scope is SAQ-A.
- Access — role-based, least privilege, and scoped to the markets a person
works in. Two-factor authentication is required for staff, enrolled at first sign-in rather than optional.
- Audit — every permitted staff action in the console is written to an
audit record with the person, the permission, the path and the time.
- Money — the ledger is append-only. Entries are never updated or deleted;
a correction is a new balancing entry, so the history cannot be rewritten.
- Secrets — held in AWS Secrets Manager, never in the repository or an
image, and rotatable without a code change.
- Change control — every change goes through review and an automated gate
set that must pass before it can ship.
- Dependencies — reviewed on a schedule, with the reasoning recorded for
anything accepted rather than fixed.
What we do not claim. We do not hold SOC 2 or ISO 27001 certification. We have not yet commissioned an independent penetration test. Saying so is part of the point of this document: the list above is what exists, not what is planned.
Annex 3 — Sub-processors
| Who | What they do | Where |
|---|---|---|
| Amazon Web Services | Hosting, database, object storage, email delivery | South Africa (af-south-1); email delivery may route via other AWS regions |
| Stripe | Card payments and subscriptions | Ireland / United States |
| Twilio | One-time codes and messages by SMS and WhatsApp | United States, with regional routing |
| Maps, addresses and route estimates; push notifications to devices | United States | |
| Amazon Rekognition | Automated identity document and face checks, where enabled | South Africa (af-south-1) |
| Anthropic, PBC | Reading documents sent to ThumaBooks and writing the words of a Brief, under zero data retention: nothing is kept once the model has answered, and nothing is used to train a model (the ThumaBooks AI Policy) | United States |
Smile Identity was on this list and should never have been. It was named as an identity sub-processor in Kenya and South Africa on the strength of an integration that was designed and then abandoned in favour of Amazon Rekognition, which runs in our own AWS account in South Africa. No customer's identity information has been sent to Smile Identity: no released version of the Platform has contained a client capable of sending it, and the API credential such a client would require has never existed in any Thuma environment. Removing the row is a correction of this document, not a change of supplier — see the note above about what this annex is for.
We use no advertising or analytics processor that receives your customers' details, and we do not sell or share them.
Rendered from thuma_backend/legal/dpa.md.
The wording there is the original; this is a readable copy.