NIST SP 800-66 Rev. 2 for HIPAA Security Rule: how to implement it

How do you use NIST SP 800-66 Rev. 2 to implement the HIPAA Security Rule?

A covered entity or business associate that must show Security Rule compliance to a customer, contract or OCR should start by treating *NIST SP 800-66 Rev. 2* (February 2024) as a resource guide, not a checklist of legal obligations. It gives key activities, descriptions and sample questions for every Security Rule standard, and HHS lists it in its Security Rule guidance as informational, not legally binding. The Security Rule itself, in 45 CFR Part 164 Subpart C, remains the requirement. The practical value of the guide is that it turns each standard into concrete activities and questions your team can answer with evidence. The ownership split matters before any work starts. The organization owns its controls and the decisions about them. An implementation partner can help prepare systems, configurations, policies and evidence against the guide's questions. Only an independent auditor or assessor can report on the results. HIPAA has no certification, and HHS does not endorse private certifications, so no outside party can issue a HIPAA certificate. Any document that claims otherwise should be treated with suspicion, and the written scope of any engagement should say who produces which artifact.

The effort varies widely, and the difference is usually set by three factors. The first is the scope of ePHI systems: how many applications, databases, endpoints, backups and integrations store, process or transmit ePHI, and whether they run on-premises, in a cloud account or across both. The second is the number of business associates and subcontractors whose access to ePHI must be documented and reviewed under the organizational standards. The third is the evidence you already have. Teams with a current risk analysis, tested backups, access reviews and training records start with artifacts to test against the guide. Teams without them begin by producing those artifacts, which takes longer. Before accepting a quote, ask the provider to list the systems in scope, the business associates included, and the existing evidence they expect to reuse.

How to run the risk assessment using SP 800-66 Rev. 2 Section 3

This sequence turns the risk analysis required by 45 CFR 164.308(a)(1)(ii)(A) into a documented, repeatable record of where ePHI lives, what could go wrong, how likely it is and how much harm it would cause. The outputs are the evidence an assessor or OCR investigator will ask to see.

Define the scope and assign ownership
Name the people accountable for the analysis, usually the security official with input from clinical, operations and IT leads, and set the boundary of what is in scope. Include every system, application, device, service and business associate that creates, receives, maintains or transmits electronic protected health information. The output is a signed scope statement and a list of named owners. You know this step is done when every ePHI flow you know about falls inside the stated boundary.
Inventory where ePHI is created and stored
Map each system and data flow that touches ePHI, including cloud tenants, on-premises servers, backups, endpoints, removable media, email, and interfaces to third parties. Record the data type, the location, the owner and the business associate involved. The output is an asset and data flow inventory, ideally kept in a configuration database or a controlled spreadsheet. Check it by comparing the inventory against network discovery results and access logs, and note any gaps for follow-up.
Identify threats and vulnerabilities
For each asset, list the threats that could exploit it, such as phishing, ransomware, insider misuse, misconfiguration or natural hazards, and the vulnerabilities that make exploitation possible. Draw on vulnerability scan results, configuration reviews, penetration test findings, incident history and vendor advisories. Section 3 of SP 800-66 Rev. 2 and its Appendix C tables help structure this work. The output is a threat and vulnerability list linked to each asset, and you know it is complete when each asset has been reviewed against the same categories.
Determine likelihood using the existing controls
Estimate how likely each threat is to exploit each vulnerability, taking into account the safeguards already in place. OCR's guidance draws on the definitions in NIST SP 800-30, under which risk is a function of the likelihood that a threat exploits a vulnerability and the resulting impact. Use a consistent scale, such as low, medium and high, and record the reasoning behind each rating. The output is a likelihood rating with its evidence, and the check is that two reviewers reach similar ratings for the same entry.
Determine impact on confidentiality, integrity and availability
Assess the harm to patients and the organization if each exploitation succeeds, covering disclosure of ePHI, alteration of records, and loss of access to care systems. Consider the number of individuals affected, the clinical consequences of downtime and the regulatory exposure, including breach notification duties. Use the same scale as the likelihood rating so the two can be combined. The output is an impact rating per asset and scenario, and you know it is done when each rating has a short written rationale.
Combine ratings into a risk register
Multiply or otherwise combine likelihood and impact according to the scale you chose, then rank each risk. Record the current control set, the residual risk and the proposed treatment for every entry, such as accept, mitigate, transfer or avoid. The output is a risk register with a named owner and a status for each risk. You know it is complete when every high or medium risk has a documented treatment decision and an accountable owner.
Document the results and the decisions
Write up the scope, method, scale definitions, assumptions, the risk register and the reasons for each treatment decision in a single report that the security official approves. Keep the document with the policies that govern risk management, since 45 CFR 164.316 requires written documentation of Security Rule actions. The output is a dated, approved risk analysis report. Check that someone outside the analysis team can follow the reasoning from the inputs to the decisions.
Schedule updates and track the treatment plan
Link each risk to a remediation task with an owner and a review point, and set a schedule for updating the analysis when systems, vendors or threats change. The HHS free risk analysis tool is one option some organizations use to structure these steps, and buyers should evaluate it against their own environment before relying on it. The output is a tracked risk management plan and an update schedule. You know this step is working when the register changes over time and each change is traceable to a decision.

