Framework

NIST SP 800-66 Revision 2
HIPAA Security Rule on one operating record

NIST Special Publication 800-66 Revision 2 (February 2024) is the implementation companion to the HIPAA Security Rule. The guide replaces SP 800-66 Rev. 1 (October 2008) and maps the Administrative, Physical, and Technical Safeguards under 45 CFR Part 164 Subpart C to NIST SP 800-53 Revision 5 control families. This page covers the five implementation steps the guide expects (risk assessment, identifying reasonable and appropriate measures, implementing measures, documenting implementation, maintaining continuous security assurance), the safeguard-to-control mapping per 164.308, 164.310, 164.312, 164.314, and 164.316, the recurring failure modes covered entities and business associates hit during the OCR audit protocol, the audit evidence the implementation produces, and how a workspace-driven approach turns SP 800-66 into a defensible operating record rather than a static document the OCR investigator cannot reconcile with the live posture.

Get Started Free

No credit card required. Free plan available forever.

NIST SP 800-66 Revision 2: implementing the HIPAA Security Rule

NIST Special Publication 800-66 Revision 2 (February 2024), titled Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide, is the implementation companion to the HIPAA Security Rule (45 CFR Part 164 Subpart C). The guide replaces SP 800-66 Revision 1 (October 2008) and modernises the implementation guidance against the current threat landscape, the current NIST control catalogue (SP 800-53 Revision 5), and the current healthcare security operating model. SP 800-66 Rev. 2 is voluntary; it does not replace the regulation. It gives covered entities and business associates a structured implementation language the OCR Audit Protocol, the HITECH audit, and the parallel framework reads (HITRUST, SOC 2, NIST CSF 2.0) all consume.

For healthcare GRC teams, vulnerability management teams, AppSec teams, internal security teams, security engineering teams, and CISOs, SP 800-66 is the practical bridge between the HIPAA Security Rule and the NIST SP 800-53 Revision 5 control catalogue. Programmes that operate against NIST CSF 2.0, HITRUST CSF, or ISO 27001 do not migrate to SP 800-66; the guide reads as the federal-grade implementation companion that places those parallel frameworks into the Security Rule operating language without rebuilding the evidence pack per audit.

Why SP 800-66 Rev. 2 is the named implementation companion to the Security Rule

The HIPAA Security Rule is technology-neutral and outcome-oriented by design. The regulation describes what to achieve (the safeguards) and what reasonable documentation looks like, but it does not prescribe how the implementation should run, which technology stack should be used, or which control catalogue the evidence should map to. SP 800-66 Rev. 2 fills that gap. The guide is structured around five implementation steps the Security Rule expects (risk assessment, identifying and documenting reasonable and appropriate security measures, implementing the measures, documenting the implementation, maintaining continuous security assurance) and maps each Administrative, Physical, and Technical Safeguard to specific SP 800-53 Rev. 5 control families. The guide is voluntary; OCR enforces the regulation, not the guide. The guide is the federal-grade implementation language that turns the safeguards into a working programme.

The pairing with SP 800-53 matters operationally. A healthcare programme that adopts the SP 800-66 implementation language gets the federal control catalogue, the FedRAMP authorisation vocabulary, the NIST CSF 2.0 outcome map, and the parallel framework crosswalks for free. A healthcare programme that operates against the HIPAA Security Rule alone has to rebuild the implementation language per audit. SP 800-66 Rev. 2 is the integration layer between healthcare-specific regulation and the NIST control catalogue the rest of the security ecosystem already speaks.

The five implementation steps SP 800-66 Rev. 2 expects

SP 800-66 Rev. 2 organises the implementation work into five sequential steps. The steps are sequential in dependency rather than strictly in calendar time; continuous security assurance feeds the next risk assessment, so the programme operates as a cycle rather than as a one-off project. Each step has a named output the next step reads against and a documentation requirement the six-year retention rule at 164.316(b)(2) preserves.

Step 1: Conduct a HIPAA Security Rule risk assessment

NIST SP 800-66 Rev. 2 Section 5.1 anchors the implementation guide to the risk assessment requirement at 45 CFR 164.308(a)(1)(ii)(A). The guide recommends the methodology in NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments): identify the ePHI in scope, characterise the system, identify threat sources and threat events, identify vulnerabilities and predisposing conditions, determine likelihood, determine impact, and determine the resulting risk. The risk assessment output drives every downstream implementation decision the guide describes. Programmes that adopt SP 800-66 without grounding the work on the SP 800-30 risk assessment carry the rest of the implementation against assumed scope rather than against documented exposure.

Step 2: Identify and document reasonable and appropriate security measures

