NIST CSF vs HIPAA: which one to start with and whether to do both
A covered entity or business associate structuring its security program should start from a legal fact: the HIPAA Security Rule is binding for electronic protected health information, while the NIST Cybersecurity Framework is voluntary. The Security Rule, codified at 45 CFR Part 164 Subpart C, sets the floor. The CSF can organize the wider program around it, but it does not replace any Security Rule standard or implementation specification. Its required and addressable specifications must be handled in their own right, including the documentation the rule requires for addressable specifications that an entity decides not to implement as written.
Pursue HIPAA first when the program has no documented risk analysis, when ePHI sits in systems that have not been mapped, or when the open question is whether a required specification is in place at all. The HHS Office for Civil Rights treats the Security Rule as the test, and its Guidance on Risk Analysis says the rule does not prescribe a methodology. That means the entity must choose one and show its work. NIST SP 800-66 Rev. 2 maps key activities and sample questions to every standard, so it is the practical companion for that first pass. The CSF helps once the HIPAA baseline is understood, because its Govern function and the GV.OC-03 tracking outcome give the program a place to record legal and contractual obligations across the enterprise.
Doing both is the practical answer for most covered entities and business associates that also serve other regulated customers or hold broader enterprise risk. Confirm with counsel and the compliance lead which obligations apply, then record HIPAA specifications as the mandatory layer and map them into CSF categories for management reporting. Neither route produces a certificate. HHS states that no Security Rule standard requires certification and that it does not endorse or recognize private certifications, and NIST does not offer conformity assessment for the CSF. Ask any vendor who claims otherwise for the basis of that claim in writing.
How the CSF 2.0 and the HIPAA Security Rule differ on scope, structure and obligation
This table sets the CSF 2.0 against the HIPAA Security Rule on who is covered, binding status, structure, tiers, documentation and update path. Read it as a list of structural differences: the Security Rule defines what a covered entity or business associate must do for electronic protected health information, while the CSF gives an outcome structure that the organization applies on its own terms.
| Dimension | NIST CSF 2.0 | HIPAA Security Rule |
|---|---|---|
| Who it applies to | Any organization, regardless of size, sector or maturity; voluntary for most | Covered entities (health plans, clearinghouses, covered providers) and business associates, for electronic protected health information |
| Binding status | Voluntary; NIST is not a regulatory agency, though some customers or suppliers may require it | Binding federal law at 45 CFR Part 164 Subpart C (sections 164.302 to 164.318) |
| Structure | Core of 6 Functions, 22 Categories and 106 Subcategories | 18 standards across administrative, physical and technical safeguards, plus organizational and documentation standards |
| Specification types | Subcategories describe outcomes; Implementation Examples are published separately | 36 implementation specifications: 14 required and 22 addressable |
| Tiers and profiles | Four Tiers (Partial, Risk Informed, Repeatable, Adaptive) and Current and Target Organizational Profiles | No tiers or profiles; each standard is met through its required or addressable specifications |
| Documentation | Profiles and program records are the organization's own choice of content | Documentation standard in 164.316 applies; addressable decisions must be documented with reasons and any equivalent measure |
| Last formal revision | CSF 2.0 published February 26, 2024, succeeding Version 1.1 of April 16, 2018; no revision of the Core since | Last Federal Register amendment cited in the eCFR source notes is 78 FR 34266 of June 7, 2013 |
| Pending change | Quick-Start Guides, Community Profiles and informative reference mappings are updated online | Proposed revision published January 6, 2025 (90 FR 898, RIN 0945-AA22); no final rule as of October 2026; Unified Agenda projects final action in July 2027 |
| Certification | NIST offers no certifications or conformity assessment program | No certification exists; HHS does not endorse or recognize private certifications |
Who must meet HIPAA and who adopts the CSF
Under 45 CFR 164.302, the Security Rule applies to covered entities, which the regulation defines as health plans, health care clearinghouses and covered health care providers. The obligation covers electronic protected health information (ePHI) that the entity creates, receives, maintains or transmits. Compliance is measured against the standards and implementation specifications in Appendix A to Subpart C, along with the organizational and documentation standards in sections 164.314 and 164.316. Adopting the CSF does not replace any of these duties. Its value for a covered entity is as an organizing structure for the broader security program, with the HIPAA specifications mapped into it.
- Binding duties: Each standard is mandatory, and each implementation specification is either required or addressable. Addressable items require a documented decision and an equivalent alternative where reasonable.
- Enforcement exposure: OCR enforces through complaints, compliance reviews and audits, so the program must produce evidence on demand.
- Where the CSF fits: Govern and Identify outcomes can hold the risk analysis, asset inventory and policy decisions that OCR's guidance expects.
- Tracking obligations: GV.OC-03 Implementation Examples cover tracking legal requirements such as HIPAA, which gives a documented place to record it.
- No certificate: HHS states no Security Rule standard requires certification, so no CSF or third-party badge substitutes for the entity's own records.
Confirm with counsel which entity type applies to each affiliate, since classification determines the scope of ePHI and the documentation you must keep.
A business associate that creates, receives, maintains or transmits ePHI for a covered entity must also comply with the Security Rule under 45 CFR 164.302. This duty applies directly to the business associate, not only through its contract with the covered entity. Many vendors in cloud hosting, billing, claims processing, analytics and managed services fall in this group, even when their own customers never see the word HIPAA. The business associate's program must therefore cover its own systems, its own risk analysis and its own documentation, separate from whatever the covered entity has done.
- Direct obligation: The Security Rule applies to the business associate itself, so regulators can examine its controls.
- Customer requests: Covered entities often ask for evidence of safeguards through questionnaires, contract schedules and audit rights.
- Subcontractors: Business associates that pass ePHI to subcontractors carry flow-down obligations that the CSF's supply chain outcomes (GV.SC) can help track.
- Shared evidence: A CSF profile can give one structure for responding to several covered entity questionnaires, while HIPAA-specific answers still come from the Security Rule standards.
- Limits of the CSF: The CSF alone does not show that each addressable specification was assessed and documented.
Ask each covered entity customer which HIPAA artifacts it expects, such as the risk analysis and policy documentation, and confirm the contract terms before choosing a framework structure.
Organizations that are neither covered entities nor business associates, such as health technology companies that do not handle ePHI, insurers' non-health business units, or general enterprises, are outside the Security Rule. They adopt the CSF for their own reasons. NIST is not a regulatory agency, and its CSF FAQs state that most organizations use the framework voluntarily. Some companies do require the CSF of customers or suppliers, and that contractual pull is often the real driver. Federal agencies are a separate case, since a 2017 executive order made the CSF mandatory for U.S. federal agencies.
- Voluntary adoption: The CSF gives a common vocabulary of six Functions and 106 Subcategories for risk discussions with boards and executives.
- Supplier requirements: Some customers and procurement teams ask suppliers to describe their CSF alignment, often with a current profile and target profile.
- No regulator: NIST does not inspect, certify or endorse implementations, so a supplier cannot present CSF conformity as a certificate.
- Confirm the request: Ask whether the customer wants a self-assessment, a profile, evidence for specific Subcategories, or an independent report.
- Other frameworks: Customers may instead ask for SOC 2 or ISO 27001, which carry their own proof types.
Before committing to a CSF profile, ask the requesting customer exactly what evidence it will accept and how it will verify your claims.
How OCR treats recognized security practices and risk analysis
The key point for a covered entity or business associate is that the 2021 HITECH amendment requires OCR to consider recognized security practices, but it does not turn the CSF into a safe harbor. The amendment directs OCR to consider, in certain Security Rule enforcement and audit activities, whether an entity had recognized security practices in place for the prior 12 months. Those practices are the ones an entity has adopted in good faith, and the amendment does not name the CSF as one of them. Before you rely on any framework in an enforcement conversation, confirm with counsel how the amendment applies to your entity, which activities it reaches, and how you would document the 12-month period.
OCR does not prescribe a single risk analysis method. Its Guidance on Risk Analysis says that no single method or best practice guarantees compliance and that methods vary with the organization's size, complexity and capabilities. The guidance draws on the definitions in *NIST SP 800-30* for vulnerability, threat and risk, where risk is a function of the likelihood that a threat exploits a vulnerability and the resulting impact. A practical check is whether your risk analysis records, for each system that handles electronic protected health information, the threats considered, the vulnerabilities identified, the likelihood and impact you assigned, and the decisions you made about each risk.
For the method itself, *NIST SP 800-66 Rev. 2* (February 2024) gives risk assessment guidance in its Section 3, with supporting risk assessment tables in Appendix C. HHS lists it as informational rather than legally binding, so treat it as a resource for building your analysis, not as a requirement. Use the CSF to organize how the analysis feeds governance and risk decisions, and use the Security Rule's risk analysis specification as the legal benchmark. Ask your team to confirm which activities OCR would review in your case and whether your current records would show the analysis the Security Rule expects.
Where the CSF and HIPAA overlap, using NIST's own mappings
NIST's CSF 2.0 Reference Tool connects the framework's outcomes to HIPAA-relevant resources, most directly through GV.OC-03 and the SP 800-66 Rev. 2 guide. These overlaps help you reuse work across both programs, but they show where the two sets of expectations meet, not that meeting the CSF satisfies the Security Rule.
Risk assessment and risk management
The HIPAA Security Rule requires an accurate and thorough risk analysis, and OCR's guidance does not prescribe a method. NIST SP 800-66 Rev. 2 Section 3 and its Appendix C supply risk assessment guidance and tables that many teams use to document HIPAA risk analysis, while CSF categories under the Identify function frame the enterprise-level risk view. Check whether your risk register records ePHI assets, threats, likelihood and impact in a form OCR can review.
Tracking legal requirements under GV.OC-03
GV.OC-03 covers legal, regulatory and contractual requirements. NIST's first Implementation Example for it names a process for tracking privacy laws such as HIPAA, the CCPA and the GDPR. A HIPAA entry in that register can show who owns the Security Rule obligations, how changes such as the pending Security Rule revision are picked up, and how the program reports against them. Confirm that the register records the Security Rule itself, not only the CSF outcome.
Supplier and business associate oversight
The second GV.OC-03 Implementation Example covers tracking contractual requirements for supplier, customer and partner information. For HIPAA, this maps naturally to business associate agreements and the security obligations passed to subcontractors that handle electronic protected health information. Use the CSF supply chain outcomes to organize vendor inventories and reviews, then verify that each business associate agreement contains the terms the Security Rule requires, since the CSF does not supply that contract language.
Aligning strategy with legal duties
The third GV.OC-03 Implementation Example addresses aligning cybersecurity strategy with legal, regulatory and contractual requirements. For a covered entity, this means the security strategy approved by leadership should explain how HIPAA obligations shape priorities, budgets and risk acceptance decisions. Ask whether the Organizational Profile, with its Current and Target states, records HIPAA as a driver and whether the Target state reflects the Security Rule's required specifications.
Non-NIST mappings need your own review
NIST says it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement. The CSF 2.0 Reference Tool export lists 363 Implementation Examples and informative references, which is a large starting set. Treat each HIPAA-related reference as a pointer to verify against 45 CFR Part 164 Subpart C and your own environment before you cite it as evidence in an OCR review.
What the CSF alone does not satisfy under HIPAA
The CSF can organize a HIPAA program, but it does not replace the Security Rule. The binding obligations are the standards and implementation specifications in 45 CFR 164.308, 164.310 and 164.312, plus the organizational and documentation standards in 164.314 and 164.316. A CSF Subcategory such as GV.OC-03 tells you to track the laws that apply to you. It does not tell you that a covered entity must have a designated security official, a workforce clearance procedure or a contingency plan with the specific elements the rule names. Those are the items OCR checks, and a CSF profile that merely references them is not the same as having them in place.
The addressable specifications need their own decision record. Under 45 CFR 164.306(d), for each addressable implementation specification you must assess whether it is reasonable and appropriate for your environment. If it is not, you must document why and implement an equivalent alternative measure where that is reasonable and appropriate. A CSF Implementation Example can point at the control area, but the reasoning behind each yes, no or alternative decision is the record that matters in an OCR investigation. Ask your team to confirm that every addressable specification has a dated assessment and a documented outcome, including the ones a framework mapping marks as covered.
Enforcement exposure continues regardless of which framework you use. The inflation-adjusted civil money penalty table in 45 CFR 102.3, as applied to penalties assessed on or after January 28, 2026, runs from $145 per violation for no knowledge up to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. Because OCR's 2024 to 2025 audits focus on hacking and ransomware provisions, confirm with your compliance lead that the HIPAA-specific documentation can be produced on request, and that its current state matches what your CSF profile claims.
Who assesses each framework, what it produces and how often
This table compares who checks each framework, what artifact the organization ends up with and how often that check recurs. Read it to see that the CSF produces no external proof, HIPAA produces no certificate but carries OCR enforcement, and the cadence for HIPAA must be confirmed rather than assumed.
| Dimension | NIST CSF 2.0 | HIPAA Security Rule |
|---|---|---|
| Who assesses | No accredited assessor. NIST does not certify or endorse CSF implementations or services | No certification body. HHS does not endorse or recognize private certifications, and OCR enforces the rule directly |
| Output an outsider can see | None issued by NIST. Any internal profile, self-assessment or report is the organization's own record | No certificate. Evidence is the documented risk analysis, risk management plan and policies that OCR reviews if it investigates |
| Conformity assessment program | None, and NIST has no plans to develop one | Not applicable. No Security Rule standard requires certifying compliance |
| Regulator activity | NIST is not a regulator. Federal agencies were made to use the CSF by a 2017 executive order, and some customers or suppliers may require it | OCR investigates complaints, runs compliance reviews and audits. Its 2024 to 2025 HIPAA audits review 50 covered entities and business associates on hacking and ransomware-relevant provisions |
| Penalty exposure | None attached to the framework itself | Civil money penalties apply. For penalties assessed on or after January 28, 2026, the per-violation range runs from $145 to $2,190,294 (45 CFR 102.3) |
| Review cycle | Voluntary and self-directed. NIST publishes new Quick-Start Guides and mappings, but the CSF 2.0 Core has no revision since February 2024 | No fixed assessment cycle appears in the researched facts. Confirm cadence with counsel and OCR guidance, and note that a major Security Rule revision is proposed but not final |
| What to confirm before relying on it | Which internal review cadence your board, customers or suppliers expect in writing | Whether any audit, contract or state requirement sets a frequency, and how the pending Security Rule revision would change documentation duties |
Doing both: the order that avoids duplicate evidence
This sequence builds one scope, one risk record and one evidence set that serves both the HIPAA Security Rule and the CSF, so each control is documented once and mapped outward. Each step ends with an artifact you can show an auditor or OCR.
Confirm HIPAA scope and business associate status
Start by documenting which entity is a covered entity, business associate or both, and which systems create, receive, maintain or transmit electronic protected health information. Legal or privacy counsel should confirm role determinations, since the Security Rule applies to covered entities and business associates under 45 CFR 164.302. The output is a signed scope statement with a system inventory that names every ePHI boundary, so the CSF Organizational Profile and the HIPAA program draw from the same asset list.
Complete the risk analysis using OCR methodology
Run the risk analysis using the OCR Guidance on Risk Analysis, which states that the rule does not prescribe a single method. Use the SP 800-30 definitions of vulnerability, threat and risk, and draw on NIST SP 800-66 Rev. 2 Section 3 and its Appendix C tables for structure. The risk analysis owner signs off the findings, likelihood and impact ratings, and a prioritized treatment plan. This document is the anchor artifact: CSF Identify and Govern outcomes should cite it rather than create a parallel risk register.
Map Security Rule specifications to CSF Subcategories
Use the CSF 2.0 Reference Tool export to link each Security Rule standard and implementation specification in Appendix A to Subpart C to the Subcategories it supports, and check the informative references to SP 800-66 and SP 800-53 Rev. 5.2.0 where they help. NIST does not verify non-NIST mappings, so the compliance lead should review each link against the organization's own controls before relying on it. The output is a crosswalk workbook with a named reviewer and a date of review.
Record required and addressable decisions
For each of the 36 implementation specifications, record whether it is required or addressable. For every addressable specification, document the assessment of whether it is reasonable and appropriate, and if it is not, the reason and the equivalent alternative measure, as 45 CFR 164.306(d) requires. Security leadership approves the decisions. The output is a decision log that a single entry can point to from both the HIPAA file and the CSF Subcategory mapping, so reviewers see one rationale instead of two.
Set up GV.OC-03 tracking of HIPAA and contracts
Configure a process under GV.OC-03 that tracks HIPAA alongside other legal and contractual obligations, including business associate agreements, customer security terms and supplier requirements. NIST publishes three Implementation Examples for this outcome, which you can adapt. Assign the privacy or compliance function to maintain the register and review it on a defined cycle you set internally. The output is an obligations register with the source clause, owner and control mapping for each entry.
Assign owners and evidence locations
Name one owner for each Security Rule standard and the matching CSF Subcategories, then record where the evidence lives, such as the ticketing system, policy repository or cloud audit log. Confirm that a single evidence item can satisfy both frameworks without duplicate collection. The output is an evidence index that lists control, owner, location and retention rule, which you can produce on request for OCR or for a customer assessment.
Schedule review as the proposed rule is finalized
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), and as of October 2026 no final rule has been published. Set a review trigger tied to publication of the final rule, and to any update of the CSF Reference Tool export or NIST SP 800-66 guidance. Record which mappings and decisions would change. The output is a dated change log showing that the crosswalk, decision log and obligations register were reviewed against the current text.
How much work does each framework need, and what it costs to get help
Is there a HIPAA certificate I can buy to prove compliance?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation. Any vendor or consultant offering a HIPAA certificate should be asked which HHS guidance supports the claim. Proof of compliance is the documented evidence that your risk analysis, safeguards and policies exist and operate, and that evidence is what OCR reviews in a complaint investigation, compliance review or audit. Build the evidence file, not a certificate.
Can I satisfy HIPAA by adopting the NIST CSF alone?
No. The CSF is a voluntary outcome framework, and it does not replace the Security Rule's binding requirements in 45 CFR Part 164 Subpart C. The CSF does not set the required and addressable implementation specifications, the documentation standards in sections 164.314 and 164.316, or the risk analysis obligation as written in the rule. Many organizations use the CSF to structure the program and track HIPAA as an informative reference under GV.OC-03, then use NIST SP 800-66 Rev. 2 for Security Rule implementation detail. That combination still needs your own HIPAA-specific evidence.
What drives the effort and cost of a HIPAA Security Rule program compared with a CSF program?
The main drivers are the same for both, but the HIPAA side adds fixed obligations. For a HIPAA program, effort rises with the number of systems that create, receive, maintain or transmit electronic protected health information, the number of business associates whose agreements and controls you must track, how much current documentation already exists, and how mature your risk analysis process is. For the CSF, effort rises with the number of Organizational Profiles you maintain and how many informative references you map. Because the Security Rule has 36 implementation specifications, with 14 required and 22 addressable, an organization with weak documentation usually spends more time on evidence than on design.
What must my organization supply before outside help can start?
Outside help depends on access you control. Plan to supply:
- A system inventory that identifies every location of electronic protected health information, including cloud services and endpoints
- Current policies, procedures and any prior risk analysis, even if incomplete
- Named owners for each system, process and business associate relationship, with time from those people for interviews and reviews
- Read access to configuration, logs and access records so testing and evidence collection can be checked
- A decision-maker who can accept or reject risk treatment choices
Missing inventory is the most common reason scoping takes longer than expected, and it should be confirmed before any quote is finalized.
Which costs are one-time and which recur for HIPAA and the CSF?
One-time work usually includes the initial scoping, the first risk analysis, gap assessment, policy and procedure drafting, system hardening, and the first mapping of CSF Subcategories to your controls. Recurring work includes periodic risk analysis updates, access reviews, workforce training, business associate tracking, vulnerability management, incident response exercises, and evidence refresh for audits or OCR inquiries. The Security Rule is a continuing obligation, so recurring costs tend to be larger than people expect. The CSF has no certification cycle, but a Target Profile and tiers still need to be reviewed as systems change. Ask any provider to split its quote into these two buckets.
Can my own team do this without an outside firm?
Often yes, for a team that has security engineers, someone who owns HIPAA compliance, and time to run a documented risk analysis. NIST SP 800-66 Rev. 2 is a free NIST resource guide that gives key activities and sample questions for every Security Rule standard, and HHS lists it as informational, not legally binding. Outside help is most useful when the team lacks experience with risk analysis methodology, needs an independent review of evidence, or must implement hardening and monitoring in a short window. OCR's guidance states that no single risk analysis method is prescribed, so your team must choose and document one that fits its size and complexity.
What should I ask for in a written quote for HIPAA or CSF work?
Ask the provider to state, in writing:
- The systems, locations and business associates in scope, and what is excluded
- The deliverables, such as the risk analysis report, control mapping, policy set and evidence index
- Which parts are one-time and which are recurring, with the frequency of each
- Who performs each task, and which of your staff must be available, and for how long
- Assumptions about existing documentation, and what triggers a change order
- How the work maps to NIST SP 800-66 Rev. 2 and to the CSF functions, if you use them
- Whether the provider states that it prepares evidence for your assessor but does not issue a certificate or audit report
A quote without these items is hard to compare with another quote.
Does DeployOpen issue a HIPAA certificate or attest to HIPAA compliance?
No. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and HIPAA has no certification to issue. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support and continuous testing are available as retainers.
How DeployOpen scopes and prepares readiness for both frameworks
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for compliance assessments. For NIST CSF vs HIPAA, we start from the Security Rule's binding requirements, map the CSF outcomes around them, and agree the result in a written, fixed scope before any work begins.
How we scope
- Confirm which covered entity or business associate functions, systems and electronic protected health information fall inside the written scope.
- Record which HIPAA standards and implementation specifications are in scope, and how each addressable decision will be documented.
- Agree which CSF Functions, Categories and Organizational Profiles the engagement covers, including the Current and Target profiles.
How we build
- Map Security Rule safeguards to CSF Subcategories, showing where a single control evidences both frameworks and where HIPAA needs more.
- Configure and harden the self-hosted platforms in scope within your cloud accounts, data centers or air-gapped networks.
- Test the controls in scope, including the risk analysis inputs that OCR guidance expects you to document and keep current.
How we hand over
- Deliver the written documentation, control mappings and evidence sets agreed in the scope, organized for your assessors and auditors.
- Provide a tracking record for HIPAA under CSF GV.OC-03, so legal and contractual obligations stay linked to the cybersecurity strategy.
- Walk your team through the handover so they can operate, update and explain the program without us in the room.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope engagement.
- Retainers can cover updates when HHS finalizes Security Rule changes, which we would confirm against the final rule text as it is published.
- Confirm with your counsel and assessor what the CSF alone does not satisfy, since DeployOpen prepares evidence but does not issue attestations.
Sources and further reading
- HHS Security Rule Guidance Material ↗
- 45 CFR Part 164 Subpart C, Security Standards for the Protection of Electronic Protected Health Information ↗
- HHS FAQ 2003: Are we required to certify our organization's compliance with the standards? ↗
- NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 ↗
- NIST CSF 2.0 Reference Tool export: Core, Implementation Examples and Informative References ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide ↗