Which key activities to run for each safeguard group

NIST SP 800-66 Rev. 2 organizes its guidance around the Security Rule's standards, and each group asks for a different kind of proof. The cards below pair the main key activities in each group with the evidence a reviewer would expect to see, so you can check coverage before an assessor does. The organization owns these controls; an implementation partner can prepare the systems and records, but only an independent assessor issues findings.

Administrative safeguards

Start with the risk analysis under 45 CFR 164.308(a)(1)(ii)(A), then run the periodic evaluation the guide describes for the administrative standards. Reviewers usually ask for a dated risk analysis, a risk management plan tied to its findings, and evaluation results showing what changed after each review. Check that the security official is named in writing and that workforce access reviews produce signed records, not just policy text. Confirm the risk analysis covers every system holding ePHI, including backups and vendor-hosted services.

Physical safeguards

Focus on facility access controls, workstation use and device and media controls, including disposal and re-use. The guide's sample questions point toward documented procedures plus proof they run: visitor logs, badge access reports, workstation configuration standards, and media sanitization records. For cloud-hosted ePHI, the question shifts to what the provider's physical controls are and whether you hold current evidence of them. Confirm who signs off on device disposal and where those sign-off records are kept.

Technical safeguards

Work through access control, audit controls, integrity, person or entity authentication and transmission security. Reviewers typically want unique user IDs, role-based access lists exported from the system, audit log samples showing who viewed or changed ePHI, and evidence that logs are reviewed rather than only collected. Encryption and authentication settings should be captured as configuration evidence. Verify that log retention and review frequency are written down and that someone can produce a log extract on request.

Organizational requirements

Cover the business associate contracts and other arrangements required under 45 CFR 164.314, and, where relevant, the plan document requirements for group health plans and their sponsors. The evidence is executed agreements that contain the required security terms, a register of business associates with the date each agreement was signed, and a process that checks subcontractor terms flow down. Confirm that contract templates reflect the current rule text and that someone reviews vendor agreements when services change.

Policies and documentation

Cover the written policies and procedures required under 45 CFR 164.316 and the documentation specifications around retention, availability and updates. A reviewer expects each Security Rule requirement to map to a current, approved procedure, a version history showing when each document changed, and a retention practice that keeps required documents for six years. Check that staff can find the current version and that reviews are scheduled, because a policy that was never reviewed is hard to defend.

Why HHS treats SP 800-66 as informational, not a safe harbor

HHS lists NIST SP 800-66 Rev. 2 as informational guidance, not legally binding requirements. That placement matters for how you use the guide. Following its key activities for each standard is a sound way to build a program, but it does not prove that you comply with the Security Rule, and it does not shield you from an OCR finding if your safeguards turn out to be inadequate. OCR still asks the question the rule itself asks: are your documented measures reasonable and appropriate for your environment, given the risks you have identified? The same reasoning applies to the other NIST publications HHS lists as informational, including SP 800-30, which OCR draws on for its definitions of risk.

The practical consequence shows up most clearly in the addressable implementation specifications. Under 45 CFR 164.306(d), for each addressable specification you must assess whether it is reasonable and appropriate in your environment. If it is not, you must document why and implement an equivalent alternative if one is reasonable and appropriate. SP 800-66 gives sample questions that help you reach that judgment, but the decision is yours and it is the record of that decision that an assessor or OCR will examine. Ask your team to show, for each addressable specification you have set aside, the reasoning, the date it was reviewed and the alternative measure in place.

Confirm the current status of the proposed Security Rule revision before you rely on any requirement as settled. HHS proposed a major revision in 90 FR 898 on January 6, 2025, and it could change some specifications and the way they are documented. Check the Federal Register proposed rule and the current Unified Agenda entry before your next review cycle, and record which version of the requirements your program was built against.

How the NIST CSF crosswalk and SP 800-53 mapping help cloud and enterprise teams