Section 5.2 covers the decision the Security Rule expects against every standard and implementation specification. Required specifications must be implemented as written; addressable specifications give the covered entity a documented choice (implement as written, implement an equivalent alternative, or document why neither is reasonable and appropriate). The guide expects the decision per specification to consider the size, complexity, and capabilities of the covered entity, the technical infrastructure, hardware, and software security capabilities, the costs of security measures, and the probability and criticality of potential risks to ePHI. The implementation rationale is itself evidence; OCR investigators routinely test the documented reasoning.

Step 3: Implement the chosen security measures

Section 5.3 walks each Security Rule safeguard against the operating implementation. Administrative Safeguards include the security management process, assigned security responsibility, workforce security, information access management, security awareness and training, security incident procedures, contingency plan, evaluation, and business associate contracts. Physical Safeguards include facility access controls, workstation use, workstation security, and device and media controls. Technical Safeguards include access control, audit controls, integrity, person or entity authentication, and transmission security. The guide maps each safeguard to NIST SP 800-53 Rev. 5 control families so the implementation reads the same control catalogue federal systems read.

Step 4: Document the security measures, rationale, and implementation

Section 5.4 reads against the documentation requirement at 45 CFR 164.316. The covered entity must maintain in written or electronic form the policies and procedures implemented to comply with the Security Rule, the actions, activities, and assessments required, and the documentation must be retained for six years from the date of creation or the date when last in effect, whichever is later. The guide expects the documentation to be available to those responsible for implementing the procedures, reviewed periodically, and updated as needed in response to environmental or operational changes affecting the security of ePHI.

Step 5: Maintain continuous security assurance

Section 5.5 covers the continuing obligation. Risk assessment is not a one-off project; the Security Rule expects the covered entity to monitor and periodically review the security measures, conduct evaluations after material change (new system, new vendor, significant incident, regulatory update), and at minimum annually. The guide expects vulnerability scanning, audit log review, access reviews, incident response testing, contingency plan testing, and security awareness reinforcement to operate on a defined cadence the covered entity can evidence with timestamped artefacts. Programmes that document the risk assessment once and go quiet until the next audit carry stale evidence into the OCR enquiry or HITECH audit.

Safeguard catalogue: Administrative, Physical, Technical, Organisational

SP 800-66 Rev. 2 maps the Security Rule safeguards directly to NIST SP 800-53 control families. The map is bidirectional. A control implementation reads as Security Rule evidence, and a Security Rule safeguard reads against a specific control family the assessor recognises. The mapping is the discipline that lets a single operating record serve the OCR Audit Protocol, the HITRUST assessment, the SOC 2 examination, and the NIST CSF 2.0 outcome report without rebuilding the evidence pack four times.

Administrative Safeguards (45 CFR 164.308)

SP 800-66 Rev. 2 Section 6.1 maps the nine Administrative Safeguards standards to NIST SP 800-53 control families and to specific tasks. Security Management Process (164.308(a)(1)) maps to Risk Assessment (RA), Planning (PL), and Program Management (PM) controls. Assigned Security Responsibility (164.308(a)(2)) maps to PM-2 Senior Information Security Officer. Workforce Security (164.308(a)(3)) maps to Personnel Security (PS). Information Access Management (164.308(a)(4)) maps to Access Control (AC). Security Awareness and Training (164.308(a)(5)) maps to Awareness and Training (AT). Security Incident Procedures (164.308(a)(6)) maps to Incident Response (IR). Contingency Plan (164.308(a)(7)) maps to Contingency Planning (CP). Evaluation (164.308(a)(8)) maps to Security Assessment and Authorisation (CA). Business Associate Contracts (164.308(b)) maps to System and Services Acquisition (SA). The maps are bidirectional; an SP 800-53 control implementation reads as Security Rule evidence and vice versa.

Physical Safeguards (45 CFR 164.310)

Section 6.2 maps the four Physical Safeguards standards. Facility Access Controls (164.310(a)) maps to Physical and Environmental Protection (PE) controls including PE-2 Physical Access Authorisations, PE-3 Physical Access Control, PE-6 Monitoring Physical Access, PE-8 Visitor Access Records. Workstation Use (164.310(b)) maps to System and Communications Protection (SC) and Configuration Management (CM) controls. Workstation Security (164.310(c)) maps to PE-5 Access Control for Output Devices and AC-11 Device Lock. Device and Media Controls (164.310(d)) maps to Media Protection (MP) controls including MP-2 Media Access, MP-4 Media Storage, MP-5 Media Transport, MP-6 Media Sanitisation, MP-7 Media Use. The guide is explicit that physical controls produce evidence on the same operating record as technical controls; the evidence pack should not separate them.

