Posture: how we handle your data.
Data is the raw material, and the liability. MIHZI processes personal data only where it is necessary for the work, and we encode agreed controls into the architecture and contract—not as unverified marketing absolutes. This page is the stance clients audit us against.
Registered on both sides of the data.
Under Rwanda's data-protection law (Law N° 058/2021), MIHZI holds active registration as both a data controller and a data processor, so we can run a client's data on instruction, and operate our own platform lawfully.
For the data we determine the purpose and means of: our own business operations, security telemetry, and platform governance.
For data we process strictly on a client's documented instruction, under a Data Processing Agreement, with the client as controller.
Six controls, built in not bolted on.
MIHZI supports managed, customer-cloud, on-premises, and hybrid deployments. The agreed architecture determines where raw data, derived features, scores, logs, backups, support access, and sub-processors are stored and processed. Residency, isolation, retention, and audit commitments are documented per engagement and verified before production use.
- Data minimization
- We process only what is required for service delivery, model development, and compliance for the agreed purpose. Scope is set per engagement and enforced at ingest. Available by design / contract.
- Anonymization · pseudonymization
- Pseudonymized at ingest where the model does not need identity. Re-identification is gated behind contractual review and logged when it happens. Available by design / contract.
- Encryption · in flight & at rest
- Transport and storage encryption controls are selected and documented per environment. Specific cipher suites and key custody are evidenced during security review for that deployment—not asserted as a universal public claim here.
- Access controls · audit logs
- Role-based access with attribute scopes. Audit events and retention are defined in the engagement control map so reviewers can reconstruct who saw what, when. Documented per engagement.
- Sovereignty · residency
- Where an in-country or customer-boundary requirement exists, the deployment is verified against that requirement rather than assumed from the edge location. Replicas, backups, logs, and support access are included in the map.
- Contractual safeguards
- DPAs, sub-processor disclosure, breach-notification clocks, and model-use restrictions for sensitive sectors, written into the engagement.
From ingest to clean exit.
Every dataset we touch follows the same four-stage path, and the last stage is as designed as the first.
When something goes wrong, and how we prove it didn't.
Two things clients ask first: what happens in an incident, and what they can independently verify.
A defined runbook with breach-notification clocks written into each DPA. We detect, contain, assess, and notify: the controller first, then authorities and data subjects as the law requires.
- Detect & contain
- Assess scope & impact
- Notify within contractual clock
- Remediate & post-mortem
Tamper-evident logs and a documented control set mean a client's risk or compliance team can reconstruct activity and attest to it. We support client audits and provide our sub-processor list on request.
- Reconstructable audit trail
- Documented control mapping
- Client audit support
- Sub-processor disclosure
The legal detail lives next door.
This page is the stance; the binding detail (purposes, legal basis, retention, and data-subject rights) sits in our data policy. For a copy of our registration certificates or a security questionnaire, reach us at info@mihzi.com.