HHS publishes a NIST Cybersecurity Framework to HIPAA Security Rule crosswalk as part of its Security Rule guidance material. It shows where CSF 2.0 outcomes overlap with the Security Rule's standards and implementation specifications, so a team that already runs a CSF program can reuse governance, asset, protection, detection and recovery work instead of building a parallel inventory. The crosswalk is informational. HHS lists it alongside NIST publications as resources that are not legally binding, so a mapped CSF outcome does not by itself prove a Security Rule requirement is met.

Reuse existing CSF evidence: Map the CSF outcomes your team already tracks to the Security Rule standards, then identify which HIPAA-specific items, such as the risk analysis and business associate assurances, still need their own evidence.
Check the crosswalk against the rule text: Read each mapped row against the cited section of 45 CFR Part 164 Subpart C, because a crosswalk can group requirements loosely.
Watch for addressable specifications: Record how each addressable specification was assessed and documented, since the crosswalk does not make that decision for you.
Keep HIPAA ownership clear: Assign a named Security Rule owner to each mapped area so CSF reporting does not stand in for HIPAA documentation.
Track versions: Confirm which version of the crosswalk HHS currently publishes before you cite it in a policy or audit response.

Before relying on the crosswalk in an audit, confirm the current version on HHS's Security Rule guidance page and test a sample of mapped outcomes against the evidence you hold.

What using SP 800-66 costs and who gets paid for each part

This table compares the cost components of running a HIPAA Security Rule program built on NIST SP 800-66 Rev. 2, showing who is paid for each part, whether it is one-time or recurring, and what moves it up or down. No dollar figures or durations are given here because they depend on the written scope of each engagement. Use the table to request line items from any quote and to see which costs stay with your staff even when you hire outside help.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Internal staff time for the security official and system owners	Your own workforce; no outside payee	Recurring	Number of ePHI systems in scope, how many system owners must answer SP 800-66 sample questions, and how often evaluations repeat
Outside help for risk analysis or readiness review	Consultant or assessor you engage, usually under a fixed-scope written agreement	One-time per cycle, plus updates when systems change	Size and age of the environment, quality of existing asset inventories, and whether the work covers Appendix C risk tables in full
Implementation partner work to configure controls and gather evidence	Implementation partner such as DeployOpen, under fixed scope and written deliverables	One-time for the initial build, recurring if retained for upgrades or testing	Number of self-hosted platforms, integration depth with identity and logging, and how much evidence collection is automated
Tooling for logging, access control, backup and monitoring	Software vendors for licenses, or your team and any provider for operating open-source components	Recurring	Choice between licensed and open-source tools, data retention volumes, and staffing needed to run them
Independent assessment fees, if you buy one	Independent assessor or certification body; the assessor issues any report	Recurring if you repeat the assessment on a schedule	Scope of systems tested, depth of evidence sampling, and whether the assessor reuses prior work
Remediation of gaps found in evaluation	Your staff, plus any implementation partner or vendor you engage	One-time per finding, with ongoing upkeep	Number and severity of gaps, legacy systems that cannot be patched, and vendor contract terms

What makes SP 800-66 implementation longer or more expensive

Effort for a NIST SP 800-66 Rev. 2 program grows with how much ePHI exists, where it runs, who handles it and how well it is already documented. The cards below cover the decisions and checks that move the timeline and quote most, and the scope controls that keep both in check.

Number of ePHI systems and locations

Every system that creates, receives, maintains or transmits electronic protected health information falls inside the Security Rule, and each one needs its own risk analysis entries and safeguard evidence. Start by narrowing scope to those systems, then inventory the sites, endpoints, backups and interfaces that touch them. Ask any implementation partner to price by system count and location, and to show how the inventory will be kept current after the work ends.

Cloud versus on-premises hosting

Cloud hosting splits safeguard responsibility between your team and the provider, so you must confirm which controls the provider operates, which it signs for, and which evidence it supplies. On-premises hosting puts physical, device and network safeguards fully in your hands. Confirm the provider's business associate terms before scoping, and ask for a responsibility matrix that maps each NIST SP 800-66 activity to an owner.

Business associates and their maturity

Each business associate that handles ePHI for you brings its own safeguards, contracts and evidence gaps to review. Mature vendors with current assurance documentation shorten the work, while vendors without written safeguards add research, contract changes and follow-up. Build a register of business associates, record which ones hold a written agreement, and ask each for security documentation before the evaluation begins.

Existing evidence and documentation

Policies, procedures and records that already exist shorten implementation, while missing or outdated ones force teams to write, approve and then prove each control. Check the written policies and procedures against the standards, confirm that documentation is retained and reviewed, and separate what is written from what is actually operated. An illustrative gap, such as a written access review policy with no completed review records, is often the largest source of unplanned rework.