Technical Safeguards (45 CFR 164.312)

Section 6.3 maps the five Technical Safeguards standards to the SP 800-53 control catalogue. Access Control (164.312(a)) maps to AC-1 through AC-25 with specific reads against AC-2 Account Management, AC-3 Access Enforcement, AC-7 Unsuccessful Logon Attempts, AC-11 Device Lock, AC-12 Session Termination, AC-17 Remote Access. Audit Controls (164.312(b)) maps to Audit and Accountability (AU) family including AU-2 Event Logging, AU-3 Content of Audit Records, AU-6 Audit Record Review, AU-12 Audit Record Generation. Integrity (164.312(c)) maps to System and Information Integrity (SI) controls including SI-7 Software, Firmware, and Information Integrity. Person or Entity Authentication (164.312(d)) maps to Identification and Authentication (IA) controls including IA-2 Identification and Authentication (Organisational Users), IA-5 Authenticator Management. Transmission Security (164.312(e)) maps to SC-8 Transmission Confidentiality and Integrity, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection.

Organisational Requirements (45 CFR 164.314) and Policies, Procedures, and Documentation (45 CFR 164.316)

Section 6.4 covers the requirements that bind the safeguard implementation to the documented governance layer. Organisational Requirements (164.314) cover business associate contracts (with the required clauses for processor obligations, breach notification, sub-processor authorisation, audit rights, and assistance with data subject requests) and group health plan requirements. Policies, Procedures, and Documentation (164.316) require the covered entity to implement reasonable and appropriate policies and procedures to comply with the standards, to maintain documentation, to retain the documentation for six years from creation or last effective date, to make the documentation available to those responsible for implementing the procedures, and to review and update periodically. SP 800-66 Rev. 2 treats the documentation requirement as a first-class artefact; it is the evidence layer the rest of the implementation reads against.

NIST SP 800-53 control families the Technical Safeguards map to

