HIPAA in a cloud stack: proving safeguards without moving PHI

The question OCR investigators ask is not whether you intended to protect protected health information. The question is whether you can prove the safeguards were in place and operating. For most mid-market healthcare-adjacent companies, those are two very different things. Intent lives in policy documents. Proof lives in records of what the systems actually did.

Today, PHI moves through cloud stacks. Salesforce Health Cloud holds patient intake records. Microsoft 365 carries clinical correspondence. AWS hosts workloads that process billing data and scheduling feeds. These are real environments where real healthcare information lives, and the companies running them face the same evidentiary standard as a large hospital system — but without dedicated compliance infrastructure. The audit finds the same exposure. The breach notice obligation is the same. The investigation is the same.

The worst possible response to this reality is to copy PHI into yet another system in order to monitor the first ones. Every copy of PHI is a new risk surface. Every new vendor that touches the data is a potential business associate requiring its own agreement, its own oversight, its own chain of documentation. The compliance architecture that protects PHI must not widen the breach surface to build itself. There is a better posture — and it starts with understanding what HIPAA's Security Rule actually requires as evidence.

01 / Three safeguards, one evidence obligation

The Security Rule organizes its requirements into three categories of safeguard: administrative, physical, and technical. Each category carries implementation specifications — some required, some addressable — and each demands that covered entities and business associates be able to demonstrate compliance, not merely assert it.

Administrative safeguards include the risk analysis, the workforce training program, the security management process, and the procedures for access authorization and review. Physical safeguards address workstation security, device controls, and facility access. Technical safeguards cover access controls, audit controls, integrity mechanisms, and transmission security. For a company whose PHI lives entirely in cloud systems, the physical layer is largely delegated to cloud providers under BAAs — but the administrative and technical layers remain squarely the company's obligation to evidence.

The compliance failure pattern OCR sees repeatedly is not a company that wrote no policies. It is a company that wrote policies, implemented controls in its cloud systems, and then generated no ongoing record that those controls operated as written. The policy said access would be reviewed quarterly. No record of those reviews exists. The policy said terminated employees would be deprovisioned within 24 hours. The audit log was never collected. When OCR opens an investigation — whether triggered by a breach notification or a complaint — it asks for records. The absence of records is itself a finding.

02 / Risk analysis as a living record

HIPAA requires a thorough and accurate assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI. Most organizations treat this as a binder produced before an audit and updated annually if someone remembers. OCR's guidance is more demanding: the risk analysis should reflect the current state of the environment, and the risk management plan should document what was done in response.

A cloud-first healthcare-adjacent company whose stack changes continuously — new Salesforce AppExchange integrations, new Microsoft 365 features enabled, new AWS services provisioned — has an environment that drifts away from its last risk analysis almost immediately. The risk analysis that was accurate in January may not describe the environment in June. If a breach occurs in August, OCR will ask what the risk analysis said about the affected system and when it was last updated relative to the configuration that allowed the breach.

The evidence obligation here is not a one-time document. It is a continuous record that the organization assessed its risks, made decisions about them, and acted on those decisions. That record needs to survive personnel changes, system changes, and the ordinary entropy of a growing company. A governance posture that produces timestamped, independent evidence of each risk review cycle — without requiring manual assembly of screenshots and spreadsheets — is the only one that holds under investigation.

The risk analysis OCR wants to see is not the document you wrote before the audit. It is the record of what you did every quarter while no one was watching.

03 / Access controls and audit controls as evidence targets

Technical safeguard requirements for access controls and audit controls are, practically speaking, the most frequently cited categories in OCR resolution agreements. Access controls require that only authorized users can access PHI — and that the authorization is tied to a defined, reviewed basis. Audit controls require that activity in systems containing PHI is recorded and that the organization can examine those records.

