Compliance Matrix
A side-by-side view of how AWRA OpsHub supports customers subject to the Kenya Data Protection Act, GDPR & UK GDPR, POPIA, the Nigeria NDPA, and HIPAA-aligned safeguards for operational health data.
Built for procurement leads, DPOs, Information Officers, and internal legal reviewers who need to compare posture across jurisdictions without stitching together five separate documents.
Rows describe common regulatory obligations. Columns describe how AWRA supports customers under each regime. Where regulators impose different timelines or artefacts, the matrix shows the most stringent applicable path.
AWRA OpsHub is a processor for customer-owned records and a controller for account and platform-level data. The DPA sets out both roles; this matrix maps the operational realities that reviewers usually verify.
Regulatory frameworks
Each framework below links to the sections most often cited during due diligence. If you operate under a different regime — Uganda DPPA, Rwanda Data Protection Law, Tanzania PDPA, Egypt PDPL — the same controls extend with region-specific templates.
Kenya · ODPC oversight
Governs personal data collected or processed in Kenya, enforced by the Office of the Data Protection Commissioner. Applies to controllers and processors regardless of where they are established when the data subject is in Kenya.
EU / EEA · United Kingdom
The general regulation for EU/EEA data subjects and the UK equivalent, supervised by national DPAs and the UK ICO. Applies to any organisation processing EU or UK personal data, including via extraterritorial reach.
South Africa · Information Regulator
The Protection of Personal Information Act 4 of 2013, enforceable since July 2021. Introduces an Information Officer duty, mandatory processing conditions, and cross-border transfer safeguards.
Nigeria · NDPC oversight
The Nigeria Data Protection Act 2023 replaces the 2019 regulation. Establishes the Nigeria Data Protection Commission, mandates DPO appointments for major processors, and formalises data subject rights and breach reporting.
United States · Health data
AWRA OpsHub is a business-operations platform, not a HIPAA-covered clinical system. We provide HIPAA-aligned safeguards for customers processing limited protected health information in operational, procurement, or administrative workflows and support Business Associate discussions on request.
Side-by-side matrix
Scroll horizontally to compare regimes. Reviewers commonly copy this table into vendor risk assessments — the matrix is designed to answer procurement, DPO, and Information Officer questions in one pass.
| Control area | KE-DPA Kenya Data Protection Act 2019 | EU-UK-GDPR GDPR & UK GDPR | ZA-POPIA POPIA (South Africa) | NG-NDPA Nigeria NDPA 2023 | US-HIPAA HIPAA-aligned safeguards |
|---|---|---|---|---|---|
| Legal basis & lawful processing | Configurable consent, contract, legal obligation and legitimate interest bases; consent capture logged with timestamp, source, and version. | Full Article 6 basis set supported. Sensitive data requires explicit consent workflow and separate audit trail. | Processing conditions 1-8 supported through role scoping, purpose tags on data categories, and processing-purpose banners at capture. | Lawful bases aligned to NDPA §25; sensitive personal data flows gated by explicit consent controls and additional access approvals. | Minimum-necessary access enforced; PHI-flagged fields limited to authorised roles with justification-required access prompts. |
| Data subject rights (access, erasure, portability, objection) Verified in code 2026-08-05 | What exists is an export and an erasure, each keyed on a user account — a machine-readable export of everything held against a login, and an erasure that cascades. There is no request-intake queue and no SLA clock; a Section 26 request is worked by your own people using those two tools. | Read the unit carefully, because it is the whole answer. The Regulation counts data subjects; our tooling counts user accounts. Article 15 and 17 are served for anyone who has a login. For a person who does not — an employee record with no linked account, a customer who is a natural person — there is no one-click export, and their data has to be assembled by hand. Articles 16, 18 and 21 have no dedicated workflow at all: no rectification queue, no restriction flag, no objection register. | Sections 23-25 are served by the same two tools, with the same limit: a data subject who holds no login is outside their reach. No POPIA-specific request templates and no Information Officer routing are built. | Section 34 rights rest on the same account-keyed export and erasure. No NDPC response templates, no countersign workflow. | An individual with a login can be exported and erased. 164.524 access and 164.526 amendment for a person who is a record rather than a user is manual work, and there is no PHI-specific chain of custody beyond the general audit log. |
| Cross-border transfer safeguards | Transfers outside Kenya rely on adequacy determinations, appropriate safeguards, or explicit consent per Section 41; transfer register maintained per customer. | Standard Contractual Clauses (2021 EU set, UK Addendum / UK IDTA) offered in the DPA; TIA guidance and supplementary measures documented. | Section 72 supported via SCC-equivalent contractual protections or adequacy where recognised by the Information Regulator. | Transfers under §41-42 covered by contractual safeguards and, where required, NDPC-notified mechanisms. | Business Associate Agreement available for eligible use cases; onward disclosures logged and restricted to permitted purposes. |
| Data residency & hosting region Verified in code 2026-08-05 | Region is a property of the DEPLOYMENT, not of your organization. One region serves every organization on a given deployment, and it is chosen by us. A region-specific commitment means a separate deployment, which is a commissioned piece of work with a price rather than an onboarding checkbox. | There is no EU-only mode you can be switched into. The sub-processor register is a single list that applies identically to every organization — it cannot be filtered to EU-region providers for one of them, and it currently includes US-region providers for AI, push notification and payment functions. | Same answer as above and for the same reason: residency is a deployment decision. We will put it in a contract; we will not describe it as a setting, because it is not one. | Not configurable per organization. Where an NDPC-driven residency commitment is required, it is met by a separate deployment and priced as one. | US-region hosting is available as a deployment. Encryption keys are not segregated per organization — data is encrypted at rest with a single key per deployment, so key separation also means a separate deployment. |
| Breach notification timeline | ODPC notified within 72 hours of becoming aware; affected data subjects notified without undue delay per Section 43. | Supervisory authority notified within 72 hours (Article 33); data subject notification when high risk (Article 34). | Information Regulator and affected data subjects notified as soon as reasonably possible after discovery (Section 22). | NDPC notified within 72 hours where required; affected subjects informed without undue delay under §40. | Notification of breaches of unsecured PHI within 60 days; annual summary for breaches under 500 individuals. |
| DPO / Information Officer support | AWRA appoints a Data Protection Officer registered where required and supports your DPO with review-ready evidence packs. | Article 37 DPO designation supported for your organization; escalation contact provided in the DPA. | Information Officer role model documented; deputy Information Officer appointment supported. | DPO appointment supported for Data Controllers of Major Importance; contact routed to a named escalation owner. | Privacy Officer and Security Officer roles mapped to AWRA governance owners for BA-scope engagements. |
| Records of Processing (RoPA) | Processing register template pre-populated with AWRA-side processing purposes; customer extends with organization-specific activities. | Article 30 records template covering categories of data, recipients, retention, and transfer safeguards. | Section 14/17 documentation supported via the same processing register with POPIA-specific fields. | RoPA-equivalent documentation supported for NDPA §29 record-keeping obligations. | Accounting of disclosures log available on request for PHI-tagged records (164.528). |
| DPIA / risk assessment support | DPIA template covering high-risk operations aligned to Section 31 and ODPC guidance. | Article 35 DPIA template with lawful basis mapping, necessity/proportionality reasoning, and mitigation matrix. | Prior authorisation and risk assessment guidance for operations covered by Section 57. | Data protection impact assessment guidance provided for high-risk processing under NDPA §28. | Security Risk Assessment guidance aligned to 45 CFR 164.308(a)(1)(ii)(A). |
| Sub-processor governance | Sub-processor register published and versioned; material changes notified with reasonable opt-out window. | Article 28 sub-processor list with change notifications and objection process defined in the DPA. | Operator obligations under Section 21 flowed down through contractual controls with each sub-processor. | Downstream processor obligations flowed down; NDPC filings supported where the customer is designated a DCMI. | Business Associate agreements maintained with each sub-processor handling PHI; downstream flow-down enforced. |
| Retention & deletion | Retention schedules configurable per record category; hard delete workflows verified with dependency map and audit trail. | Article 5(1)(e) storage limitation supported through per-object retention policies and automated purge jobs. | Section 14 retention limits enforced through the same retention schedule with POPIA-tagged categories. | Retention aligned to NDPA principles; customer-defined retention overrides logged with owner attribution. | PHI retention aligned to state law and BA agreement; secure disposal follows 164.310(d)(2) media re-use controls. |
| Security controls (encryption, access, logging) | TLS 1.2+ in transit, AES-256 at rest, role-based access with MFA, tamper-evident audit log covering user, admin, and system events. | Article 32 measures documented in the Security Whitepaper; pseudonymisation supported at field-level for high-risk categories. | Section 19 security safeguards implemented via technical controls, admin routines, and staff confidentiality obligations. | Technical and organisational measures aligned to §39 with configurable admin controls per organization. | Administrative, physical, and technical safeguards mapped to 164.308/310/312 for BA-scope engagements. |
| Automated decisioning & profiling | Automated decisions requiring human review are flagged and routed through an approval queue; opt-out available per Section 35. | Article 22 human-review controls, meaningful information about logic, and objection workflow supported. | Section 71 rights covering automated decision-making respected; manual intervention path documented. | Automated processing safeguards aligned to §37 with review and objection paths available to data subjects. | AI-assisted operational routines exclude PHI-driven adverse determinations without documented human review. |
| Special-category / sensitive data handling | Sensitive personal data (Section 44) requires explicit consent workflow, elevated access approval, and category-specific audit tag. | Article 9 special categories gated by explicit consent, safeguards, and separate audit trail. | Section 26 special personal information gated by prohibition-then-exception workflow with elevated approval. | Sensitive personal data (§30) requires explicit consent or another authorised basis with elevated logging. | PHI-tagged fields restricted to minimum-necessary roles with justification-required access. |
What "verified in code" means, and what the unmarked rows mean
Two rows carry a verification date: data subject rights and data residency & hosting region. Every claim in them was checked against the codebase on 5 August 2026, and both were corrected as a result — one described a per-organization residency and key-separation option that is in fact a property of the deployment, the other described request workflows that exist for user accounts and do not exist for people who are records rather than logins. The corrected text is what is above.
The other eleven rows have not been through that check. They describe posture in good faith and some of them are demonstrably backed by running code — retention and deletion, for instance, is a scheduled job rather than an intention — but they have not been line-by-line verified, and until they carry a date you should read them as a starting point for questions rather than as a warranty. If a specific row decides your procurement, ask us and we will audit that row and publish the result the same way.
This matrix reflects platform posture at time of publication and is provided for information purposes. It is not legal advice — consult your DPO, Information Officer, or external counsel for jurisdiction-specific determinations.
Africa adjacency
Our regional customers frequently operate across multiple African jurisdictions. The following regimes are supported with the same operational controls plus region-specific templates and escalation contacts.
Uganda DPPA 2019
Aligned to Kenya DPA controls; Uganda-serving organizations use the same DSR queue with UG-specific templates.
Rwanda Law No. 058/2021
RURA-oriented residency and DPO support available on request for Rwandan public-sector engagements.
Tanzania Personal Data Protection Act 2022
Data protection commission notification workflow supported through the same breach playbook.
Egypt PDPL 2020
Cross-border transfer safeguards and residency options extended to Egyptian customers on request.
When an organization operates under multiple regimes, AWRA applies the most stringent applicable rule at each control area — the highest bar becomes the floor.
DSR SLAs default to the shortest window in scope. Retention defaults to the shortest retention permitted by any applicable regime.
Breach playbooks default to the fastest notification requirement across regulators the organization is subject to.
Reviewer workflow
The most efficient procurement teams treat multi-regime compliance as a single control library, not four parallel audits. Here is how our customers typically operationalise the matrix in the first thirty days.
First-thirty-days path
List every region where you collect, store, or process personal data — including customer, employee, and supplier records.
Confirm which party is the controller and where AWRA sits in each flow; align contractual duties.
Decide hosting region, transfer mechanisms, and any residency addenda required by your regulator.
Tailor timelines, escalation contacts, and audit tags to match the most stringent applicable regime.
Adjacent evidence
We provide tailored compliance packs for procurement teams evaluating AWRA against a specific regulator's questionnaire. Share your framework and jurisdictions, and we will assemble the mapped evidence.
Request a Regional Compliance PackHelp Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
