Data Processing Agreement
Last updated: [Effective Date]
Template for legal review
This document is a drafting template, not a lawyer-vetted agreement. Have it reviewed by qualified legal counsel — for Ethiopia, counsel familiar with the 2024 Personal Data Protection Proclamation and Ministry of Health rules — before relying on it. This document is drafted in the style of a HIPAA Business Associate Agreement, adapted for Ethiopia's 2024 Personal Data Protection Proclamation — it is not a substitute for either statute and does not itself certify compliance with them.
This Data Processing Agreement (“DPA”) supplements the Terms of Service between Atlas (“Processor”) and [Hospital Name] (“Controller”), and governs Atlas's processing of Patient Data on the Controller's behalf. In the event of conflict between this DPA and the Terms on data protection matters, this DPA controls.
1. Roles and scope
The Controller determines the purposes and means of processing patient information entered into or generated by the Atlas platform (“Patient Data”) and is the controller for purposes of Ethiopia's Personal Data Protection Proclamation (2024) and, where applicable, HIPAA-equivalent obligations the Controller owes as a covered healthcare provider. Atlas is the processor (business associate): it processes Patient Data only to provide the Service and only on the Controller's documented instructions, which include the configuration choices the Controller makes in the platform (roles, retention, module enablement) and the terms of this DPA.
2. Instructions
Atlas will process Patient Data only as necessary to provide, secure, support, and improve the Service, and will promptly notify the Controller if an instruction appears to violate applicable data-protection law, so the Controller can revise it.
3. Security obligations
Atlas will maintain administrative, technical, and physical safeguards appropriate to the sensitivity of Patient Data, designed to support (not certify) HIPAA-style and Ethiopian data-protection security expectations, including:
- tenant-isolated database schemas so no workspace can query another's data;
- encryption in transit (TLS) and encrypted local storage for the Offline Client;
- role-based access control enforced on every clinical action;
- an audit log of record access and changes, retained and reviewable by the Controller;
- remote revocation/wipe for lost or decommissioned offline devices;
- salted password hashing, signed/expiring session tokens, and standard account-security practices (rate limiting, session expiry).
4. Personnel
Atlas limits access to Patient Data to personnel who need it to provide or support the Service, binds them to confidentiality obligations, and provides them data-handling training appropriate to their role.
5. Sub-processing
Atlas may engage sub-processors (see the sub-processor list in the Privacy Policy) to provide infrastructure, messaging, or payment functions, and will impose data-protection obligations on them equivalent to this DPA. Atlas remains responsible for its sub-processors' performance. Atlas will give the Controller reasonable advance notice of a new sub-processor material to Patient Data processing, so the Controller may object on legitimate data-protection grounds.
6. Data location and cross-border transfer
Patient Data is hosted on Atlas's own infrastructure, expected to be an AWS region in Cape Town, South Africa (af-south-1), or an equivalent regional facility Atlas designates in writing. Hosting Patient Data outside Ethiopia is a cross-border transfer under the Personal Data Protection Proclamation; the Controller is responsible for completing its own due-diligence and any regulatory notification the Proclamation requires before go-live, and Atlas will provide the information reasonably needed for that assessment (security documentation, sub-processor list, this DPA).
7. Breach notification
Atlas will notify the Controller without undue delay, and in any case within [X hours/business days — to be confirmed with counsel] of becoming aware of a confirmed security incident involving Patient Data, describing the nature of the incident, the data affected, and remediation steps taken or planned, so the Controller can meet its own breach-notification duties to patients and regulators.
8. Assistance with rights requests
Because patients direct their rights requests (access, correction, restriction) to the Controller, Atlas will give the Controller the platform tools and reasonable support needed to locate, export, correct, or restrict a patient's record within the Controller's workspace.
9. Audit rights
On reasonable written notice (and no more than once per year absent a suspected incident), the Controller may request evidence of Atlas's compliance with this DPA — such as security documentation, audit-log samples for its own workspace, or a summary of a third-party security assessment — or engage an independent auditor under mutual confidentiality terms. Audits are scheduled to avoid disruption to other Providers' workspaces, consistent with tenant isolation.
10. Deletion and return on termination
On termination of the underlying agreement, Atlas will, at the Controller's election, export Patient Data in a structured format or delete it, and will delete any remaining copies (including backups) within a reasonable retention window thereafter, except where retention is required by law. Offline Client devices tied to the workspace will be revoked so they can no longer sync or access Patient Data.
11. Liability
Liability under this DPA is subject to the limitation-of-liability terms in the Terms of Service, except to the extent a data-protection law makes such limits unenforceable for the type of harm involved.
12. Precedence and term
This DPA takes effect alongside the Terms of Service and remains in force for as long as Atlas processes Patient Data on the Controller's behalf, surviving termination of the Terms to the extent needed to complete deletion/return obligations under Section 10.