Security official staff capacity

The Security Rule requires a designated security official, and the NIST guide assumes someone owns the program day to day. If that role sits with a person who also runs IT operations, activities such as risk analysis updates and periodic evaluations slip. Estimate the hours the role needs each month, decide whether to hire, reassign or outsource part of it, and confirm who signs off on evidence.

Open or undocumented risk findings

Open findings from earlier risk analyses, penetration tests or audits must be tracked to closure with a documented decision, which adds work when the list is long or ownerless. Undocumented findings are harder still because the team must first rediscover what was tested and why. Reconcile the findings register against the current risk analysis, assign owners and target dates, and record accepted risks with the reasoning behind each acceptance.

Who owns the controls, who prepares evidence, and who reports

The covered entity or business associate remains accountable for every Security Rule requirement, including those it hands to vendors. NIST SP 800-66 Rev. 2 describes key activities for each standard, but the organization decides how those activities apply to its own environment, which risks to accept, and how to document the reasoning. For each addressable implementation specification, the organization must assess whether it is reasonable and appropriate, and if it is not, document why and implement an equivalent measure where one is reasonable. Those decisions cannot be delegated to a consultant or platform vendor.

Control ownership: Named owners for each safeguard, with the authority to change configurations and accept residual risk.
Risk decisions: Approval of the risk analysis results, the risk management plan and any risk acceptance.
Addressable decisions: Written reasoning for each addressable specification, adopted or documented as an alternative.
Policies and sign-off: Written policies and procedures approved by management, with the Security Rule's documentation retained for six years.
Evaluation and vendor oversight: Periodic evaluation of the program and assurance from business associates under the contract terms.

Before any engagement begins, confirm in writing which decisions stay with your security official and leadership.

How to choose a consultant or assessor for a SP 800-66 program

NIST SP 800-66 Rev. 2 is a resource guide, not a certification, so no firm can issue a HIPAA certificate. The checks below help you separate an implementation partner that prepares your systems and evidence from an independent assessor that tests them, and they show what to get in writing before work starts.

Relevant HIPAA experience with references

Ask for named HIPAA Security Rule engagements of a similar size and environment, and request references you can call. Check whether the firm has worked through the standards in 45 CFR 164.308, 164.310 and 164.312 in systems like yours, such as hosted electronic health record environments or self-hosted patient portals. Ask how they handled an addressable specification they documented as not reasonable and appropriate, since that judgment is where weak advisers show their gaps. Confirm the named people will do the work, not only the sales lead.

Implementation partner or independent assessor

Decide early whether you need a firm to build and configure controls or a firm to test them. A firm that designs your safeguards should not also be the one that judges whether they work, or the result will carry little weight with OCR or your auditors. Ask in writing which role the firm plays for your engagement and whether it will perform any independent testing. No body accredits a firm to certify HIPAA compliance, so an assessment report is only as useful as the scope and method behind it.

Written scope and deliverables

Require a written scope that lists the systems, locations, business associates and Security Rule standards covered, along with the deliverables for each. For an NIST SP 800-66 program, the deliverables should include a documented risk analysis, the evaluation results for standard 164.308(a)(8), and a remediation plan with owners. Ask what is excluded, such as cloud provider controls you must inherit or a separate penetration test. Fixed scope with agreed deliverables makes cost comparable across bids.

How evidence is handed over

Agree up front on the format and ownership of evidence: risk analysis workpapers, policies, configuration exports, access reviews, training records and test results. Ask whether the evidence stays in your environment and your document repository or sits in the consultant's tools. Confirm that you can keep copies after the engagement ends and that the firm will explain each artifact so your workforce and auditors can use it. Documentation under 164.316 must be retained and available, so the handover needs to meet that standard too.

Business associate agreement for ePHI access

If a firm can view, store or process ePHI in any part of the engagement, it is a business associate and must sign a business associate agreement that meets 164.314. Ask for the agreement before you share any production data, and check how it covers subcontractors, breach notice and return or destruction of PHI at the end. Keep the firm's work on sanitized data or screenshots where that is enough. A firm that refuses to sign or says it does not need one should not receive ePHI.

Ongoing support and reassessment terms

NIST SP 800-66 treats evaluation as recurring, so the standard 164.308(a)(8) activities must repeat over time, not stop at the first report. Ask what support is included after delivery, how changes to systems are reviewed, and how often the risk analysis is refreshed. Separate one-time engagement fees from any retainer for ongoing support, testing or upgrades, and ask the firm to state both in the quote. Confirm who keeps the program running when the consultant's contract ends.

