Trust · Data handling · Security posture

Posture: how we handle your data.

Data is the raw material, and the liability. MIHZI processes personal data only where it's necessary for the work, and we encode the controls into the system, not the policy document. This is the stance our clients audit us against.

ResidencyIn-country
EncryptionTLS 1.3 · AES-256
LoggingTamper-evident
RegisteredController + Processor
§ 01 · Registration

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.

Registered · Active
Data Controller

For the data we determine the purpose and means of: our own business operations, security telemetry, and platform governance.

NCSA Rwanda · Year 2026
Registered · Active
Data Processor

For data we process strictly on a client's documented instruction, under a Data Processing Agreement, with the client as controller.

NCSA Rwanda · Year 2026
§ 02 · Controls

Six controls, built in not bolted on.

Each of these is enforced in the platform (in code, configuration, and contract) rather than asserted in a document and hoped for in practice.

01
Data minimization
We process only what's required for service delivery, model development, and compliance, nothing more, nothing "just in case." Scope is set per engagement and enforced at ingest.
02
Anonymization · pseudonymization
Pseudonymized at ingest where the model doesn't need identity. Re-identification is gated behind contractual review and logged when it happens.
03
Encryption · in flight & at rest
TLS 1.3 in transit. AES-256 at rest with managed-key rotation. Hardware-isolated key custody for high-sensitivity tenants.
04
Access controls · audit logs
Role-based access with attribute scopes. Every read, write, and model decision is logged and tamper-evident, so an auditor can reconstruct who saw what, when.
05
Sovereignty · residency
Workloads deployable in-country where regulation requires it. Regional cloud topology by default, with documented transfer mechanisms for anything that crosses a border.
06
Contractual safeguards
DPAs, sub-processor disclosure, breach-notification clocks, and model-use restrictions for sensitive sectors, written into every engagement.
§ 03 · Data lifecycle

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.

01
Ingest
Minimised and pseudonymised at the boundary. Only fields a purpose needs cross into our systems.
02
Process
Encrypted, access-scoped, and logged. Models and agents run over the data under contract.
03
Retain
Held only for the engagement term and the period set in the DPA, on a scheduled review cycle.
04
Return / destroy
At close, data is returned or securely destroyed on the client's instruction, with a clean handover.
§ 04 · Assurance

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.

Incident response

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
Audit & attestation

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
§ 05 · More

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.