In a Salesforce Health Cloud environment, this means knowing which profiles and permission sets grant access to PHI-bearing objects, which users hold those permissions, when that access was last reviewed, and whether the review was documented. In a Microsoft 365 environment, it means knowing who can access SharePoint libraries containing clinical files, whether DLP policies covering PHI are active and correctly scoped, and whether the audit log captures the activity that matters. In AWS, it means CloudTrail coverage, IAM policy review, and S3 bucket access controls verified against the approved baseline.

The evidence these controls were operating — not the PHI those controls were protecting — is what the company needs to collect. Access review completion, permission set snapshots compared against approved baselines, DLP policy status, audit log availability: all of this can be proven without moving a single PHI record out of the systems where it lives. The moment a vendor ingests PHI records to report on access to those records, the compliance architecture has created the exact risk it was supposed to mitigate.

04 / Vendor oversight and the BAA chain

Every vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate. Every business associate requires a Business Associate Agreement. And every BAA creates an obligation not just to sign the document but to oversee the associate's compliance — to have reasonable assurance that the safeguards are in place.

For a company running PHI through Salesforce, Microsoft, and AWS, the Tier 1 BAAs are generally straightforward. These vendors maintain their own compliance programs and make BAAs available. The harder problem is the secondary chain: the AppExchange app that pulls Salesforce Health Cloud records, the third-party analytics tool connected to the Microsoft 365 tenant, the managed-service provider handling AWS infrastructure. Each of these may qualify as a business associate subcontractor, creating an obligation that many mid-market companies have not mapped.

Vendor oversight evidence includes the BAA itself, documentation of the vendor's security posture review at onboarding, and ongoing monitoring evidence. The last category is where most companies have nothing. If a vendor is processing PHI and OCR asks how the company monitored that vendor's controls over the past year, the answer should not be "we renewed the BAA." The answer should be a record of what was checked and when. Governing vendors at the source — collecting evidence of their control operation without pulling their data into yet another system — is the only oversight posture that does not compound the problem.

05 / Breach notification and the stakes of thin records

HIPAA's Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in some cases the media, following the discovery of a breach of unsecured PHI. The notification timeline is 60 days from discovery for individual notifications, with HHS notification timing dependent on the scale of the breach. Business associates must notify covered entities within 60 days of discovering a breach.

The investigation that follows a breach notification is where thin compliance records become acute problems. OCR will request the risk analysis, the access control records, the audit logs, the BAA inventory, and the workforce training records. If those records are complete, current, and independently verified, the investigation can proceed on the merits of the incident. If those records are incomplete, out of date, or assembled reactively from system screenshots, the investigation expands to include the compliance program itself — and findings multiply.

Companies that treat compliance evidence as a retrospective exercise — something assembled when an audit is announced or a breach occurs — are exposed in a way that no policy document corrects. The evidence of safeguard operation must exist before the incident, produced continuously by the governance program, independent of any specific investigation or audit cycle. That is the standard OCR applies. It is also the standard enterprise customers, health plan partners, and procurement teams increasingly apply in their vendor security reviews. The question is always the same: can you prove it?

06 / What continuous, independent evidence changes

A point-in-time compliance posture — annual risk analysis, quarterly access review spreadsheet, a BAA folder in SharePoint — is a baseline, not a program. OCR enforcement actions and enterprise procurement questionnaires alike are increasingly focused on whether governance is continuous and whether evidence is independently produced, not self-reported.

Continuous governance means the evidence of control operation exists for every period, not just the periods when someone remembers to check. Independent governance means the evidence is collected by the governance program itself, not assembled from memory by the people whose controls are being evidenced. For HIPAA specifically, these properties matter because the Security Rule applies continuously — not just when an auditor is looking — and because the breach notification investigation reaches backward in time to ask what the controls showed before the incident.

Governing the systems where PHI lives — Salesforce, Microsoft 365, AWS — and collecting evidence of control operation at the source, without moving PHI to do it, is the compliance architecture the Security Rule's evidentiary standard demands. It is also the architecture that survives an investigation, satisfies an enterprise procurement review, and gives the compliance team a real answer when a health plan partner asks whether access to their data is controlled and proven.