> For the complete documentation index, see [llms.txt](https://docs.oomus.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oomus.org/compliance/legal-compliance.md). # Legal compliance This page presents the legal compliance framework for Oomus CampaignID and the measures in place to comply with applicable personal health data regulations. *** ## Applicable regulatory frameworks ### GDPR principles Oomus CampaignID applies the **principles of the General Data Protection Regulation (GDPR)** of the European Union as a best-practice reference, even for deployments outside the EU. These principles represent the most demanding standard for personal data protection. ### National regulations — West Africa Programs deployed in ECOWAS countries must comply with applicable national laws. The main reference frameworks include: | Country | Law / Authority | Reference | | ----------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------ | | **Senegal** | Law No. 2008-12 on the protection of personal data | Personal Data Protection Commission (CDP) | | **Côte d'Ivoire** | Law No. 2013-450 relating to the protection of personal data | National ICT Regulatory Authority (ARTCI) | | **Mali** | Law No. 2013-015 on the protection of personal data | National Commission for Information Technology and Civil Liberties (CNIL Mali) | | **Burkina Faso** | Law No. 010-2004/AN | | | **Guinea** | Digital Code of the Republic of Guinea | Post and Telecommunications Regulatory Authority | > It is the responsibility of the organization deploying Oomus CampaignID to ensure compliance with the applicable national legislation. The Oomus team can support this process upon request. ### African Union Convention on Cyber Security and Personal Data Protection (Malabo Convention) The **Malabo Convention** (2014) establishes an African continental framework for the protection of personal data, including health data. Oomus CampaignID is designed to be compatible with the requirements of this convention. *** ## Scope of compliance ### Data minimization Oomus CampaignID collects **only the data necessary** for generating, distributing and verifying health cards: * Last name, first name, date of birth, sex (for MPI deduplication) * Phone number (if SMS/WhatsApp distribution) * Program data (card type, campaign, issue date) Full medical records, raw biometric data, and personal financial data are not collected. ### Purpose limitation The data collected is used exclusively to: 1. Generate digital health cards 2. Distribute cards to beneficiaries 3. Enable verification of card authenticity 4. Build and maintain the sovereign MPI identity registry They are not used for commercial purposes, profiling, or advertising targeting. ### Access control Access to beneficiary data is controlled by the institutional RBAC system: * Only authorized program users can access the data * Access is limited to the defined geographic and functional scope * Every action is logged in the immutable audit trail ### Data security Data is protected by: * AES-256-GCM encryption for sensitive data at rest * HTTPS/TLS for all communications * bcrypt hashing for passwords * Non-reversible opaque QR tokens *** ## Data subject rights ### Right of access A beneficiary may request access to the data concerning them from the responsible health program. The program manager can use the MPI interface to export a beneficiary's data. ### Right to rectification A beneficiary's data can be corrected via the MPI interface ("MPI Registry" section) or via the API `PATCH /mpi/{mpi_id}`. Corrections are recorded in the audit trail. ### Right to be forgotten Deletion of an MPI identity may be requested via Oomus support. The identity is then deactivated, and associated cards are revoked. ### Right to object A beneficiary may object to the generation of a card or request its revocation through the responsible health program. *** ## Responsibilities — Shared responsibility model ### Oomus CampaignID (processor) As **data processor**, Oomus CampaignID undertakes to: * Process data only according to the client program's instructions * Implement appropriate technical and organizational measures * Notify the client program within 72 hours in the event of a security incident * Allow and facilitate compliance audits * Not subcontract data processing without the client program's agreement ### Client organization (controller) As **controller**, the client health program is responsible for: * Obtaining the beneficiaries' legal consent according to applicable local law * Defining the purposes and legal basis of processing * Informing beneficiaries of their rights * Complying with reporting obligations to local data protection authorities * Defining data retention periods in accordance with local regulations *** ## Data breach notification In the event of a security breach affecting personal data: 1. **Detection** : Oomus CampaignID notifies the client program within **72 hours** of becoming aware of it 2. **Notification content** : nature of the breach, data involved, measures taken, contact point 3. **Notification to authorities** : it is the client program's responsibility to notify the competent data protection authority if required 4. **Informing beneficiaries** : if the breach presents a high risk, the client program informs the beneficiaries concerned *** ## Responsible disclosure If you discover a security vulnerability in Oomus CampaignID: 1. **Do not exploit** the vulnerability 2. **Contact** the security team: `ceo@oomus.org` 3. **Describe** the vulnerability in sufficient detail for reproduction 4. **Allow** a reasonable correction period (90 days) We commit to: * Acknowledge receipt within **48 hours** * Assess the vulnerability within **7 days** * Fix critical vulnerabilities within **30 days** * Inform you of the fix and, if you wish, mention you in our acknowledgment notes *** ## Data Processing Agreement (DPA) For programs requiring a **Data Processing Agreement (DPA)** formalized — particularly for deployments involving EU nationals or partners requiring GDPR compliance — contact the Oomus team at ****. *** ## Next steps * [AI & Ethics](/compliance/ai-ethics.md) * [Data Protection](/security/data-protection.md) * [Security overview](/security/overview.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.oomus.org/compliance/legal-compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.