The Technical Safeguards at 45 CFR 164.312 carry the bulk of the scanner-driven and authentication-driven evidence. SP 800-66 Rev. 2 maps each Technical Safeguard standard to the SP 800-53 Rev. 5 control families that produce the evidence; the table below names the control families the assessor reads against per safeguard and the implementation specifications they cover.

  • AC family (Access Control) for 164.312(a) Access Control. AC-2 Account Management, AC-3 Access Enforcement, AC-5 Separation of Duties, AC-6 Least Privilege, AC-7 Unsuccessful Logon Attempts, AC-8 System Use Notification, AC-11 Device Lock, AC-12 Session Termination, AC-17 Remote Access, AC-18 Wireless Access, AC-19 Access Control for Mobile Devices, AC-20 Use of External Systems. The Security Rule unique user identification requirement (164.312(a)(2)(i), required) reads against AC-2 and IA-2. The emergency access procedure (164.312(a)(2)(ii), required) reads against AC-2(2). The automatic logoff specification (164.312(a)(2)(iii), addressable) reads against AC-11 and AC-12. The encryption and decryption specification (164.312(a)(2)(iv), addressable) reads against SC-13 and SC-28.
  • AU family (Audit and Accountability) for 164.312(b) Audit Controls. AU-2 Event Logging, AU-3 Content of Audit Records, AU-4 Audit Log Storage Capacity, AU-5 Response to Audit Logging Process Failures, AU-6 Audit Record Review, Analysis, and Reporting, AU-7 Audit Record Reduction and Report Generation, AU-8 Time Stamps, AU-9 Protection of Audit Information, AU-11 Audit Record Retention, AU-12 Audit Record Generation. The audit controls requirement at 164.312(b) is purposely technology-neutral but the evidence set is the audit logging coverage matrix per ePHI system, the monitoring and review procedure, and the records of those reviews against a defined cadence. Gaps in coverage or review cadence are routine findings under OCR investigations following a breach.
  • IA family (Identification and Authentication) for 164.312(d) Person or Entity Authentication. IA-2 Identification and Authentication (Organisational Users) with enhancements IA-2(1) MFA to Privileged Accounts and IA-2(2) MFA to Non-Privileged Accounts, IA-3 Device Identification and Authentication, IA-4 Identifier Management, IA-5 Authenticator Management with enhancements covering password complexity, lifetime, and storage, IA-6 Authentication Feedback, IA-8 Identification and Authentication (Non-Organisational Users). Multi-factor authentication for ePHI access by remote, privileged, or external users is widely treated as the reasonable and appropriate baseline under the addressable specification.
  • SI family (System and Information Integrity) for 164.312(c) Integrity. SI-2 Flaw Remediation, SI-3 Malicious Code Protection, SI-4 Information System Monitoring, SI-7 Software, Firmware, and Information Integrity, SI-10 Information Input Validation, SI-11 Error Handling, SI-12 Information Management and Retention. The integrity requirement at 164.312(c) is paired with the audit controls and the contingency plan controls; the evidence set covers file integrity monitoring, database integrity constraints, immutable backups, change management records, and the patch lifecycle that prevents corruption rather than detecting it after the fact.
  • SC family (System and Communications Protection) for 164.312(e) Transmission Security. SC-7 Boundary Protection, SC-8 Transmission Confidentiality and Integrity with enhancements covering cryptographic protection, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-23 Session Authenticity, SC-28 Protection of Information at Rest. The HHS Guidance on Securing Electronic Protected Health Information names AES with a recognised symmetric key length and TLS configurations consistent with NIST SP 800-52 as appropriate cryptographic protection. SSL/TLS scan output, header analysis, and configuration baselines feed this safeguard with hard evidence on the operating record.
  • RA, PL, PM families (Risk Assessment, Planning, Program Management) for 164.308(a)(1) Security Management Process. RA-3 Risk Assessment, RA-5 Vulnerability Monitoring and Scanning, RA-7 Risk Response, RA-9 Criticality Analysis, PL-2 System Security and Privacy Plans, PL-4 Rules of Behaviour, PM-1 Information Security Program Plan, PM-9 Risk Management Strategy, PM-11 Mission and Business Process Definition. The Security Rule risk analysis at 164.308(a)(1)(ii)(A) reads against RA-3 and the methodology guidance in NIST SP 800-30 Rev. 1. The continuing risk management at 164.308(a)(1)(ii)(B) reads against RA-7 and PM-9.
  • CP family (Contingency Planning) for 164.308(a)(7) Contingency Plan. CP-1 Policy and Procedures, CP-2 Contingency Plan, CP-3 Contingency Training, CP-4 Contingency Plan Testing, CP-6 Alternate Storage Site, CP-7 Alternate Processing Site, CP-9 System Backup, CP-10 System Recovery and Reconstitution. The Security Rule contingency plan standard has five implementation specifications: data backup plan (required), disaster recovery plan (required), emergency mode operation plan (required), testing and revision procedure (addressable), and applications and data criticality analysis (addressable). The pairing with the SP 800-53 CP family gives the covered entity a specific implementation language and an evidence set the assessment can read against.
  • IR family (Incident Response) for 164.308(a)(6) Security Incident Procedures. IR-1 Policy and Procedures, IR-2 Incident Response Training, IR-3 Incident Response Testing, IR-4 Incident Handling, IR-5 Incident Monitoring, IR-6 Incident Reporting, IR-7 Incident Response Assistance, IR-8 Incident Response Plan, IR-9 Information Spillage Response. The Security Rule incident procedures at 164.308(a)(6) include response and reporting as required specifications. Pair with the Breach Notification Rule at 45 CFR Part 164 Subpart D so the incident lifecycle, the four-factor breach risk assessment, the notification timelines (without unreasonable delay and no later than 60 calendar days for affected individuals, with media and HHS notifications based on impact), and the rationale for any low-probability-of-compromise determination all read against one record.

Where SP 800-66 sits next to HIPAA, HITECH, HITRUST, SOC 2, NIST CSF 2.0

The healthcare security stack reads multiple frameworks in parallel. HIPAA (the Privacy Rule, the Security Rule, the Breach Notification Rule, and the Enforcement Rule at 45 CFR Parts 160 and 164) is the federal regulation. HITECH Act of 2009 amendments and the 2013 Omnibus Rule extend the regulation to business associates and increase enforcement. SP 800-66 Rev. 2 is the NIST implementation guide that pairs the Security Rule with the SP 800-53 control catalogue. HITRUST CSF is the private-sector certifiable framework many enterprise health systems and business associates adopt to give a third-party certification stream against the same controls. SOC 2 is the AICPA assurance report that some health technology vendors run alongside HIPAA. NIST CSF 2.0 is the outcome-oriented framework boards and senior leaders read against, with the Govern, Identify, Protect, Detect, Respond, and Recover functions. SP 800-66 is the integration layer; the framework crosswalk reads cleanly against all of the above through the SP 800-53 control mapping.

Recurring failure modes SP 800-66 implementations hit

Programmes that struggle with the SP 800-66 implementation typically hit a small set of recurring failure modes. Naming them upfront lets the programme design controls to avoid them rather than discovering them during the OCR audit protocol read or the HITECH investigation following a breach.

