Data handling and retention overview
What information is handled, how it is used, and how long it is kept.
Account and profile data
Account identity, contact details, county, and optional demographic fields support sign-in, support routing, and anonymized aggregate analytics.
Case and incident data
Reports, timeline events, assignment states, severity, and coordinator ownership drive the operational response workflow and closure review.
Public-safe aggregate data
Mwananchi and CSV surfaces should expose only anonymized, thresholded, and aggregated insight that cannot be traced back to a person or case.
Expected data-use boundaries
Safety, coordination, recordkeeping, and anonymized analytics.
- Demographic fields such as gender and optional orientation should support anonymized analytics and service understanding, not public identification.
- Location and county data should support routing, referral relevance, hotspot analysis, and emergency context only where necessary.
- Case records should remain inside operational dashboards and should not appear in public analytics or open exports.
- Uploaded files, supporting evidence, and event timelines should remain attached to governed operational workflows and not leak into civic-facing surfaces.
Retention posture
Different types of information follow different lifecycles.
Shorter-lifecycle product data
Session, preference, and routine product telemetry should be retained only as long as needed for security, debugging, and product operation.
Operational case records
Incident, assignment, and case records should follow a formal retention schedule based on safeguarding, legal, and partner obligations rather than indefinite storage.
Public datasets
Public releases should be regenerated from governed aggregates and should avoid retaining raw case-linked identifiers entirely.