Data Processing Agreements: The Clause Most Ethiopian Contracts Are Now Missing
Almost every organization shares personal data with someone else to get its work done. A payroll provider processes your employees' salary details. A cloud platform stores your customer database. An IT contractor manages your systems. A marketing agency handles your mailing list. In each case, one organization decides why and how the data is used, and another handles it on the first one's behalf.
Ethiopia's Personal Data Protection Proclamation No. 1321/2024, in force since July 2024, has a specific requirement for exactly this situation — and it is one of the most widely overlooked obligations in the entire law. Whenever you engage another party to process personal data for you, the Proclamation requires that the relationship be governed by a written contract containing defined terms. That contract is commonly called a Data Processing Agreement, or DPA. Most contracts currently in force across Ethiopia — vendor agreements, service contracts, supplier terms — do not contain one. This article explains what the law requires, why the obligation falls on you, and what a compliant DPA must address.
A note on context: before this Proclamation, data privacy in Ethiopia rested on a fragmented patchwork — the constitutional right to privacy under Article 26 of the Constitution, and scattered provisions in the Computer Crime Proclamation and the Electronic Transaction Proclamation, with no dedicated regulator to enforce them. The Proclamation changed that, establishing a comprehensive framework supervised by a single authority and arriving alongside Ethiopia's rollout of the Fayda national digital ID. For organizations, this is no longer a soft expectation — it is enforceable law.
Controller and processor: which one are you?
The Proclamation draws a clear distinction. A data controller is the party that, alone or jointly with others, determines the purpose and means of processing personal data. A data processor is a party — other than an employee of the controller — that processes the data on the controller's behalf (Article 2).
In plain terms: if it is your data and your decision how it is used, you are the controller. The vendor handling it for you is the processor. Your organization is almost always the controller in its vendor relationships — and, as we explain below, that is precisely why the compliance burden is yours.
A threshold point: both parties must register
Before turning to the contract itself, one foundational requirement is easy to miss. Under the Proclamation, both data controllers and data processors must register with the supervisory authority before processing personal data (Article 33). The supervisory authority is the Ethiopian Communications Authority (ECA), which maintains the register, investigates complaints, conducts audits, and issues enforcement notices. A certificate of registration is valid for two years and must be renewed, and an organization processing data for several distinct purposes must register each purpose separately. Registration and a proper DPA are complementary: one puts you on the regulator's record; the other governs how you share data once you are.
What the law actually requires of a DPA
The core obligation sits in Article 16 of the Proclamation, under the principle of integrity and confidentiality. Where processing is carried out by a processor on a controller's behalf, the controller is not regarded as complying with the law unless three conditions are met:
The processing is carried out under a written contract. The arrangement must be made or evidenced in writing (Article 16(3)(a)). A handshake, a purchase order, or silence is not enough.
The processor acts only on the controller's instructions. The processor cannot use your data for its own purposes or in ways you have not authorized (Article 16(3)(b)).
The contract imposes security and confidentiality obligations equivalent to the controller's own. The processor must be held, by contract, to the same standard of integrity and confidentiality the law imposes on you (Article 16(3)(c)).
The Proclamation reinforces this. The controller must choose a processor that provides sufficient guarantees in respect of technical and organizational security measures, and take reasonable steps to ensure those measures are followed (Article 16(2)). Both controllers and processors must implement appropriate technical and organizational security measures (Article 17). And anyone acting under the controller's or processor's authority must not process the data except on the controller's instructions (Article 16(4)).
For clients in regulated sectors, this requirement often overlaps with existing rules. Banks and financial institutions, for example, are already required under the National Bank of Ethiopia's IT-related directives to govern service-provider and data-centre relationships through binding written agreements with strict need-to-know access controls. For these organizations, a compliant DPA is not a new burden so much as the convergence of two regimes — data-protection law and sectoral regulation — that a well-drafted agreement can satisfy at once.
Why the obligation falls on you, not the vendor
This is the point organizations most often miss. Under the Proclamation, accountability rests with the controller. Article 52 makes the controller responsible for complying with the law's obligations in respect of any processing undertaken "by him or on his behalf," and requires the controller to be able to demonstrate that compliance. You cannot outsource the liability by outsourcing the data.
The consequences are concrete in three ways. First, when the ECA assesses whether to impose an administrative fine, one of the factors it weighs is whether the arrangement between the controller and processor contained adequate transparency and accountability measures to safeguard the data (Article 59(2)(g)). The presence or absence of a proper DPA is something the regulator looks at directly when deciding your penalty. Second, where a data subject challenges your handling of their data, the burden of proof falls on the controller to show the processing was lawful or fell within an exemption (Article 63) — and you can only discharge that burden if your contract compels the processor to give you the records and cooperation you need. Third, the penalties are significant: processing personal data in contravention of the Proclamation can attract administrative fines, and where an institution is involved, fines can reach up to four per cent of total worldwide turnover of the preceding financial year (Articles 60 and 64).
A missing or inadequate processing agreement, in short, is not a technicality. It is an aggravating factor, an evidentiary gap, and a financial exposure all at once.
What a compliant DPA should contain
Drawing the requirements together, a Data Processing Agreement that meets the Proclamation's standard should, at minimum, address:
Subject matter and purpose — what data is processed, and the specific, limited purpose it may be used for.
The instruction limit — an express term that the processor acts only on the controller's documented instructions and for no other purpose (Article 16(3)(b)).
Security obligations — a commitment to appropriate technical and organizational measures equivalent to the controller's own, reflecting Articles 16 and 17, including, where appropriate, encryption and pseudonymization.
Confidentiality — binding confidentiality on the processor and anyone acting under its authority (Article 16(4)).
Record-keeping and logs — an obligation on the processor to maintain detailed processing logs. This is a distinctive and easily missed feature of the Ethiopian regime: the Proclamation requires logs that record why data was accessed or transmitted, when, by whom, and to which recipients (Article 46), and these must be available to the regulator. A DPA should require the processor to keep logs to this standard and make them available to the controller.
Breach notification — an obligation on the processor to notify the controller without undue delay after becoming aware of a personal data breach (Article 43(3)), so the controller can meet its own duty to notify the Authority — and, where required, affected data subjects — within 72 hours (Articles 43 and 44). In practice, the DPA should set a tight internal deadline (often 24 to 48 hours) for the processor to alert the controller, so the 72-hour clock can be met.
Data localization and cross-border limits — confirmation that personal data collected locally is stored on servers located in Ethiopia (Article 22), and that the processor will not transfer, back up, or route data outside Ethiopia except where the Proclamation's cross-border conditions are met (Articles 18–21). Cross-border transfer of sensitive personal data requires the prior approval of the Authority.
Sub-processing — whether the processor may engage sub-processors, and on what terms.
Return and destruction — what happens to the data at the end of the engagement. The Proclamation gives this a specific contractual hook: the controller must notify the processor when data is to be destroyed, and the processor is then bound to destroy it (Article 50). A DPA should set a clear, time-bound process, ideally with written confirmation of destruction.
Audit and demonstration — the controller's ability to verify compliance, supporting its own accountability obligation under Article 52.
Two further points worth building in where relevant. Where two or more organizations jointly determine the purposes and means of processing, they are joint controllers, and the Proclamation requires them to set out their respective responsibilities by contract (Article 51) — this arises more often than people expect, for example among partners in a shared programme. And where the data involves minors — defined by the Proclamation as data subjects under the age of sixteen (Article 2) — special care is required: a minor's data may generally be processed only with parental or guardian consent, and the Proclamation prohibits its use for profiling or direct marketing (Article 11). A DPA covering data that may include minors should bind the processor against such uses.
What organizations should do now
Three practical steps:
1. Map your processors. Identify every third party that handles personal data on your behalf — payroll, IT, cloud, marketing, professional advisers, sub-contractors. This is the same data-mapping exercise that underpins all data protection compliance, and it tells you where DPAs are needed.
2. Check your existing contracts. Most current vendor and service agreements were signed before the Proclamation and contain no data-processing terms. They need to be reviewed and, in most cases, supplemented with a DPA or a data-processing addendum.
3. Put DPAs in place going forward. Every new engagement involving personal data should include a compliant DPA from the outset. It is far easier to include the right terms when negotiating a contract than to retrofit them after a dispute or an incident.
How we can help
Prime Law advises organizations on practical compliance with the Personal Data Protection Proclamation, including drafting and reviewing Data Processing Agreements and data-processing addenda, mapping controller and processor relationships, advising on ECA registration, and building the wider compliance framework the law requires. Our fixed-fee compliance packages are designed to make this straightforward for organizations of any size.
If you would like your vendor contracts reviewed for data-processing compliance, write to us at info@primelaw.law.
_____________
This article is provided for general information only and does not constitute legal advice. Regulatory requirements and procedures may change; for advice on a specific product or application, please consult qualified legal counsel.
