HIPAA arrives with a contract, not a choice
For most small software teams, HIPAA doesn't show up as a strategic decision. It shows up as a clause. A healthcare prospect wants to buy, their procurement team slides a Business Associate Agreement (BAA) across the table, and suddenly you are legally on the hook for protected health information (PHI) you may have barely thought about. Sign the BAA and you become a business associate under the law — directly liable for safeguarding that data, subject to the same Security Rule obligations as the hospital or clinic you serve.
The instinct at that moment is to ask "are we HIPAA compliant?" — but that's the wrong frame, and a dangerous one. HIPAA has no certificate, no audit body that stamps you approved, no logo you earn. Compliance is a posture you maintain and must be able to demonstrate if the regulator ever asks, not a badge you acquire. The practical question is sharper: do we run the safeguards the Security Rule requires, and can we prove it? That reframing is the whole job, and it's the same evidence-first instinct that governs every framework.
The Security Rule: three families of safeguards
The HIPAA Security Rule organizes its requirements into three categories. A lean team can cover all three with controls it largely already needs for any serious security program — the rule is mostly a structured way of asking for hygiene you should have anyway.
- Administrative safeguards — the program around the data. A named security official, a documented risk analysis, workforce security-awareness training, an incident response plan, and a sanction and access-review process. This is the largest category and the one auditors lean on hardest, because it proves the program is governed, not accidental.
- Physical safeguards — controlling physical access to the systems and devices that touch PHI. For a cloud-native team this mostly inherits from your provider, but the part you still own is the fleet: encrypted, managed laptops with remote-wipe, because the device that leaves the building with PHI on it is yours to account for.
- Technical safeguards — the controls on the data itself: access controls and unique user IDs, encryption at rest and in transit, audit logging that records who touched what, and integrity controls. These map almost one-to-one onto the technical hygiene any modern application should already run.
Required vs. addressable — and why "addressable" is not "optional"
The single most misunderstood part of the Security Rule is the distinction between required and addressable implementation specifications. Teams read "addressable" as "optional" and skip it — which is exactly how enforcement actions begin.
Addressable means you must assess whether the safeguard is reasonable and appropriate for your environment, and then either implement it or document why you didn't and what you did instead. Encryption is the canonical example: it's addressable, not strictly required — but if you choose not to encrypt PHI, you'd better have a written, defensible rationale and a compensating control, because a breach of unencrypted PHI is the fact pattern in nearly every published settlement. The safe default is to implement addressable specs and reserve the documented-exception path for the rare case where a control genuinely doesn't fit — the same discipline as a formal risk acceptance.
The risk analysis is the keystone — and the thing most teams skip
If there is one requirement the regulator looks for first, it's the risk analysis: a documented, accurate assessment of where PHI lives, how it flows, and what threatens it. Its absence is the most commonly cited failure in HIPAA enforcement, because without it every other safeguard is unanchored — you can't right-size a control to a risk you never mapped.
This is where HIPAA leans directly on the foundations of the rest of your program. You cannot perform a credible risk analysis without first knowing what data you hold and where, which is exactly what data classification and discovery produces — the unmanaged PHI copy in a staging database or a forgotten export is precisely the gap the rule wants you to find. And the analysis isn't a one-time document; new services, new data flows, and new vendors all move the risk, so it's a continuously verified artifact, refreshed as reality changes rather than written once and filed.
Your vendors inherit the obligation, too
Sign a BAA and you take on PHI — but you almost certainly pass some of that PHI to your own subprocessors: your cloud host, your email provider, your analytics tool. Each of those that touches PHI needs its own BAA with you, and each becomes a node in your vendor risk management program. A subprocessor handling PHI without a signed BAA is a compliance gap and a real breach-liability exposure rolled into one. The flip side is operational: you cannot sign BAAs with vendors you don't know you use, which makes shadow-IT discovery a HIPAA control in disguise — the unsanctioned tool quietly ingesting health records is the exposure the BAA chain was supposed to close.
Breach notification raises the stakes
HIPAA is unusual in how concretely it punishes the failure to protect data: a breach of unsecured PHI triggers mandatory notification to affected individuals, to the regulator, and — above a threshold — to the media. That notification regime is why the encryption decision matters so much. Properly encrypted PHI generally falls under a safe-harbor that can take a lost device or stolen backup out of "reportable breach" territory entirely. The same encryption-at-rest discipline that's good hygiene everywhere becomes, under HIPAA, the difference between a quiet asset write-off and a public, regulator-notified incident.
What a platform does, and the line it does not cross
A posture platform can map the HIPAA Security Rule safeguards to the controls you actually run, track which are implemented and which are gaps, hold your risk-analysis documentation and policies with owners and review dates, keep your BAA and subprocessor inventory current, and archive the evidence — access reviews, encryption status, training records, audit logs — so that if a regulator or a covered-entity customer ever asks, you produce a current, organized record instead of a scramble. It organizes, tracks, and prepares the work, and keeps it continuously verifiable.
One honest caveat — and under HIPAA it matters more than anywhere: a platform does not make you HIPAA compliant, certify you, or grant or guarantee any HIPAA attestation, because no such certificate exists to grant. HIPAA compliance is a legal posture you maintain and must be able to demonstrate; the safeguards, the signed BAAs, the risk-analysis judgments, and the breach-notification decisions are your organization's to own. Whether you are a covered entity or business associate at all, and which specifications are reasonable for you, are questions for qualified counsel — not software. A platform proves you did the work; it cannot do the work or stand in for the lawyer.
HIPAA isn't a badge you earn — it's a set of safeguards you run and a record you can produce on demand. Map the administrative, physical, and technical controls to what you already do, anchor everything to an honest risk analysis, keep the BAA chain closed, and treat the evidence as a living artifact. Do that and the BAA on your desk becomes a deal you can sign instead of a liability you can't measure.