Questions buyers ask before using NIST SP 800-66 for HIPAA

Is NIST SP 800-66 mandatory for HIPAA compliance?

No. NIST SP 800-66 Rev. 2 is not legally binding. HHS lists it among its informational Security Rule resources, alongside other NIST publications, so it describes one way to work through the requirements rather than adding new ones. The binding obligations are the standards and implementation specifications in 45 CFR Part 164 Subpart C, sections 164.302 to 164.318. Your organization still has to decide, document and justify how it meets each one. Read the regulation first, then use the NIST guide to structure the work and the sample questions to test your own answers. The eCFR text of Subpart C is the authoritative starting point.

Does following NIST SP 800-66 make us HIPAA compliant?

Following the guide does not make you compliant on its own, and no HIPAA certification exists that would confirm it. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not prevent a later finding of violation. Compliance is judged on what your organization actually does: whether your risk analysis is accurate, your addressable specifications are reasoned and documented, and your safeguards operate in practice. The HHS FAQ on certification explains this position. Treat the guide as a method for building and evidencing your program, not as a finish line.

How long does a first NIST SP 800-66 implementation take, and what drives the timeline?

The duration depends mainly on the size and complexity of your ePHI environment, how many systems and business associates touch it, and how current your existing policies and risk analysis are. No supplied figure gives a standard duration, so ask any partner to show their estimate against your written scope. The biggest variables are usually inventory: mapping where ePHI is created, stored, transmitted and backed up. Next come the risk analysis itself, the decisions on addressable specifications, and the documentation and training that follow. Organizations with mature governance and clear system ownership typically move faster. Ask for milestones, the dependencies on your staff, and which evidence will be delivered at each stage.

Can our own team implement NIST SP 800-66 without outside help?

Yes, many organizations do this internally, and the guide is written so that a capable privacy or security team can work through it. The Security Rule requires that a designated security official be assigned, and the accountable decisions, including risk acceptance and the rationale for addressable specifications, must remain with your organization. Internal teams often struggle with objectivity in the risk analysis, time to evaluate every standard, and keeping technical evidence current across cloud and on-premises systems. Outside help can cover gap assessments, technical configuration reviews or documentation support. An independent assessor can test your program, but an assessor does not certify compliance. Decide which parts you own and which you need help with before you request a quote.

What do we need to provide to an implementation partner before work starts?

A partner needs enough detail to define a fixed scope and to avoid guessing at your environment. Prepare an inventory of systems, applications, cloud accounts, data centers and endpoints that store, process or transmit ePHI, along with network diagrams and identity sources. Provide your current policies, procedures, prior risk analysis results, business associate agreements, incident response plan and backup and contingency arrangements. Name the security official and the people who own each system and approve changes. Also list existing tools and any contractual or regulatory constraints, such as data residency limits. With this material, the partner can write a scope, deliverables and timelines that you can review and agree in writing before work begins.

Is there a HIPAA certification, and what do the proposed rule changes mean for this work?

There is no official HIPAA certification, so any vendor offering one is selling a private attestation that HHS does not recognize. HHS also proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists final action projected for July 2027. The proposal would tighten requirements such as encryption, multi-factor authentication, asset inventories and resilience testing. Until a final rule exists, build against the current regulation, and track the proposed changes in your risk analysis so the program can adapt. Confirm the current status on the Federal Register proposal before making commitments.

How DeployOpen scopes and prepares evidence for SP 800-66 work

DeployOpen works on SP 800-66 Rev. 2 work as an implementation partner, not as an assessor. We scope the work in writing, prepare the systems and documentation that support each Security Rule standard, and hand over evidence your organization owns and can present to an independent assessor or to OCR.

How we scope

Engagements are fixed-scope, with the covered standards, systems and deliverables agreed in writing before work starts.
The written scope names which in-house systems, cloud accounts or data centers hold ePHI and fall within the SP 800-66 work.
We confirm which activities your organization performs itself, such as risk decisions, workforce training and policy approval, and which we prepare.

How we build

We deploy and harden self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks.
Technical safeguards are configured to match the key activities for each standard, and the configuration is documented for review.
Security testing of applications, APIs and infrastructure can be scoped alongside the build to test the safeguards that were implemented.

How we hand over

You receive documentation that maps each in-scope standard to its key activities, configurations and the evidence that supports them.
Risk analysis inputs, such as system inventories and data-flow records, are delivered in formats your security official can maintain.
DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications; independent assessors do.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Evidence is refreshed when systems change, so the documentation stays current between periodic evaluations.
Ask any provider, including DeployOpen, to confirm in the written scope exactly which SP 800-66 activities they cover and which remain with your organization.