HIPAA on cloud infrastructure, where scope reduction does most of the work

The two mistakes cost the same amount in different currencies. The first is a startup that signs a business associate agreement with its cloud provider, ticks the box, and assumes the infrastructure is now compliant. It is not, and the first customer security review finds audit logging disabled, a developer with standing production access and protected health information sitting in a support tool that is not covered by any agreement.

The second is a team that treats every system as in scope, encrypts everything twice, restricts everyone from everything, and spends eighteen months building a compliance programme around data that ninety percent of their services never needed to see.

The difference between them is a scoping decision made early, and it is worth more than every control that follows.

Who you are determines what applies

A covered entity is a health plan, a healthcare clearinghouse or a healthcare provider transmitting health information electronically. Hospitals, insurers, most clinical practices.

A business associate is anyone performing a function on behalf of a covered entity that involves protected health information. If you sell software to hospitals and your product touches patient data, you are a business associate, directly regulated, and subject to enforcement rather than merely contractually obliged.

A subcontractor of a business associate carries the same obligations down the chain. Your cloud provider is one. So is your logging vendor, your email provider and anything else that touches the data.

The practical consequence is that you need a business associate agreement in both directions: one with each customer who is a covered entity, and one with every vendor that touches the data. The second list is longer than teams expect and it is the one that has gaps.

Protected health information, and the eighteen identifiers

Protected health information is individually identifiable health information. The phrase that matters is "individually identifiable", because that is the hinge on which scope turns.

The regulation lists eighteen identifiers: names, geographic detail smaller than a state, dates more precise than a year, phone and fax numbers, email addresses, social security numbers, medical record numbers, health plan numbers, account numbers, certificate and licence numbers, vehicle and device identifiers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying code.

IP addresses being on that list surprises engineers, and it is why web server logs on a patient-facing application are usually in scope.

Scope reduction is the highest-leverage work

Every system that holds protected health information needs the full control set, forever, and has to be evidenced. So the most valuable engineering decision is reducing how many systems that is.

Three techniques, in order of power:

De-identification. Data stripped of the eighteen identifiers, under the safe harbour method, is no longer protected health information and falls out of scope entirely. The alternative expert determination method allows more data retention with a documented statistical opinion. This is the only route that removes a system from the regime rather than adding controls to it, and it is chronically underused. Your analytics warehouse almost certainly does not need real identifiers.

Tokenisation at the boundary. Keep the identifying data in one small, well-controlled service and give everything else a token. The billing system, the recommendation engine and the notification service work on tokens, and only the token service is in scope.

Not collecting it. The date of birth the form collects by habit, the free-text notes field that inevitably fills with clinical detail, the full address where a postal code region would do.

Draw the boundary explicitly and write it down as a diagram with a line on it. Everything inside gets the full treatment. Everything outside gets a control preventing protected health information from crossing in, which is a real control needing real enforcement rather than a hope.

Which cloud services you may actually use

Every major provider offers a business associate agreement, and each publishes a list of services covered by it. The list is not all services, and using an uncovered service for protected health information is a violation regardless of how well you configured it.

Check the current list before designing, because it changes. Newer services, preview features and some regional or AI offerings are frequently absent. This bites hardest on AI features: a model endpoint that is not in the covered list cannot receive patient data, and the presence of a generic enterprise agreement does not change that.

Also note that the agreement covers the provider's obligations, not your configuration. A covered service configured to allow public access is still your breach.

The safeguards, as configuration

The Security Rule is deliberately technology-neutral, with required and addressable implementation specifications. Addressable does not mean optional: it means implement it, or document why an alternative is reasonable and appropriate. "We did not get to it" is not that document.

In practice an assessor looks at the same things every time:

• Access control. Unique user identification, role-based access, and automatic logoff. In cloud terms: no shared accounts, no standing production access, just-in-time elevation, and an emergency access procedure that exists and has been tested.
• Audit controls. Recording and examining access to systems holding protected health information. The examining half is the one teams skip, and it needs a named owner and a cadence.
• Integrity. Mechanisms to confirm data has not been improperly altered or destroyed. Versioning, checksums, immutable audit logs.
• Authentication. Multi-factor everywhere, no exceptions for administrators.
• Transmission security. TLS in transit, with internal traffic included. Encryption at rest is addressable rather than strictly required, and it is also the cheapest thing on this list, so encrypt.
• Disposal. Media and data destruction that you can evidence, including in backups.

Most of this is the control set you already run for SOC 2, which is why it belongs in a single mapped programme rather than a parallel one, as argued in one control set across frameworks. If you have SOC 2 Type II, you are most of the way here, and the delta is documentation plus a few specifics; the sequencing question is covered in SOC 2 Type I or Type II.

Logging, retention and the six-year number

Audit logging is where cloud architecture and HIPAA interact most awkwardly.

You need a record of who accessed what, and it must survive attempts to alter it. That means audit logs in a separate account with write-only access from production, immutability enabled, and an alert on configuration change. The same pattern as protecting backups from ransomware, and for the same reason.

Documentation retention runs to six years from creation or last effective date, which applies to policies, risk analyses and the agreements, not necessarily to every log line. Decide the log retention deliberately by class and document the decision, because a blanket six-year retention on high-volume access logs is an expensive default nobody actually required.

The risk analysis deserves a specific mention because it is the most commonly missing document and the first thing requested in an enforcement action. It is a written, dated, periodically updated assessment of risks to protected health information across your systems. Not a penetration test, not a scan report.

Breach notification, and the sixty-day clock

A breach of unsecured protected health information triggers notification to affected individuals without unreasonable delay and no later than sixty days, to the Secretary of Health and Human Services, and to media outlets when a large number of residents of a state or jurisdiction are affected. Smaller breaches may be logged and reported annually. Business associates notify the covered entity, who notifies onward.

The engineering consequence is the important one: encrypted data meeting the specified standards is not "unsecured", so a breach of properly encrypted data may not be notifiable. That makes encryption the control with the highest return on this entire list, and it makes key management a compliance question rather than a technical preference.

The other consequence is that you cannot scope a breach without access logs. If you were not recording reads, you cannot establish what was accessed, and an inability to narrow it tends to widen the notification.

What to do this week

Draw one diagram of your systems and put a line around everything that holds protected health information. Then, for the three largest systems inside the line, ask whether they need real identifiers or would work on tokens. Every system you move outside that line is a permanent reduction in compliance cost, and it is the cheapest work available. We start a healthcare engagement with exactly that diagram, in the scoping phase of a security engagement.