HIPAA Readiness.
US Security Rule and Privacy Rule applied to cloud-hosted PHI, with breach-notification playbooks your counsel can actually use
Readiness guide
HIPAA is US federal law — Title II of the Health Insurance Portability and Accountability Act of 1996 — administered by the Department of Health and Human Services Office for Civil Rights (HHS OCR). Three operative rules affect anything that touches Protected Health Information (PHI):
The Privacy Rule covers permissible uses and disclosures of PHI plus individual rights of access and correction. The Security Rule sets administrative, physical, and technical safeguards for electronic PHI (ePHI) — this is where cloud infrastructure shows up. The Breach Notification Rule covers notification to affected individuals, HHS, and the media when unsecured PHI is compromised.
The Security Rule is organized into administrative, physical, and technical safeguards, each with standards and implementation specifications. Implementation specifications are either “required” (must be done) or “addressable” (must be done unless a documented analysis shows an equivalent alternative).
Source: HHS OCR Security Rule · HHS OCR Privacy Rule · HHS OCR Breach Notification Rule · NIST SP 800-66r2
HIPAA applies to two classes of organization: covered entities (health plans, health-care clearinghouses, and providers that electronically transmit health information in connection with a HIPAA transaction) and business associates (third parties that create, receive, maintain, or transmit PHI on behalf of a covered entity).
Most digital health, healthtech, and care-adjacent SaaS companies are business associates. They sign a Business Associate Agreement (BAA) with each covered entity they serve, and the BAA contractually binds them to the same Security and Privacy Rule requirements.
Heuristic: if your platform stores, processes, or transmits health information that can be tied back to an individual, and you received that information from a US healthcare organization, you are almost certainly a business associate. Cloud Upload is not a law firm — confirm scope with counsel before designing the architecture.
HIPAA has no official certificate. HHS OCR does not issue pass/fail stamps; compliance is an ongoing obligation, not an attestation at a point in time. Readiness in this context means three concrete outputs:
-
Output A
Documented Security Rule compliance
Every required implementation specification is implemented; every addressable one is either implemented or has a documented equivalent-alternative analysis.
-
Output B
Current risk analysis & risk management plan
§ 164.308(a)(1)(ii)(A) and (B). “We have not done one” is the single most-cited finding in HHS OCR enforcement actions.
-
Output C
Breach-notification capability
Decision tree, playbook, and rehearsed procedure for the 60-day individual-notification and HHS-notification windows.
Many buyers (covered entities signing a BAA with you) also ask for third-party validation beyond the statute — a HITRUST certification, or a SOC 2 report with HIPAA mapping as an addendum. Those are commercial expectations, not legal requirements, and we prepare for either path on request.
The Security Rule's technical safeguards map cleanly onto five of the eight CloudCheck 360° categories. Administrative and physical safeguards need policy and documentation work on top of the technical pass.
| Section | Title | CC360° category |
|---|---|---|
| § 164.312(a) | Access control | §1 IAM · §3 Data |
| § 164.312(b) | Audit controls | §4 Logging & Detection |
| § 164.312(c) | Integrity | §3 Data · §4 Logging & Detection (tamper-evidence) |
| § 164.312(d) | Authentication | §1 IAM (MFA, federation) |
| § 164.312(e) | Transmission security | §2 Network · §3 Data (TLS) |
| § 164.308 | Administrative safeguards | Cross-cutting (policy + risk analysis — outside CC360°) |
| § 164.310 | Physical safeguards | Inherited from cloud provider (AWS/GCP physical safeguards documented in their SOC 2/ISO 27001) |
The administrative safeguards — § 164.308 — pull in the risk-analysis requirement, workforce clearance and termination, security training, contingency planning, and business-associate agreements. Physical safeguards are largely inherited from the cloud provider (covered by their own SOC 2 / ISO 27001 reports, which we reference in the readiness documentation).
A HIPAA readiness engagement is typically 6 to 10 weeks, running alongside or immediately after a CloudCheck 360° pass.
-
Weeks 1-2
Scoping & BAAs
Identify systems that store, process, or transmit PHI. Inventory subprocessors and verify BAAs are in place with each. Establish the scope of the risk analysis.
-
Weeks 2-5
Risk analysis & gap assessment
The § 164.308 risk analysis is the anchor deliverable. We enumerate assets, threats, vulnerabilities, likelihood, impact, and existing controls — in a format that will survive an HHS OCR investigation.
-
Weeks 4-8
Remediation & policy
Technical gaps fixed. Administrative safeguards — training program, sanction policy, workforce clearance, incident response — documented and put into operation. Security Officer and Privacy Officer formally designated.
-
Weeks 8-10
Breach-notification rehearsal
Tabletop exercise of a simulated breach. We observe how the notification decision tree, risk-of-harm analysis, and individual-notification workflow perform under time pressure.
After completion, we recommend annual risk analysis refresh + quarterly evidence collection sync.
-
No formal risk analysis.
The Security Rule requires one. Most companies have done something that looks like a risk analysis but not with the rigor the Rule requires — enumerate assets, threats per asset, vulnerabilities, likelihood-and-impact ratings, and current controls. HHS OCR enforcement actions repeatedly cite a missing or stale risk analysis as the primary failure.
-
Logging gaps on data-access events.
Application-level logging of PHI access is often incomplete. Database-level audit logging sometimes exists but is never read. The Audit Controls standard expects both existence and examination.
-
BAAs signed, subprocessor BAAs not.
A covered entity has a BAA with the business associate. The business associate then uses a cloud provider, a logging service, a customer-support tool — and those also need BAAs. Many clients have the top-level BAA in order and a gap on the subprocessor chain.
-
Workforce sanctions undefined.
§ 164.308(a)(1)(ii)(C) requires a sanction policy for workforce members who fail to comply with security policies. Most companies have an HR policy but no security-specific sanction tier. The fix is usually a one-page addendum to existing HR policy.
-
Contingency plan never tested.
§ 164.308(a)(7) requires a contingency plan AND testing/revision procedures. Companies have backup runbooks; few have ever restored from those backups. The fix is annual restore-from-backup drill with documented evidence.
-
Does AWS / GCP / Azure sign a BAA?
All three do, for specific services listed on each provider's HIPAA-eligible service list. Using a non-eligible service for ePHI is itself a compliance gap. Review and document which services are in scope.
-
Do we need to encrypt PHI at rest?
Encryption is addressable, not required. In practice, every modern cloud environment is expected to encrypt ePHI at rest with provider-managed or customer-managed keys. Not doing so requires a documented equivalent-alternative rationale that regulators rarely accept.
-
What about HITRUST?
HITRUST CSF is a private certification that maps to HIPAA plus many other frameworks. Larger payers and health systems often ask for HITRUST instead of raw HIPAA compliance, because HITRUST includes a third-party assessment HIPAA does not. We can prepare for HITRUST as an extension of the HIPAA readiness work.
-
Breach notification timelines?
Individual notification within 60 days of discovery (§ 164.404). HHS notification concurrent with individual notification for breaches involving 500+ individuals; annual for breaches under 500 (§ 164.408). Media notification for breaches involving 500+ residents of a state or jurisdiction (§ 164.406).
-
What counts as a breach?
An impermissible use or disclosure of PHI that compromises the security or privacy of the PHI. The Rule provides a four-factor risk-of-harm analysis — the compromise is presumed to be a breach unless the analysis documents otherwise. Do not skip the analysis; do not delete the documentation.
-
Can we host ePHI outside the US?
HIPAA itself does not prohibit it, but BAAs and customer contracts often do. Verify before designing the architecture.
Primary sources: HHS OCR Security Rule · HHS OCR Breach Notification Rule · NIST SP 800-66 Rev. 2 · CloudCheck 360° methodology · SOC 2 readiness guide · GDPR readiness guide
Get started
Run a free audit to see your HIPAA posture.
The patterns in this guide come from real engagements. To see how your environment compares — and which gaps would land in your readiness report — start with a free scan or talk to us about a manual engagement.