Treating SP 800-66 as a substitute for the Security Rule. SP 800-66 Rev. 2 is an implementation guide, not the regulation itself. The Security Rule (45 CFR Part 164 Subparts C and D) and the Breach Notification Rule (Subpart D) carry the legal obligations. Programmes that treat SP 800-66 as the source of truth and the Security Rule as the supporting reference invert the relationship; the regulation governs, the guide assists with implementation.

Skipping the risk assessment grounding. The guide expects the entire implementation to follow from the documented risk assessment per SP 800-30. Programmes that adopt SP 800-66 to fix a specific control gap without grounding the work on the documented risk assessment carry implementation decisions that cannot be defended against the cost, complexity, capability, and risk factors the addressable specification language requires.

Documenting addressable choices as binary in or out. The Security Rule expects three documented choices per addressable specification (implement as written, implement an alternative, or document why neither is reasonable and appropriate). Programmes that document a yes or no on each addressable specification lose the documented rationale OCR investigators routinely test.

Pairing the implementation with the wrong SP 800-53 baseline. SP 800-66 Rev. 2 maps the Security Rule to SP 800-53 control families but does not pick a baseline. The Moderate baseline is the typical starting point for ePHI; programmes that adopt the Low baseline without documenting the rationale, or skip baseline selection entirely, lose the audit defence the assessment expects.

Holding the documentation in a Word file outside the operating record. The Security Rule requires six-year documentation retention from creation or last effective date. Programmes that hold the risk assessment, the policy library, the safeguard implementation evidence, the workforce training records, and the activity logs in separate document repositories that do not reconcile with the operating record carry a documentation hierarchy that drifts from the implemented controls between audits.

Treating the continuing obligation as the next annual review. SP 800-66 expects monitoring and periodic review on a defined cadence and reassessment after every material change. Programmes that document the risk assessment once and go quiet until the next annual review carry stale evidence into the OCR enquiry, the HITECH audit, or the business associate due diligence read after an incident.

Underbuilding the business associate chain. The HITECH Act of 2009 and the 2013 Omnibus Rule made business associates directly liable for Security Rule compliance. Programmes that maintain the business associate agreement as a contractual artefact alone without verifying the safeguard implementation across the data flow carry liability the parent covered entity ultimately answers for.

Evidence the implementation expects

A defensible SP 800-66 implementation produces a stable evidence set across the five steps. The artefact set is the documentation the Security Rule expects to be retained for six years from creation or last effective date under 164.316(b)(2), and the same evidence the OCR Audit Protocol, the HITECH enquiry, and the parallel framework reads consume.

  • Documented Security Rule risk assessment with the asset inventory, threat catalogue, vulnerability list, current control posture, likelihood and impact rationale, risk determination, and risk treatment per the SP 800-30 Rev. 1 methodology
  • Documented decision rationale per addressable implementation specification (implement as written, implement an equivalent alternative, or document why neither is reasonable and appropriate)
  • Per-safeguard implementation evidence: configuration baselines, scan output, control attestations, policy references, training completion records, drill records, and walk-through evidence
  • Six-year document retention from creation or last effective date per 164.316(b)(2)(i) covering policies, procedures, risk assessments, incident records, training records, and the safeguard implementation evidence
  • Workforce training records per role with the per-individual completion record, the training content reference, and the cadence the covered entity adopted under 164.308(a)(5)
  • Incident records per the Security Incident Procedures (164.308(a)(6)) and the Breach Notification Rule (164.400 to 164.414) including the four-factor breach risk assessment, the notification timeline (HHS, affected individuals, media), and the rationale for any low-probability-of-compromise determination
  • Contingency plan testing records covering the disaster recovery plan, the emergency mode operation plan, and the backup restore validation, with the test date, the participants, the findings, and the plan revisions
  • Business associate agreement register with the BAA on file per business associate, the categories of ePHI accessed, the security attestations, and the subcontractor chain
  • Access review records per the access review cycle the covered entity adopted under 164.308(a)(4) covering the user inventory, the role assignments, the access grant rationale, and the access removal records
  • Audit log evidence per ePHI system covering the logging coverage matrix, the monitoring and review procedure, and the records of those reviews against a defined cadence per 164.312(b)
  • Vulnerability management evidence under RA-5 covering scan execution records, finding triage with severity calibration, remediation SLAs, exception register entries with rationale, retest evidence per remediated finding, and recurring detection identity
  • Configuration baseline evidence per ePHI system component with change control records, configuration deviation tracking, and configuration audit results under 164.312(c) integrity

How SP 800-66 reads across security functions

SP 800-66 is a cross-functional guide. The same Security Rule implementation reads differently depending on the function that holds the work. Programmes that run SP 800-66 as a GRC exercise alone lose the engineering depth the implementation expects; programmes that run it as an engineering exercise alone lose the governance depth. The named functions below own different parts of the same evidence set.

