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.
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.
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.
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.
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.
14 AWS accounts and 9 Google Cloud projects with 28 findings across every status, 22 identity principals, 15 internet exposures and 7 owner teams.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

Designed and built a clickable vulnerability management platform for a Skopje electricity distribution operator: scanner findings merged into one list, ranked by real-world risk, triaged to owner teams with SLA dates, and OT fixes planned into maintenance outages - with substations assessed passively, never scanned.

Designed and built a clickable access review platform for a securities exchange and central securities depository operator in Port of Spain: review campaigns in which managers, application owners and the security team keep or remove each person's access, with the risky items surfaced first, revoke tickets tracked to removal and a later sync that proves the access really went.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
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
Enterprise Software Engineering - Human + AI
Contact Us
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