CLIENT: Isimbi Health Ltd🇷🇼Rwanda

Umurinzi - Cloud Security Posture and Control Mapping Dashboard

Cloud Security Posture Dashboard for a Kigali Healthtech

Designed and built a clickable cloud security posture dashboard for a Kigali healthtech on AWS and Google Cloud: one findings queue checked against the CIS Benchmarks, identity risks and internet exposure in one view, every check mapped to ISO 27001 and SOC 2 controls, and a residency check for Rwandan patient data.

Scope of Work
Product design, UI build and clickable demo
Industry
Cybersecurity / Cloud Security Posture
EnterpriseHealthcare
Compliance & Certifications
Rwanda Law No. 058/2021 (personal data)ISO/IEC 27001:2022SOC 2CIS Benchmarks (AWS, Google Cloud)

Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.

Impact

5 Screens
Clickable end to end

Posture overview, all findings with a quick view panel, a detail page for each of the 28 demo findings, identity risks and exposure with its path view.

18 Checks
Mapped to 22 controls

15 CIS AWS and Google Cloud Foundations Benchmark v3.0.0 recommendations and 3 custom checks, each mapped to ISO/IEC 27001:2022 Annex A controls and SOC 2 criteria under Isimbi's mapping v12.

1 of 38
Residency check on screen

Every store holding Rwandan personal data is checked against the regions in Isimbi's recorded storage authorisation: 37 inside, and 1 analytics bucket in europe-west1 raised to critical.

23 Accounts
Realistic demo data

14 AWS accounts and 9 Google Cloud projects with 28 findings across every status, 22 identity principals, 15 internet exposures and 7 owner teams.

The Problem

Isimbi grew from one AWS account to 23 cloud accounts and projects in three years. Its four-person security team ran open-source scanners by hand once a month, pasted the output into a spreadsheet and argued with teams over which findings were real. Nobody could say how many buckets held patient data or which were public, accepted risks lived in email, and every ISO 27001 surveillance audit and the first SOC 2 Type II window meant three weeks of screenshots.

Our Solution

Umurinzi connects to each AWS account and Google Cloud project read-only, checks every resource against the CIS Benchmarks and puts every failing check in one queue with an owner team, a severity reason and an SLA. Identity risks and internet exposure get their own views, every check maps to ISO 27001 and SOC 2 controls, and stores holding Rwandan personal data are checked against the regions Isimbi is authorised to use.

The Challenge: Posture Across Two Clouds and Two Frameworks

Isimbi runs a telemedicine app, a clinic record system used by about 400 private clinics and an e-prescription and lab-results service across Rwanda, Kenya, Uganda and Tanzania, on AWS in Cape Town and Ireland and Google Cloud in Johannesburg. Every product team had its own accounts, and the security team had to answer for all of them.

Monthly Scans by Hand

Open-source scanners ran once a month and their output went into a spreadsheet. A bucket made public on day two stayed public for weeks, and with no owner team on each finding, every fix started with an argument about whose it was.

Patient Data Nobody Could Locate

Health data is sensitive personal data under Rwanda's Law No. 058/2021, and storing personal data outside Rwanda generally needs an authorisation from NCSA. The team could not say which stores held patient data, which were public, or which sat outside the authorised regions.

Two Frameworks, One Client Mapping

Neither ISO 27001 nor the AICPA says which CIS recommendation evidences which control, so the mapping has to be Isimbi's own and versioned. A SOC 2 Type II report covers how controls operated over a period, so evidence must show state over time, not a screenshot of today.

Accepted Risks Lost in Email

Risks were accepted in email threads and never revisited. Intended exposures such as the marketing website bucket sat in the same list as real leaks, and the board asked every quarter whether things were getting better without getting a straight answer.

Our Approach: From Audit Rules to a Clickable Dashboard

01

Spec and Rules Research

Mapped 8 user roles from the head of security to the external auditor, 32 screens across the staff app, settings and an auditor portal, and the data model for accounts, assets, checks, findings, identity principals, exposures, controls, mappings, risk acceptances, tickets and evidence exports. Wrote down the rules the design follows: Rwanda's Law No. 058/2021 and NCSA storage authorisation, the CIS AWS and Google Cloud benchmarks, ISO/IEC 27001:2022 Annex A, the SOC 2 Trust Services Criteria and the cloud shared responsibility model.

02

Clickable Demo on a Production UI Kit

Built 5 key screens on a production dashboard kit: the posture overview with a 90-day score against the target of 85, KPIs, needs attention and the residency check; all findings with status pills, filters, grouping by finding or by check and a bulk-action bar; finding detail with redacted evidence, the CIS reference, console, CLI and Terraform fixes and mapped controls; identity risks; and exposure with a path view. A scope switcher filters every page by cloud or environment, and actions open their forms and confirm on submit.

03

What a Production Build Adds

Read-only connections through AWS Organizations, AWS Config, the IAM credential report, IAM Access Analyzer and Security Hub, and the Google Cloud Asset Inventory and Security Command Center. Google Workspace or Okta for people and MFA, two-way Jira Cloud or Linear tickets, Slack alerts and SSO. Evidence exports with SHA-256 manifests in S3 Object Lock, a hash-chained audit log, and the remaining screens: accounts and the connect wizard, asset inventory, benchmarks, the control map, risk acceptances, remediation tickets, the board scorecard, trends, settings and the auditor portal.

Why It Works: Every Finding Has a Reason and an Owner

Severity Explains Itself

A finding raised from high to critical says why, for example because the bucket holds patient health data and is internet exposed. The detail page cites the benchmark version, recommendation and level, and gives the fix as console steps, a CLI command and Terraform.

Read-Only by Design

Umurinzi never changes a cloud resource. It uses an AWS cross-account role with SecurityAudit and ViewOnlyAccess and Google Cloud workload identity federation, stores no secrets, and shows access key ids truncated to the last four characters.

Grouped the Way Engineers Fix

Findings can be viewed one per asset or grouped by check with the number of affected assets, and one ticket can cover many findings. Every finding carries its owner team and SLA due date, so past-SLA work is visible and assigned.

Exposure Shown as a Path

Each internet exposure shows the route from the internet through the bucket policy, firewall rule or security group to the asset, with the rule at each hop. Intended exposures are listed apart with their approver and end date, so the website bucket is not mistaken for a leak.

Related case studies

View all: Cybersecurity
Logo
Oceanlab

Enterprise Software Engineering - Human + AI

Languages

Locations

Global Headquarters

21 Merchant Road, 3rd Floor, Singapore 058267

Main corporate office and leadership operations

North America Office

548 Market Street, PMB 12345, San Francisco, CA 94104

Client operations and business development

India Office

402 Shivalik Shilp II, SG Highway, Ahmedabad 380015

Engineering and delivery center

© 2026 - Copyright. All Rights reserved Oceanlab