Compliance & frameworks
HIPAA
HIPAA Security Rule
HIPAA is federal law, not a market ask. Its Security Rule sets the safeguards you must apply to electronic protected health information (ePHI) — and once patient data lives in AWS, Azure, or Google Cloud, most of those safeguards become cloud configuration questions. A HIPAA-eligible cloud and a signed Business Associate Agreement cover the provider's side of the shared-responsibility line; how you configure identity, encryption, network exposure, and audit logging around ePHI is yours to answer. The health check reviews that side of the line, read-only, and maps what it finds to the Security Rule safeguards your compliance team and, if it comes to it, the HHS Office for Civil Rights already reference.
Who it applies to
HIPAA reaches two groups: covered entities — healthcare providers, health plans, and clearinghouses — and their business associates, meaning any vendor that creates, receives, maintains, or transmits ePHI on their behalf, plus that vendor's subcontractors down the chain. If your workload stores or processes patient data in the cloud, a signed BAA does not end your obligations; it formalizes them. The Security Rule's protections follow the ePHI wherever it lives, so a SaaS platform serving hospitals carries the same technical duties as the hospital. Enforcement is real: the Office for Civil Rights investigates breaches and can levy civil penalties, and a documented risk analysis covering the systems that handle ePHI — your cloud environment among them — is an explicit, non-negotiable requirement, not a best practice you can defer.
Cloud control themes
What HIPAA asks of your cloud
- Access Control (§164.312(a)) — unique user identification, least privilege, automatic logoff, and encryption of ePHI at rest
- Audit Controls (§164.312(b)) — recording and examining activity in systems that hold or touch ePHI
- Integrity (§164.312(c)) — protecting ePHI from improper alteration or destruction
- Person or Entity Authentication (§164.312(d)) — verifying identity before access, where MFA is the practical bar
- Transmission Security (§164.312(e)) — guarding ePHI in transit, including encryption in motion
- Security Management Process (§164.308(a)(1)) — the required risk analysis and risk management over your cloud estate
Domain × framework
Which assessment domains produce HIPAA evidence
| Assessment domain | How it maps |
|---|---|
| Identity & access | IAM findings map to Access Control (§164.312(a)) and Person or Entity Authentication (§164.312(d)) — unique identities, least-privilege roles over ePHI, MFA on privileged and console access, and prompt deprovisioning across AWS IAM, Entra ID, and Google Cloud IAM. |
| Data security | Storage and encryption findings evidence the addressable encryption-at-rest specification (§164.312(a)(2)(iv)) and Integrity (§164.312(c)) — surfacing unencrypted or publicly reachable stores of ePHI and confirming customer-managed keys via AWS KMS, Azure Key Vault, or Google Cloud KMS/CMEK. |
| Network exposure | Boundary and segmentation findings support Transmission Security (§164.312(e)) by showing whether ePHI workloads sit behind private networking — keeping traffic off the public internet — rather than open security groups, exposed management ports, or unnecessary public endpoints in your VPCs, VNets, or VPC networks. |
| Logging & monitoring | Log-coverage findings map directly to Audit Controls (§164.312(b)) — confirming CloudTrail, Azure Monitor and Activity Log, and Google Cloud Audit Logs capture access to ePHI systems, retain records with integrity, and would let you reconstruct an incident. |
| Configuration & posture | Baseline-drift findings feed the required Security Management Process and periodic evaluation (§164.308(a)(1) and (a)(8)) — measuring how far each account, subscription, or project has drifted from a hardened, HIPAA-appropriate configuration. |
| Framework mapping | Every finding is tied back to the specific Security Rule citation it bears on and framed against your BAA scope, so the report reads as ordered evidence toward the safeguards rather than a generic scan. |
What you get
A findings report organized around the HIPAA Security Rule: each cloud gap tied to the specific safeguard it affects — Access Control, Audit Controls, Integrity, Authentication, Transmission Security, and the required risk analysis — ranked by real risk to ePHI, with a remediation order your compliance lead and your engineers can both follow. It is the cloud-technical input to the risk analysis the rule already requires of you, in a form you can put in front of internal audit, an assessor, or the Office for Civil Rights if you ever have to.
Most relevant to: Healthcare
Questions
Does a health check make us HIPAA compliant?
No. HIPAA compliance spans administrative, physical, and technical safeguards, plus policies, training, and executed BAAs — most of that lives outside the cloud. The health check is read-only technical readiness: it finds and prioritizes the cloud-configuration gaps that bear on the Security Rule so your compliance program has accurate evidence to work from. Closing the findings is what changes your risk.
We use a HIPAA-eligible cloud and signed a BAA — isn't that enough?
A BAA and a HIPAA-eligible service cover the provider's responsibilities under the shared-responsibility model. How you configure ePHI on top — who has access, whether it's encrypted, what's exposed to the network, whether access is logged — is your side of that line, and it's where most real exposure sits. The health check assesses exactly that side.
Does the assessment access our patient data?
No. It reviews configuration and metadata through read-only access — IAM policies, encryption settings, network rules, and log coverage — and writes nothing to production. We do not read, copy, or move ePHI to determine whether the safeguards around it are in place.
Framework work in practice
Evidence rooms and compliance tables
Mapping is for auditors and operators — shown in the spaces where evidence is reviewed.