GRC and compliance teams

Run the SP 800-66 implementation on the same workspace the HIPAA Security Rule compliance evidence already lives on. Hold the risk assessment, the addressable-specification decision rationale, the per-safeguard implementation evidence, the workforce training records, the business associate register, and the incident records as compliance artefacts that consume cleanly across the OCR audit, the HITECH enquiry, the HITRUST assessment, and the customer security questionnaire.

CISOs and security leaders

Carry the HIPAA programme accountability at the operating layer. Track the per-ePHI-system risk assessment cadence, the safeguard implementation status per Administrative, Physical, and Technical Safeguard, the open finding aging against the remediation SLA, the workforce training completion rate, and the business associate due diligence status. Read SP 800-66 as the federal-grade implementation companion to the regulation rather than as an additional framework competing for attention.

Internal security teams and vulnerability management teams

Own the RA-5 vulnerability monitoring and SI-2 flaw remediation work at the operating layer. Run authenticated, external, and code scanning against the ePHI estate; calibrate finding severity against the SP 800-66 risk assessment; enforce the per-finding remediation SLA; document exception register entries against the addressable specification language; and pair every remediation with the retest evidence the OCR investigator reads against if the breach lands on the system later.

AppSec teams and security engineering teams

Own the SI-7 software integrity, SA-11 developer security testing, and CM-3 configuration change control evidence at the operating layer. Run code scanning against connected repositories, hold the secure-coding standard and the enforcement record, and pair each change to the ePHI processing tier with the assessment evidence so the Security Rule Implement step reads the live engineering posture rather than the version from the last audit.

Healthcare CISOs and covered entity privacy officers

Carry the cross-functional accountability the Security Rule, the Privacy Rule, and the Breach Notification Rule expect. Track the BAA register against every covered business associate, the data flow per ePHI system, the access reviews, the workforce training, the incident lifecycle from the four-factor breach risk assessment through the notification decision, and the rationale for any low-probability-of-compromise determination on one record so the OCR enquiry after an incident reads the operating posture rather than reconstructing it from disconnected tools.

Healthcare audit, compliance, and risk committees

Read SP 800-66 as the federal-grade implementation companion the audit committee can cite alongside the HITRUST certification, the SOC 2 examination, and the parallel framework reads. The SP 800-53 control map gives the committee a specific control vocabulary the executive can defend against the regulator enquiry, the breach litigation, and the cyber insurance underwriting read, rather than a high-level safeguard summary that does not survive the OCR audit protocol.

Running the SP 800-66 implementation on SecPortal

SecPortal carries the operating record the SP 800-66 implementation reads against: the engagement is the per-ePHI-system risk assessment cycle, the findings record carries the safeguard gaps and the vulnerability scan output, the documents area carries the risk assessment, the policy library, and the per-BAA register, and the activity log carries the audit trail every Security Rule documentation requirement reads against. The platform alignment below maps the verified product capabilities to the SP 800-66 steps and the SP 800-53 control families the Security Rule safeguards map to.

  • Engagement management as the workspace anchor for the SP 800-66 implementation programme, with the per-ePHI-system risk assessment cycle, the per-safeguard implementation evidence, the workforce training pack, and the annual reassessment cadence tracked as engagements that produce the artefact set as a side effect rather than as a parallel project
  • Findings management with CVSS 3.1 calibration and 300+ finding templates so the safeguard gaps identified during the risk assessment, the vulnerability scanning output, and the OCR-relevant findings all read the same severity vocabulary and the remediation SLA is enforceable per finding
  • Compliance tracking across 21 framework templates including the HIPAA Security Rule, NIST SP 800-53, NIST CSF 2.0, HITRUST, and the additional frameworks healthcare programmes typically read against, so the SP 800-66 mapping reads against the same record the parallel framework reads consume
  • Document management for the risk assessment, the per-safeguard policies and procedures, the business associate agreement register, the contingency plan, the incident response plan, the training materials, the audit log coverage matrix, and the OCR investigation evidence pack, so the six-year retention requirement under 164.316(b)(2) operates on the workspace rather than across a folder hierarchy that drifts
  • Authenticated scanning (17 modules) for the technical safeguards evidence including TLS posture for 164.312(e) transmission security, authentication posture for 164.312(d), session and access control posture for 164.312(a), and integrity posture for 164.312(c)
  • External scanning (16 modules) for the boundary and perimeter posture evidence including DNS, TLS, ports, headers, technology fingerprinting, subdomain enumeration, and CVE matching that the SP 800-53 SC-7 boundary protection control reads against
  • Code scanning via Semgrep against connected GitHub, GitLab, and Bitbucket repositories so the SI-2 flaw remediation evidence, the SA-11 developer security testing evidence, and the SI-7 software integrity evidence accumulate as scan execution records archived per ePHI system
  • Continuous monitoring on daily, weekly, biweekly, or monthly cadences so the periodic review obligation under SP 800-66 Section 5.5 reads against the operating posture rather than against a snapshot
  • Retesting workflows paired to the original finding so the remediation evidence carries the verify-after-fix record the OCR investigator and the HITECH auditor read against, and the recurring detection identity prevents the same gap from being closed without verification
  • Activity log with CSV export and timestamped state changes by user across finding, engagement, scan, document, comment, and team entity types, so the AU-2 event logging and AU-12 audit record generation evidence is reproducible from one source for the six-year retention window
  • Encrypted credential storage (AES-256-GCM) for the scanning credentials needed to read ePHI systems under authenticated scanning, so the credential lifecycle is held under the same access controls the Security Rule expects against the rest of ePHI access
  • Multi-factor authentication for workspace access so the IA-2(1) and IA-2(2) MFA evidence for privileged and non-privileged user access reads against the operating posture rather than against a policy statement alone
  • Team management with RBAC (owner, admin, member, viewer, billing) so the AC-2 account management, AC-5 separation of duties, AC-6 least privilege, and PS-2 position risk designation controls have the per-role evidence the Security Rule expects
  • AI report generation that produces the per-ePHI-system risk assessment narrative, the per-safeguard implementation summary, the leadership-readable continuous monitoring summary, and the OCR-ready investigation pack draft from the same engagement record, with the underlying findings, scans, and documents linked

