Preparing Azure for a Hospital Security Review: HIPAA Controls for ePHI
Before a hospital or health system signs a Business Associate Agreement (BAA) with a software vendor, its security team usually reviews how the vendor's cloud environment protects patient data. Here is what those reviews tend to look for on Azure and the technical controls that answer them.
What is at stake
Under the Health Insurance Portability and Accountability Act (HIPAA) and the HITECH Act, a business associate that handles electronic protected health information (ePHI) is directly responsible for safeguarding it. A breach can lead to breach notification duties, investigation by the Department of Health and Human Services (HHS) Office for Civil Rights, and civil monetary penalties, on top of the loss of the customer's trust.
Microsoft offers a BAA covering in-scope Azure services, but that only covers Microsoft's side of the shared responsibility model. How you configure your own resources is what the hospital's reviewers will examine. Findings that come up often in early-stage environments include:
- Public storage endpoints. Storage accounts holding patient files that allow public network access, protected only by shared access signature (SAS) tokens.
- Unencrypted internal traffic. Backend APIs that accept plain HTTP inside the virtual network.
- Thin audit logging. Access logs kept for a short default period, with no way to show who accessed ePHI and when.
How long to keep audit logs
The Security Rule requires audit controls (§ 164.312(b)) without naming a log retention period. The six-year retention in § 164.316(b)(2) applies to required documentation, and many covered entities set long log retention expectations for vendors in their contracts.
The controls: an isolated environment for ePHI
These are the controls VitCamp sets up for healthcare workloads in the Compliance Guardrail Pack (Tier 2), with HIPAA/HITRUST as the engagement's framework:
- No public endpoints. Storage, PostgreSQL databases and Azure AI services have public network access disabled, and traffic reaches them only through Private Link endpoints in your virtual network.
- Customer-managed keys. Storage and databases encrypt data at rest with keys you hold in Azure Key Vault, with a key rotation policy configured.
- Enforced TLS. Azure Policy denies resources that allow plain HTTP or a minimum TLS version below 1.2.
- Protected audit trail. Diagnostic and activity logs flow to a dedicated Log Analytics workspace, with an archive copy exported to a storage account under a time-based immutability policy.
Policy guardrails instead of checklists
Developer checklists drift. Azure Policy definitions assigned at management group scope apply to every subscription beneath it, so a non-compliant resource is denied at deployment time rather than found in a later review.
Example guardrail: deny public network access to ePHI storage
{
"policyRule": {
"if": {
"allOf": [
{ "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
{ "field": "Microsoft.Storage/storageAccounts/publicNetworkAccess", "notEquals": "Disabled" }
]
},
"then": { "effect": "deny" }
}
}Giving reviewers the evidence they ask for
Hospital reviewers want to see how each safeguard is enforced, not only that a policy document exists. A Security Control Traceability Matrix (SCTM) maps each Azure Policy assignment to the HIPAA Security Rule citation it supports, for example § 164.312(a)(1) Access control, § 164.312(b) Audit controls and § 164.312(e)(1) Transmission security. A reviewer can trace a requirement to the setting that enforces it and its current compliance state.
What the controls do not cover
Technical controls are only part of HIPAA. Risk analysis, workforce policies, incident response and the BAA itself remain your organisation's responsibility, and whether a review is cleared is the customer's decision. The controls and the matrix make the technical part of that review quicker to answer.