How to Design a HIPAA-Conscious Security Architecture for a Cloud-Based Healthcare SaaS Platform

Before any architecture decision, a signed Business Associate Agreement (BAA) with your cloud provider is the legal foundation - without it, using the infrastructure for PHI isn't compliant regardless of how well it's configured. Major cloud providers publish a specific list of HIPAA-eligible services covered under their BAA; using a service outside that list for PHI, even a mature and secure one, isn't covered. We've delivered a HIPAA and HITRUST-aligned AWS infrastructure project built around exactly this constraint - starting from the eligible-services list, not from 'what's the best tool for this job' in isolation.

Isolate PHI-handling systems into their own network segment (a dedicated VPC or equivalent) with explicit, minimal ingress/egress rules rather than a flat network where every service can reach every other service. Public-facing components (a web app, an API gateway) should sit in a clearly separated tier from data-layer components (databases, PHI storage), with no direct public network path to the data layer - all data access should route through your application's own access-controlled logic, not be reachable directly.

IAM policy is where least-privilege access control gets structurally enforced, not just documented as a policy - service accounts and roles should have narrowly scoped permissions matched to what that specific service genuinely needs, not broad administrative access granted for convenience. Human access to production infrastructure (not just application-level access, but infrastructure access - the ability to SSH into a server or query a production database directly) should be similarly scoped, logged, and, for anything sensitive, require explicit elevated-access requests rather than standing broad access.

Encrypt data at rest (managed, provider-native encryption for databases and storage is usually sufficient and simpler to maintain correctly than custom encryption) and enforce TLS for all data in transit, including internal service-to-service traffic, not just the public-facing edge. Centralized, queryable logging - both application-level audit logs (who accessed what PHI, when) and infrastructure-level logging (API calls against your cloud environment itself) - needs to be treated as core infrastructure from the start, since reconstructing this after the fact during an incident or audit is far harder than having it running continuously.