Honest scope: what SP 800-66 implementation on SecPortal does not include

SecPortal carries the implementation record the Security Rule expects against the verified product capabilities. The platform does not provide HIPAA certification (the Security Rule does not certify; OCR investigates compliance against the regulation), does not act as a Business Associate by default (the workspace owner decides whether the SecPortal contract reaches BAA territory and signs the appropriate agreements), does not ship packaged Jira, ServiceNow, Slack, PagerDuty, Opsgenie, SIEM, or EHR connectors (the workspace bridges those flows through user actions and bulk import rather than through packaged integrations), does not provide SSO, SCIM, or SAML federation, does not provide a packaged Medical Device Inventory beyond the asset records the workspace owner creates, does not provide a packaged Privacy Rule de-identification engine, and does not determine the four-factor breach risk assessment on the covered entity's behalf (the covered entity makes the determination; SecPortal carries the record).

Related reading on SecPortal

Key control areas

SecPortal helps you track and manage compliance across these domains.

Step 1: Conduct a HIPAA Security Rule risk assessment

SP 800-66 Rev. 2 Section 5.1 grounds the implementation on the risk assessment requirement at 45 CFR 164.308(a)(1)(ii)(A). The guide recommends the methodology in NIST SP 800-30 Rev. 1: identify the ePHI in scope, characterise the system, identify threat sources and threat events, identify vulnerabilities and predisposing conditions, determine likelihood and impact, and determine the resulting risk. The risk assessment output drives every downstream implementation decision the guide describes.

Step 2: Identify and document reasonable and appropriate security measures

Section 5.2 covers the decision per Security Rule standard and implementation specification. Required specifications must be implemented as written. Addressable specifications give the covered entity a documented choice (implement as written, implement an equivalent alternative, or document why neither is reasonable and appropriate). The decision considers size, complexity, capabilities, technical infrastructure, security capabilities, costs, and the probability and criticality of risks to ePHI. The rationale is itself evidence; OCR investigators routinely test the documented reasoning.

Step 3: Implement the chosen security measures

Section 5.3 walks each Security Rule safeguard against the operating implementation. Administrative Safeguards include the security management process, assigned security responsibility, workforce security, information access management, security awareness and training, security incident procedures, contingency plan, evaluation, and business associate contracts. Physical Safeguards include facility access controls, workstation use, workstation security, and device and media controls. Technical Safeguards include access control, audit controls, integrity, person or entity authentication, and transmission security. Each safeguard maps to NIST SP 800-53 Rev. 5 control families.

Step 4: Document the security measures, rationale, and implementation

Section 5.4 reads against the documentation requirement at 45 CFR 164.316. The covered entity must maintain policies and procedures implemented to comply with the Security Rule, the actions and assessments required, and the documentation must be retained for six years from the date of creation or the date when last in effect, whichever is later. Documentation must be available to those responsible for implementing the procedures, reviewed periodically, and updated as needed in response to environmental or operational changes affecting the security of ePHI.

