Healthcare engineering teams pay for the cloud twice. Once to build, once to prove.
The HIPAA Security Rule does not specify cloud services. It specifies safeguards. Teams who interpret it as a checklist of services end up paying for the architecture twice: once when they build it the easy way, and again when they rebuild it to satisfy a HITRUST assessor or a hospital procurement reviewer.
We have built and audited HIPAA cloud environments for clinical SaaS startups selling into hospital systems, pharmacy benefit managers running production PHI workloads, and digital health platforms preparing for HITRUST. The pattern is the same in every engagement: the engineering team understands the application, the compliance team knows what HIPAA wants, and the cloud architecture in the middle has never been built to satisfy both.
Stonebridge designs the environment around the PHI boundary first. Encryption, identity, logging, and network architecture are derived from where PHI flows, not bolted on after.
HIPAA Security Rule safeguards the environment must satisfy.
The HIPAA Security Rule (45 CFR § 164.308 through § 164.312) names safeguards, not services. A correctly-architected HIPAA cloud satisfies the technical safeguards through how it is built, not through policies that describe what it is supposed to do.
The safeguards the environment most directly touches:
- §164.308(a)(3)Workforce security. Identity federation with least-privilege IAM and time-bounded access to PHI-bearing systems.
- §164.308(a)(4)Information access management. Role-based access boundaries, with PHI access audited and reviewable.
- §164.312(a)(1)Access control. Unique user identification, automatic logoff, and encryption of data at rest.
- §164.312(b)Audit controls. Centralized, tamper-evident logging of access to PHI and changes to systems that touch PHI.
- §164.312(c)(1)Integrity. Signed artifacts, immutable infrastructure, and drift detection on production state.
- §164.312(e)(1)Transmission security. Encrypted in transit with mutually-authenticated, modern TLS for all PHI flows.
Build around the PHI boundary, not the application boundary.
The architecture pattern that survives HIPAA scrutiny rests on four principles. Implementation varies across AWS, GCP, Azure, and OCI; the architecture is the same.
Principle 1: Identify the PHI boundary first
Before any Terraform is written, we map where PHI enters the system, where it is stored, and where it leaves. Every account, network range, and service that touches PHI is inside the boundary. Everything else is outside. This single decision drives every subsequent architectural choice.
Principle 2: Account-level isolation, not tag-level
PHI-bearing workloads live in separate cloud accounts (AWS), projects (GCP), or subscriptions (Azure) from non-PHI workloads. Identity federates from a central IdP with role-based, time-bounded access. Network connectivity between accounts is explicit, mutually-authenticated, and audited.
Principle 3: Customer-managed keys for PHI-bearing storage
KMS-backed encryption with customer-managed keys for every PHI-bearing data store. Key usage is logged. Key rotation is automated. The blast radius of a single key compromise is bounded by design.
Principle 4: Centralized, retention-locked audit logging
Every account, service, and identity event ships to a centralized logging account that engineers cannot modify. Retention locks (S3 Object Lock or equivalent) prevent tampering. Logging is not a feature; it is the system of record auditors will use to validate every other control.
Six artifacts your auditor will ask for.
A HIPAA Cloud Build engagement produces a defined set of deliverables, each mapped to safeguards and ready for assessment package inclusion.
PHI boundary architecture
- PHI boundary diagram
- Data flow diagrams
- Network topology
- BAA-covered service inventory
Infrastructure as code
- Terraform modules for the boundary
- OPA / Sentinel policy gates
- Drift detection wired to alerting
- State backend in the PHI boundary
Identity & access
- IdP federation
- Role catalog with least-privilege scopes
- Access review automation
- Break-glass procedure
Encryption & key management
- KMS topology
- Customer-managed keys for PHI
- Automated rotation
- Key usage audit logging
Logging & monitoring
- Centralized logging account
- Retention locks
- SIEM integration
- HIPAA-mapped dashboards
Control documentation
- HIPAA safeguard narratives
- Continuous monitoring plan
- Incident response runbooks
- HITRUST CSF crosswalk
Five patterns that fail HIPAA assessments.
We see the same mistakes repeatedly when healthcare engineering teams build HIPAA cloud environments without architectural help.
One account, all PHI
A single AWS account or GCP project hosting production PHI, dev environments, and corporate workloads. The first IAM mistake exposes everything. Separate accounts for PHI workloads; explicit, audited cross-account access.
Default encryption, no key rotation
Relying on default cloud-managed keys with no rotation discipline. The encryption is in place but the key management discipline is not. Customer-managed keys with automated rotation, logged usage, and clear key ownership.
BAA not enforced in IaC
A BAA covers specific services; the IaC happily provisions services that are not BAA-eligible. Policy gates that reject non-eligible services at plan time prevent the silent boundary breach.
Logs that engineers can edit
Audit logs in the same account engineers operate in. Logging needs its own account, retention locks, and access boundary distinct from production engineering.
HIPAA as a policy document, not an architecture
Policies describing what the environment should do, with infrastructure that does not actually do it. We write control narratives alongside the Terraform; the policy is generated from the architecture, not the other way around.
Two ways to engage. Fixed scope, fixed price.
Most clients start with the audit. It produces a written roadmap that often gets approved as a follow-on build. Clients with a fixed audit deadline come straight to the build.
HIPAA Cloud Audit
Two-week, fixed-fee assessment of your cloud environment against HIPAA Security Rule safeguards. Produces a written report with control mapping, prioritized remediation roadmap, and effort estimates.
- 2 weeks duration
- Cloud + IaC review
- Safeguard mapping document
- Prioritized remediation roadmap
- Effort estimates per finding
- Often converts to build engagement
HIPAA Cloud Build
Eight-week hands-on engagement to architect and ship a HIPAA-aligned cloud environment. PHI boundary, encryption, identity, logging, IaC, and control documentation, handed to your team with runbooks.
- 8 weeks duration
- Production-ready environment
- Terraform IaC for full boundary
- Centralized logging architecture
- HIPAA control documentation
- 30-day post-handoff support
A representative engagement.
One of our healthcare engagements involved auditing a clinical platform's GCP infrastructure to identify HIPAA gaps before a third-party assessment, then codifying the baseline so future deployments could not regress.
HIPAA GCP infrastructure audit, ahead of third-party assessment.
The platform was running production workloads on GCP with PHI in flight. The compliance team had a required version baseline for Tomcat, JavaScript runtimes, and operating systems. Manually inventorying every VM against the baseline would have taken weeks.
We wrote an Ansible and Python tool that connected to each VM through GCP Identity-Aware Proxy, scraped versions, and produced a compliance matrix mapping current state to the required baseline. From there we extended the work into the pipeline, codifying the baseline as a policy gate so future deployments could not regress.
vs manual process
on first-party review
codified in the pipeline