HIPAA Security Rule
Administrative, physical and technical safeguards under 45 CFR 164, with verbatim public-domain text.
What HIPAA Security Rule is
The HIPAA Security Rule sets the requirements for protecting electronic protected health information. It applies to covered entities — health plans, healthcare clearinghouses and most healthcare providers — and, since the HITECH Act and the 2013 Omnibus Rule, directly to business associates as well, which is how software vendors ended up inside its scope.
Its structure is three sets of safeguards. Administrative safeguards under §164.308 are the largest by some distance and cover the security management process, workforce security, access management, training, incident procedures, contingency planning and evaluation. Physical safeguards under §164.310 cover facility access, workstations and devices. Technical safeguards under §164.312 cover access control, audit controls, integrity, authentication and transmission security.
Every implementation specification is marked either Required or Addressable. Addressable does not mean optional — it means you must assess whether the specification is reasonable and appropriate for your environment, implement it if it is, and document the rationale plus any equivalent alternative if it is not. Undocumented addressable decisions are one of the most common findings in an OCR investigation.
Who it applies to
- Covered entities: health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically.
- Business associates — including SaaS vendors, analytics providers and hosting companies — who create, receive, maintain or transmit ePHI on behalf of a covered entity.
- Subcontractors of business associates, who are themselves business associates under the Omnibus Rule.
- Anyone who has signed a Business Associate Agreement, which is the moment the obligations become contractual as well as regulatory.
How it is structured in CMDash
CMDash seeds the implementation specifications across the three safeguard sets, keyed by their actual CFR citations — §164.308(a)(1)(ii)(A) rather than a renumbered internal identifier — so that a control row matches what an investigator or an auditor cites. The (R) and (A) markers from the regulation are carried in the specification titles.
| Administrative Safeguards | 29 |
| Physical Safeguards | 12 |
| Technical Safeguards | 12 |
These counts are the control rows CMDash actually seeds, checked against the seed files by a test on every build.
Scope: § 164.308, § 164.310 and § 164.312 only. § 164.314 (organizational requirements) and § 164.316 (policies, procedures and documentation) are not seeded.
The control text
53 of the 53 seeded controls carry the publisher’s own wording, taken from 45 CFR Part 164 (eCFR, as in force 2026-01-01). It is public-domain content, so CMDash reproduces it rather than paraphrasing — you assess against what the publisher wrote.
What CMDash does for HIPAA Security Rule
- Verbatim text from 45 CFR Part 164 as in force. US federal regulation is public-domain, so the actual regulatory language is in the product.
- Specification-level tracking with practical evidence requirements — the risk analysis specification asks for the assessment report and the methodology documentation, which is the artefact OCR asks for first in any investigation.
- The largest HIPAA-to-HITRUST crosswalk in the catalogue, plus a mapping to NIST CSF. That HITRUST mapping is the specific path most healthcare vendors end up walking when a customer escalates from "are you HIPAA compliant" to "are you HITRUST certified".
- Dated evidence with reviewer notes and timestamps, which is what makes an addressable-specification decision defensible years later.
- Every control is a tracked row with an owner, a status (not started, in progress, implemented, not applicable, at risk, failing), reviewer notes, and its own evidence requirements — not a checkbox on a spreadsheet.
- Evidence is uploaded against a specific control, dated, and kept on that control, so an assessor can see what was true when.
- Gaps export to a POA&M CSV — every control that is not implemented and not marked out of scope, with owner, status and evidence requirements.
- Policies you author in CMDash link to the controls they govern, so each control row shows which living policies stand behind it.
- A time-boxed, read-only external assessor seat can be scoped to just this framework, with an expiry date you set and a record of every page they opened.
What it shares with your other frameworks
CMDash seeds control-to-control crosswalk mappings, each with a confidence score. They are what stops the same artefact being gathered twice, and they are how a second framework costs a fraction of the first.
Where the evidence comes from
CMDash reads from the security tools you already run and turns what they report into control evidence. These are the integrations whose data lands closest to HIPAA Security Rule’s control groups — you decide which control each signal evidences, and CMDash keeps it current from then on.
Depth: how controls are evidenced
Control counts
53 controls in 3 groups, read from the same public control catalog that powers the HIPAA Security Rule control library. 53 carry the publisher’s own wording. 45 have at least one seeded crosswalk to another framework.
How controls are mapped to evidence
CMDash ships mapping suggestions, each a connector and a data type for one control, with the condition it is meant to check. A suggestion appears once a matching connector is connected and applies only when you accept it.
Once accepted, CMDash files a dated evidence record for that control each day while the connector stays connected, recording when it last synced. Only continuous-monitoring rules (a rule pack, or one you write) evaluate a condition and change a control’s status. You can map a connector to any control yourself.
Some suggestions are derived: a pre-built check for a control in another framework is reused here when a direct crosswalk edge between the two controls has confidence of at least 0.85. Derived suggestions are counted separately below and never added to the directly mapped ones.
Connector rules versus attested
Of 53 controls, 8 have a pre-built connector check, mapped by CMDash and not independently reviewed, that contributes evidence, and 0 more have a crosswalk-derived one. The other 45 have no shipped rule and are attested unless you add one. An attested control has an owner, a status, uploaded, dated evidence, and reviewer notes.
- Amazon Web Services: 164.308(a)(5)(ii)(D), 164.312(a)(2)(iv), 164.312(b), 164.312(d)
- Certn: 164.308(a)(3)(ii)(B)
- Checkr: 164.308(a)(3)(ii)(B)
- CrowdStrike Falcon: 164.308(a)(5)(ii)(B)
- Google Cloud Platform: 164.312(b)
- Google Workspace: 164.312(d)
- Jamf Pro: 164.312(a)(2)(iv)
- Microsoft Azure: 164.312(e)(1)
- Microsoft Entra ID: 164.312(d)
- Microsoft Intune: 164.312(a)(2)(iv)
- Okta: 164.308(a)(4)(ii)(C)
- SentinelOne: 164.308(a)(5)(ii)(B)
Evidence sources
7 integrations carry data relevant to 3 of the 3 control groups, listed under “Where the evidence comes from” above. You choose which control each signal evidences. Where a control has a shipped rule, its connector is named above.
What CMDash does not do
- CMDash does not certify HIPAA compliance. No HIPAA certification exists.
- CMDash does not decide whether an addressable specification is reasonable and appropriate for you. It records your decision and rationale as evidence.
- CMDash covers the Security Rule only. The Privacy Rule, the Breach Notification Rule and the Enforcement Rule are not control sets in CMDash.
Where CMDash stops
Published on purpose. A buyer who discovers a limit after signing is a support ticket and a refund conversation; a buyer who reads it here is making an informed decision.
- The Security Rule only. The Privacy Rule (45 CFR Part 164 Subpart E), the Breach Notification Rule and the Enforcement Rule are not seeded as control sets.
- HIPAA has no certification. Nobody can certify you compliant, and any vendor offering to is selling something that does not exist. What exists is a documented risk analysis, implemented safeguards and evidence.
- The addressable-versus-required determination is a judgement you make and document. CMDash records the decision and the rationale as evidence; it does not make the call.
Common questions
Can we become "HIPAA certified"?
No such thing exists. There is no HIPAA certification body and no certificate. What you can have is a documented risk analysis, implemented and evidenced safeguards, and documented decisions on every addressable specification. Vendors selling HIPAA certification are selling a self-assessment with a logo on it.
What does "addressable" actually require?
An assessment, a decision and a record. You determine whether the specification is reasonable and appropriate for your environment; if it is, implement it; if it is not, document why and what equivalent measure you implemented instead. The failure mode is not choosing differently, it is having no record of the choice.
Our customers are asking for HITRUST instead. Does HIPAA work carry over?
Substantially. The HIPAA-to-HITRUST crosswalk is the largest HIPAA mapping CMDash seeds, and HITRUST was built partly by harmonising HIPAA in the first place. The gap is prescriptiveness — HITRUST tells you what to implement where HIPAA tells you to be reasonable — so expect new work, not a rebuild.
Also in Privacy & Sector Regulation
Paid plans cap how many frameworks you run at once, never which ones — HIPAA Security Rule is available on every paid plan.
View pricingReady to see your posture?
Start a 30-day free trial of any paid plan — a card is required, and it converts unless you cancel — or sign up for Free with no card at all.