Zero-trust security overhaul for a healthcare platform

Implemented a zero-trust architecture with network microsegmentation, remediated 30+ critical vulnerabilities, and achieved full HIPAA compliance within 10 weeks.

Client: Confidential (Healthcare Industry)
Practice: Cybersecurity & Compliance
Timeline: 10 weeks to HIPAA
Vulnerabilities fixed: 30+
Compliant: HIPAA
To certification: 10 wks

The challenge

A growing healthcare SaaS platform handling protected health information had no formal security program in place. With an expanding customer base and increasing regulatory scrutiny, they urgently needed HIPAA compliance and a working security program before their next funding round.

Our solution

We ran a security assessment covering penetration testing, cloud configuration, and code, implemented a zero-trust architecture with network microsegmentation, encrypted all data at rest and in transit, established audit logging for every access to patient data, and guided the team through the full HIPAA certification process including policy documentation and staff training.

What the assessment surfaced

The platform had grown the way most early SaaS products do: fast, feature-first, with security deferred until someone asked for it. Someone was now asking. We started with a full security assessment: external and internal penetration testing, cloud configuration review, dependency and code audits, and interviews with the engineers running production. The findings followed the pattern typical of a team that has never had a formal program: a flat network where every service could reach every other, over-permissive IAM roles, exposed management interfaces, secrets sitting in configuration files, and no reliable record of who accessed protected health information or when. None of it was unusual. All of it was disqualifying for a company selling into healthcare.

Working down the backlog

Triage came before fixes. We scored every finding on exploitability and proximity to PHI, then worked the list in that order rather than by generic severity ratings. Anything that put patient data within reach of the internet, directly or through a stolen credential, was closed first: management interfaces pulled off the public network, default and shared credentials rotated, hard-coded secrets moved into a managed vault. Structural problems came next: over-permissive IAM policies rewritten to least privilege, stale dependencies upgraded, access-control flaws fixed in application code with regression tests to keep them fixed. In total, 30+ vulnerabilities were remediated, and each was verified closed by retesting rather than marked done on a spreadsheet.

Zero-trust architecture

Closing existing holes was half the work; the other half was removing the conditions that produce them. We rebuilt the platform around a zero-trust model: no request is trusted because of where it originates, every service and every person authenticates on every call, and authorization is checked at each boundary instead of once at the edge. The flat network gave way to microsegmentation: workloads grouped by function and sensitivity, with explicit allow rules defining exactly which segment may talk to which, on which ports, and nothing else. A compromised web server can no longer reach the database holding patient records unless that path was deliberately opened. Lateral movement, the mechanism behind most real breaches, now stops at the segment boundary.

Protecting the data itself

Encryption became the default state of PHI rather than a feature. Data at rest (databases, object storage, backups, snapshots) is encrypted with keys held in a managed key service, separated from the infrastructure they protect and rotated on a schedule. Data in transit is encrypted on every hop, including service-to-service traffic inside the network, because zero trust does not exempt internal links. We also mapped every flow of patient data through the system, tracing where it enters, which services touch it, and where it lands, then cut the paths that had no reason to exist: debug logs capturing request bodies, analytics events carrying identifiers, staging environments seeded with production records. The data that remains moves through fewer places, all of them encrypted and accounted for.

Audit logging and monitoring

HIPAA requires that access to patient data be recorded; a working security program requires that someone can actually read the record. Every access to PHI, whether by a user, a service, or an administrator, now writes a structured audit event: who, what, when, from where. Logs ship to a centralized, tamper-evident store that application servers cannot alter, with retention set to meet the regulatory requirement. On top of the raw record sits alerting, routed to people expected to respond, for the patterns that matter: bulk record access, logins from unfamiliar locations, permission changes, queries outside working hours. The distinction is deliberate: logging satisfies an auditor, monitoring catches an incident.

HIPAA in 10 weeks

Certification ran in parallel with the engineering work, not after it. We drafted the full policy set HIPAA expects (access control, incident response, breach notification, business associate management, contingency planning), writing each to describe what the team actually does rather than what a template says a company should do, because policies that diverge from practice fail audits and protect no one. Staff training covered everyone who touches PHI or the systems around it. Configurations, logs, training records, and risk assessments were collected as each control went live, so the audit reviewed a working program rather than a paper one. The platform reached full HIPAA compliance in 10 weeks, ahead of the diligence questions of the next funding round.

The program day to day

Compliance is a snapshot; the security program is what keeps it true. The team now runs on the machinery we left behind: infrastructure changes are reviewed against the segmentation and IAM baselines, dependency scanning gates every deploy, and new services declare their data flows before they touch PHI. Audit logs are reviewed on a schedule, not just after something goes wrong. The risk assessment is a living document, updated when the architecture changes, and the incident response plan gets exercised rather than filed. Security stopped being a project with an end date and became part of how the platform ships software, which is what a certification is supposed to certify in the first place.

The numbers

Vulnerabilities fixed: 30+
Compliant: HIPAA
To certification: 10 wks