A plain-language walk through 45 CFR Part 164 Subpart C — every standard, what it means operationally, and where teams fail it.
Scope
The Security Rule applies to electronic protected health information only. Paper is governed by the Privacy Rule’s safeguard requirements.
Who it binds: covered entities — providers who transmit health information electronically in connection with standard transactions, health plans, and clearinghouses — and, since the HITECH changes, business associates directly. If you are a health-tech company processing ePHI on a covered entity’s behalf, the Security Rule applies to you in your own right, not merely through your contract. “Electronic” is read broadly: databases, email, backups, laptops, phones, removable media, and anything transmitted over a network. The rule’s own structure is compact — general requirements at §164.306, the three safeguard categories at §§164.308, 164.310, and 164.312, organisational requirements at §164.314, and the documentation standard at §164.316. Everything on this page hangs off those six sections.
Required versus addressable
Required means implement it. Addressable means implement it, or implement an equivalent alternative, or document why it is not reasonable and appropriate. Addressable never means optional.
This distinction, set out at §164.306(d), is the most misunderstood sentence in HIPAA, and the misunderstanding has one consistent shape: treating “addressable” as “skippable”. The actual decision tree has three branches, and every branch produces paperwork. If the specification is reasonable and appropriate for your environment, implement it. If not, implement an equivalent alternative that achieves the same protective purpose — and document why. If neither is reasonable, document the assessment that led you there. The documented rationale is the compliance artefact; an addressable specification with no implementation and no rationale is a finding, full stop.
Encryption at rest is the canonical example. It is addressable, and in 2026 the honest assessment for almost any organisation is that it is reasonable and appropriate — storage-level encryption is a checkbox in every major cloud. The practical advice: treat addressable specifications as required unless you have a written, defensible reason otherwise, because that is exactly how a reviewer will treat them.
The three safeguard categories
Administrative safeguards are the largest by volume and where most findings occur. Physical safeguards are frequently ignored by remote-first organisations. Technical safeguards are where engineering teams over-index.
Administrative safeguards (§164.308) are nine standards covering the management of the programme: the risk analysis and risk management plan, a sanction policy, a named Security Officer, workforce access lifecycle, training, incident procedures, tested contingency plans, periodic evaluation, and business associate contracts. They dominate findings because they cannot be purchased — they are things your organisation does, on a calendar, with records.
Physical safeguards (§164.310) cover facilities, workstations, and device and media controls, including disposal. Remote-first companies routinely write this section off with “we have no offices”, which fails: home offices are physical environments, laptops are devices, and the disposal chain for departed employees’ hardware still exists.
Technical safeguards (§164.312) cover access control with unique user identification, audit controls, integrity, authentication, and transmission security. Engineering-led teams tend to do these well and then assume the job is done — which is roughly a third of the rule handled and the most-cited third neglected.
The starting point for all three is the risk analysis: the rule expects your safeguard choices to trace back to the risks you documented, which is why OCR requests the analysis first and reads everything else against it.
Flexibility of approach
The rule is deliberately scalable — a ten-person clinic and a national health system are held to the same standards with different reasonable implementations. This flexibility is why ‘we bought a compliant tool’ is not a defence.
§164.306(b) lists the factors you may weigh: size and complexity, technical infrastructure, cost of measures, and the probability and criticality of risks to ePHI. Cost is a legitimate factor in how you implement, never whether — the rule is explicit that security cannot be priced out of existence. The flexibility also explains why no product can be “HIPAA compliant” on your behalf and why no certification exists: HHS certifies nothing, and compliance is a property of your implementation, not your vendor list. A cloud provider’s BAA and encryption features are raw materials; the configured system, the trained workforce, and the documented decisions are the compliance.
What compliance looks like in practice
Stripped of the legal structure, a Security Rule programme is a short list of artefacts and habits: a current risk analysis and management plan; a policy set matching your real operations, acknowledged by the workforce; training records; an incident log with response procedures; tested backups; access reviews and same-day termination; BAAs in a register; and the six-year document trail proving all of it. If you can produce those on request, you are in the strong minority. If you want to know which ones you are missing, that is precisely what the free readiness assessment measures, and the full checklist breaks the rule down item by item.
Questions teams actually ask
We are a small business associate — does the full rule really apply to us? Yes, all of it, directly. What scales is the implementation, not the applicability: your risk analysis might be a week’s work rather than a quarter’s, your contingency plan two pages rather than forty. The flexibility provision exists so small organisations can comply proportionately, not so they can skip standards.
Our cloud provider signs a BAA and is ‘HIPAA eligible’ — how much does that cover? Less than the marketing implies. It covers their side of the shared responsibility line: physical data centres, infrastructure controls, their staff. Your configuration, your access model, your logging, your policies, your training, and your risk analysis remain entirely yours, and misconfiguration on your side of the line is your finding.
Where do penalties actually land? The civil money penalty structure is tiered by culpability — from violations the organisation could not reasonably have known about, up to wilful neglect left uncorrected — with per-violation amounts and annual caps rising by tier. The practical lesson in the structure: documented, good-faith effort moves you down tiers, and an ignored known risk moves you up them. The risk analysis you skipped is the difference between the bottom and the top of the range.
How long does building a defensible programme take? For a small organisation starting honestly from near zero: the assessment and remediation arc typically runs a few months of part-time effort, front-loaded in the inventory and policy adaptation. The recurring load after that is hours per month, not days — provided the calendar has an owner.
Where SuperHIPAA fits
Everything above is work. The platform does the parts that are mechanical — evidence collection, acknowledgement tracking, register maintenance, renewal reminders — and our team does the parts that need judgement. You keep the parts that need to be yours.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.