Step 5: Maintain continuous security assurance

Section 5.5 covers the continuing obligation. Risk assessment is not a one-off project; the Security Rule expects the covered entity to monitor and periodically review the security measures, conduct evaluations after material change, and at minimum annually. Vulnerability scanning, audit log review, access reviews, incident response testing, contingency plan testing, and security awareness reinforcement operate on a defined cadence the covered entity can evidence with timestamped artefacts.

Administrative Safeguards (164.308) to SP 800-53 control families

Security Management Process (164.308(a)(1)) maps to RA, PL, PM controls. Assigned Security Responsibility (164.308(a)(2)) maps to PM-2. Workforce Security (164.308(a)(3)) maps to PS controls. Information Access Management (164.308(a)(4)) maps to AC controls. Security Awareness and Training (164.308(a)(5)) maps to AT controls. Security Incident Procedures (164.308(a)(6)) maps to IR controls. Contingency Plan (164.308(a)(7)) maps to CP controls. Evaluation (164.308(a)(8)) maps to CA controls. Business Associate Contracts (164.308(b)) maps to SA controls.

Physical Safeguards (164.310) to SP 800-53 control families

Facility Access Controls (164.310(a)) maps to PE-2, PE-3, PE-6, PE-8. Workstation Use (164.310(b)) maps to SC and CM controls. Workstation Security (164.310(c)) maps to PE-5 and AC-11. Device and Media Controls (164.310(d)) maps to MP-2, MP-4, MP-5, MP-6, MP-7. The physical control evidence reads on the same operating record as the technical control evidence; the evidence pack should not separate them.

Technical Safeguards (164.312) to SP 800-53 control families

Access Control (164.312(a)) maps to AC-2, AC-3, AC-7, AC-11, AC-12, AC-17. Audit Controls (164.312(b)) maps to AU-2, AU-3, AU-6, AU-12. Integrity (164.312(c)) maps to SI-7. Person or Entity Authentication (164.312(d)) maps to IA-2, IA-5 with MFA enhancements widely treated as the reasonable and appropriate baseline. Transmission Security (164.312(e)) maps to SC-8, SC-12, SC-13.

Organisational Requirements (164.314) and Policies, Procedures, and Documentation (164.316)

Organisational Requirements cover business associate contracts (with the required clauses for processor obligations, breach notification, sub-processor authorisation, audit rights, and assistance with data subject requests) and group health plan requirements. Policies, Procedures, and Documentation require the covered entity to implement reasonable and appropriate policies and procedures, maintain documentation, retain documentation for six years from creation or last effective date, make documentation available to those responsible for implementing the procedures, and review and update periodically.

Audit evidence the implementation expects

A defensible SP 800-66 implementation produces: the documented risk assessment per SP 800-30, the decision rationale per addressable specification, per-safeguard implementation evidence including configuration baselines and scan output, six-year document retention covering policies and procedures, workforce training records per role, incident records per the Breach Notification Rule, contingency plan testing records, business associate agreement register, access review records, audit log evidence per ePHI system, vulnerability management evidence including remediation SLAs and retest evidence, and configuration baseline evidence with change control records.

How SP 800-66 sits next to HIPAA, HITECH, HITRUST, SOC 2, NIST CSF 2.0

HIPAA (the Privacy, Security, Breach Notification, and Enforcement Rules at 45 CFR Parts 160 and 164) is the federal regulation. HITECH amendments and the 2013 Omnibus Rule extend the regulation to business associates and increase enforcement. SP 800-66 Rev. 2 is the NIST implementation guide pairing the Security Rule with the SP 800-53 control catalogue. HITRUST CSF is the private-sector certifiable framework. SOC 2 is the AICPA assurance report some health technology vendors run alongside HIPAA. NIST CSF 2.0 is the outcome-oriented framework with Govern, Identify, Protect, Detect, Respond, and Recover functions. SP 800-66 is the integration layer.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Document management for every security engagement

Every action recorded across the workspace

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Monitor continuously catch regressions early

Verify fixes and track reopens on the same finding record

Multi-factor authentication on every workspace

Collaborate across your entire team

AI-powered reports in seconds, not days

Encrypted credential storage for authenticated scans

Run a defensible NIST SP 800-66 implementation on one operating record

Hold the HIPAA Security Rule risk assessment, the per-addressable-specification decision rationale, the per-safeguard implementation evidence, the workforce training pack, the BAA register, and the audit log on one workspace. Carry the same record into HITRUST, SOC 2, NIST CSF 2.0, and the OCR audit protocol without rebuilding the evidence pack. Start free.

Get Started Free

No credit card required. Free plan available forever.