The Health Insurance Portability and Accountability Act (HIPAA) establishes standards for protecting health information. The HIPAA Security Rule establishes a standard to safeguard electronic protected health information (ePHI). Organizations may use any security measures to meet these standards. This blog assesses the degree to which CMMC addresses these requirements.
In the blog, we’ll cover:
The purpose of HIPAA Security Rule and relevant NIST Standards
Methodology for crosswalking CMMC and the HIPAA Security Rule
Results from the crosswalk
Hypothesis
NIST has provided a mapping of SP 800-53 controls to the HIPAA Security Rule. As a derivative of SP 800-53, SP 800-171 should address many of HIPAA’s confidentiality requirements. We expect to see gaps in integrity and availability.
Comparing Standards
HIPAA Security Rule
The purpose of the HIPAA Security Rule is to protect ePHI. Protection covers confidentiality, integrity, and availability. The HIPAA Security Rule includes administrative, technical, and physical safeguards. The rule includes standards and implementation specifications.
The Security Rule specifies some implementation specifications as required and others as addressable. Organizations may use alternative security measures to meet the purpose of addressable requirements. If addressable requirements and alternatives are not reasonable, organizations must document this choice. The Security Rule applies to covered entities and business associates.
Covered entity means:
A health plan
A health care clearinghouse
A health care provider who transmits information for which HHS has a standard.
Business associate includes:
A Health Information Organization, E-prescribing Gateway, or other person that:
transmits protected health information to a covered entity and
requires access on a routine basis to such protected health information.
A person that offers a personal health record to one or more individuals on behalf of a covered entity.
A subcontractor that creates, receives, maintains, or transmits protected health information.
The Department of Health and Human Services enforces penalties through the Office of Civil Rights (OCR). The 2021 HITECH Act amendment provided new guidance for enforcement. OCR must consider regulated entities’ implementation of recognized security practices when resolving violations. The HITECH amendment defines recognized security practices by identifying three categories:
Standards developed under Section 2(c)(15) of the NIST Act
This includes the NIST Cybersecurity Framework (CSF). The CSF includes informative references to ISO/IEC 27001 and NIST SP 800-53.
Approaches promulgated under section 405(d) of the Cybersecurity Act of 2015
This includes Healthcare Industry Cybersecurity Practices (HICP). The HICP includes technical volumes 1 and 2, depending on the size of the organization.
Other programs that address cybersecurity promulgated through regulations under other statutory authorities.
NIST SP 800-171 is another cybersecurity standard promulgated through regulations. The Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012 cites SP 800-171.
NIST SP 800-53
NIST SP 800-53 is a catalog of cybersecurity controls developed for Federal systems. The catalog includes 20 domains. There are three parts of the control catalog:
Contains the controls, control enhancements, and a corresponding discussion.
Contains the assessment objectives and methods for each control.
Tailors the controls into three baselines (low, moderate, and high).
Requirements for nonfederal organizations protecting US Government information stem from these baselines. NIST SP 800-171 tailors the moderate baseline to protect the confidentiality of information.
NIST SP 800-171
The purpose of NIST SP 800-171 is to protect controlled unclassified information (CUI). These requirements apply to the components of nonfederal systems. This includes any component that processes, stores, or transmits CUI. It also includes components that provide security protection for such components. There are two parts of the publication:
NIST SP 800-171:
Contains the security requirements and a corresponding discussion.
NIST SP 800-171A:
Contains the assessment objectives and methods for security requirements.
Cybersecurity Maturity Model Certification (CMMC)
CMMC implements third party assessment requirements for NIST SP 800-171. The CMMC Level 2 Assessment Guide combines both SP 800-171 and SP 800-171A into a single document.
Federal Acquisition Regulations (FAR) CUI Rule
Other federal agencies may add protection requirements of CUI within their supply chains. A proposed rule would promulgate new requirements to contractors handling CUI. Unlike CMMC, these requirements would apply to contractors for any Federal agency.
Methodology
NIST IR 8477 explains the basics of cybersecurity concept mapping. NIST proposes that crosswalk exercises should include the following steps:
Identify and document use cases for the mapping.
Choose a concept relationship style
Evaluate concept pairs and document their relationships.
Use Case for HIPAA and NIST SP 800-171 Mapping
How well does NIST SP 800-171 fulfill requirements from the HIPAA Security Rule?
Answering this question is relevant to compliance officers within the healthcare industry. Healthcare organizations may be both a covered entity and a contractor handling CUI. The National Archives and Records Administration (NARA) maintains the CUI Registry. Within the privacy index, several categories overlap with ePHI:
Choosing a Concept Relationship Style
We elected to use the Supportive Relationship Mapping. Our use case was to fulfill HIPAA requirements using SP 800-171. NIST IR 8477 categorizes four types of crosswalks:
Concept Crosswalk
A concept crosswalk indicates that a relationship exists between two concepts. The NIST Online Library of Information References (OLIR) contains many concept crosswalks. For example, NIST provides a concept crosswalk of the HIPAA Security Rule to SP 800-53 R5. This crosswalk does not characterize the type of relationship or its strength.
Image Source: NIST OLIR Mapping HIPAA Security to SP 800-53 R5
Structural Relationship Mapping
The structural relationship mapping style captures inherent hierarchical structures of concepts. Structural relationships are usually defined within a single source. Since the goal was to crosswalk concepts from two sources, this style was not considered.
Set Theory Mapping
Set Theory Mapping describes the nature of concept relationships. The Set Theory Mapping includes both a rationale and a relationship type. Rationales provide high-level context describing the relationship between two concepts:
Syntactic: How similar is the wording that expresses the two concepts? This is a word-for-word analysis of the relationship, not an interpretation.
Semantic: How similar are the meanings of the two concepts? This involves some interpretation of each concept’s language.
Functional: How similar are the results of executing the two concepts? This involves understanding the outcomes of the concepts.
Set theory relationship mapping styles support five relationship types:
Subset of: Concept A is a subset of concept B. In other words, concept B contains everything that concept A does and more.
Intersects with: Concept A and concept B have some overlap, but each includes content that the other does not.
Equal: Concept A is a superset of concept B. In other words, concept A contains everything that concept B does and more.
Superset of: Concept A is a superset of concept B. In other words, concept A contains everything that concept B does and more.
No relationship: Concept A is not related to concept B; their content does not overlap.
NIST IR 8278Ar1 provides guidance on identifying the strength of the relationship.
If the two elements have an “equal” relationship, assign a score of 10.
If the two elements have a “subset of,” “superset of,” or “intersects with” relationship, and
They are much more similar than they are dissimilar, assign a score of 7, 8, or 9.
They are roughly as similar as they are dissimilar, assign a score of 4, 5, or 6.
They are much more dissimilar than they are similar, assign a score of 1, 2, or 3.
We used this mapping type to compare elements from NIST SP 800-171Ar2 and NIST SP 800-53Ar5.
Image Source: NIST SP 800-171Ar2 Crosswalk to NIST SP 800-53Ar5
Supportive Relationship Mapping
Supportive relationship mapping indicates how a supporting concept helps achieve a supported concept. These mappings identify each relationship according to one of the following types:
Supports: Concept A supports concept B. Concept A may apply alone or in combination with one or more other concepts to achieve B in whole or in part.
Is supported by: Concept A has support from concept B. Concept B may apply alone or in combination with one or more other concepts to achieve A in whole or in part.
Identical: Concept A and concept B are identical. They use exactly the same wording.
Equivalent: Concept A and concept B are equal. They have the same meaning but different wording.
Contrary: Concept A and concept B each have one or more elements that contradict one or more elements of the other concept. The contradictions may be opposites but do not have to be.
Supportive relationships define if one concept is necessary to achieve the other. Practitioners assign one of the following relationship properties for supporting relationships:
Example of: The supporting concept C is one way (an example) of achieving the supported concept D in whole or in part. However, one can accomplish D without C.
Integral to: The supporting concept C is integral to and a component of the supported concept. One cannot accomplish D without C.
Precedes: Concept C is a prerequisite for concept D.
Only the supportive relationship could describe how SP 800-171 supports HIPAA requirements. As referenced above, both concepts have Mappings to NIST SP 800-53. We used SP 800-53 as the bridge to identify potential relationships between them.
Derived Relationship Mappings
NIST IR 8278 discusses the use of derived relationship mappings (DRMs). Mappings may not exist for a particular document pair. You may be able to glean some of the mappings by using the two Reference Documents and a single Focal Document.
Image Source: NIST IR 8278 Figure 2.
DRMs do not identify relationships between the reference documents. Rather they identify if two elements have potential relationships. The derived reference mapping function identified potential relationships between HIPAA and SP 800-171r2. SP 800-53r5 was the Focal Document for both reference documents.
Evaluating Concept Pairs and Documenting their Relationship
We used Microsoft Excel to combine the crosswalks. This gave us hundreds of potential relationships to consider. We trained Google Gemini on guidance from NIST IR 8477 supportive relationship mapping . Gemini helped us categorize the relationships between HIPAA and NIST SP 800-171A.
Image Source: HIPAA Security Rule CMMC Crosswalk
We identified whether integral or preceding concepts fulfilled HIPAA Security Rule requirements.
We included the Gemini comments providing a rationale for the Fulfilled by determination. Below are some highlights of the results.
Results
Required Standards
There are 19 required standards within the administrative, physical, and technical safeguards. The DRM indicates that SP 800-171 fulfills 13 of these 19 required standards.
Of the six required standards not fulfilled, one had integral concepts from SP 800-171. This was the one technical standard not fulfilled by SP 800-171.
164.312(c)
Integrity: Implement policies and procedures to protect ePHI from improper alteration or destruction.
Maps to SP 800-53: CP-9, MP-2, MP-5, SC-8, SI-1, SI-7
DRM mapping to SP 800-171Ar2: MP.L2-3.8.2(a.), MP.L2-3.8.5(a.), MP.L2-3.8.5(b.)
HIPAA requires policies and procedures to protect ePHI from improper alteration or destruction. SP 800-171 focuses on confidentiality and physical access control, not data integrity.
Other Required HIPAA Standards Not Fulfilled
The other required HIPAA standards were administrative safeguards. The DRM failed to identify any integral or preceding SP 800-171 concepts.
164.308(a)(1)(i) - Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.
Maps to SP 800-53: RA-1
SP 800-171r2 tailored policies and procedures out as nonfederal organization (NFO) controls. NIST expected organizations to meet these controls without specification. In revision 3, NIST made policy and procedure requirements explicit in 03.15.01.
164.308(a)(2) - Assigned Security Responsibility. Identify the official responsible for developing and implementing policies and procedures.
Maps to SP 800-53: CA-6, PM-2
SP 800-171 tailored Security Authorization (CA-6) out as a federal control (FED). SP 800-171r3 tailored PM-2 out as not applicable (N/A).
164.308(a)(7)(i) - Standard: Contingency plan. Establish policies and procedures for responding to emergencies that damage systems containing ePHI.
Maps to SP 800-53: CP-1, CP-2
SP 800-171 tailored CP-1 and CP-2 out as not related to the confidentiality of CUI.
164.308(b)(1) - Business Associate Contracts and Other Arrangements. A covered entity must receive safeguarding assurances from business associates handling ePHI.
Maps to SP 800-53: CA-3, PS-7, SA-9
SP 800-171r2 tailored CA-3, PS-7 and SA-9 out as NFO controls. Revision 3 makes CA-3 and SA-9 explicit in 03.12.05 and 03.16.03. Revision 3 categorizes PS-7 as not related to the confidentiality of CUI (NCO).
164.308(b)(2) - Business associate contracts and other arrangements. A business associate must receive safeguarding assurances from subcontractors handling ePHI.
SP 800-53 does not map to this HIPAA requirement.
Required Implementation Specifications
There are 14 required implementation specifications within the administrative, physical, and technical safeguards. The DRM identified SP 800-171 as fulfilling 6 of these 14 required implementation specifications.
Of the eight implementation specifications not fulfilled, three had integral concepts from SP 800-171. One technical standard not fulfilled by SP 800-171.
164.308(a)(1)(ii)(B)
Risk Management (R). Implement security measures to reduce risks and vulnerabilities to a reasonable level.
Maps to SP 800-53: PL-2, RA-2, RA-3
DRM mapping to SP 800-171Ar2: AT.L2-3.2.1(a.); CA.L2-3.12.4(a.); (c.); (d.); (e.); (f.); (g.); (h.); RA.L2-3.11.1(a.); (b.); RA.L2-3.11.3(b.)
HIPAA Risk Management is about the implementation of security measures to reduce risks. SP 800-171 lacks a holistic view of the entire risk management process required by HIPAA.
164.308(a)(7)(ii)(B)
Disaster Recovery Plan (R). Establish (and implement as needed) procedures to restore any loss of data.
Maps to SP 800-53: CP-2, CP-6, CP-7, CP-8, CP-9, CP-10
DRM mapping to SP 800-171Ar2: MP.L2-3.8.9(a.); IR.L2-3.6.1(f.)
HIPAA requires an organization to establish procedures to restore any loss of data. SP 800-171 only covers a small fraction of what's needed for a complete disaster recovery plan.
164.312(a)(2)(ii)
Emergency Access Procedure (R). Establish procedures for obtaining necessary electronic protected health information during an emergency.
Maps to SP 800-53: AC-2, AC-3, CP-2
DRM mapping to SP 800-171Ar2: AC.L1-3.1.1(a.); AC.L1-3.1.2(a.); AC.L1-3.1.2(b.)
HIPAA requires a specific procedure for obtaining necessary ePHI during an emergency. SP 800-171 only requires routine access control and does not address emergency circumstances.
Addressable Implementation Specifications
There are 22 addressable implementation specifications within the administrative, physical, and technical safeguards. The DRM indicates SP 800-171 fulfills 15 of these 22 required implementation specifications.
Of the 7 addressable implementation specifications, two had integral concepts from SP 800-171.
164.308(a)(5)(ii)(A)
Security Reminders (A). Periodic security updates.
Maps to SP 800-53: AT-2, AT-3
DRM mapping to SP 800-171Ar2: AT.L2-3.2.1(c.); AT.L2-3.2.2(c.)
HIPAA security reminders are about periodic updates ensuring ongoing security awareness. SP 800-171r2 does not cover this "periodic" aspect. Revision 3 incorporates ongoing literacy training requirements and role-based training.
164.310(a)(2)(iv)
Maintenance Records (A). Implement policies and procedures to document repairs and modifications to security-related physical components.
Maps to SP 800-53: MA-1, MA-2, MA-6
DRM mapping to SP 800-171Ar2: MA.L2-3.7.1(a.); MA.L2-3.7.2(b.); PE.L1-3.10.5(a.); (b.); (c.)
HIPAA requires documentation of repairs and modifications to physical security components. SP 800-171 does not include requirements for maintenance documentation.
Other Addressable Implementation Specifications Not Fulfilled
164.308(a)(7)(ii)(D) - Testing and Revision Procedure (A). Implement procedures for periodic testing and revision of contingency plans.
Maps to SP 800-53: CP-2, CP-3, CP-4
SP 800-171 tailored CP-2, CP-3 and CP-4 out as NCO controls.
164.308(a)(7)(ii)(E) - Applications and Data Criticality Analysis (A). Assess the criticality of applications and data in support of contingency plan components.
Maps to SP 800-53: CP-2, CP-2(8), RA-2, RA-2(1)
SP 800-171 tailored CP-2 and CP-2(8) out as NCO controls. SP 800-171 tailored RA-2 and RA-2(1) out as FED controls.
164.310(d)(2)(iv) - Data Backup and Storage (A). Create a retrievable exact copy of ePHI, when needed, before movement of equipment.
Maps to SP 800-53: CP-9, MP-4
SP 800-171 tailored CP-9 out as a NCO control. SP 800-171 incorporates MP-4 into 3.8.1. Without CP-9, MP-4 does not fulfill this HIPAA requirement.
164.312(c)(2) - Mechanism to Authenticate ePHI (A). Implement electronic mechanisms to verify ePHI integrity and protect against unauthorized destruction.
Maps to SP 800-53: SC-8, SI-7
SP 800-171 incorporates SC-8 into 3.13.8 but focuses on confidentiality. SP 800-171 tailored SI-7 out as a NCO control.
164.312(e)(2)(i) - Integrity Controls (A). Implement security measures to ensure the integrity of ePHI until disposed of.
Maps to SP 800-53: SC-8, SI-7
SP 800-171 incorporates SC-8 into 3.13.8 but focuses on confidentiality. SP 800-171 tailored SI-7 out as a NCO control.
Closing Gaps with SP 800-53 Controls
Required Controls
Organizations can supplement SP 800-171 with SP 800-53 controls to close these gaps. Below are the integral controls that fulfill the remaining HIPAA requirements:
CA-3 addresses 164.308(b)(1)
CA-6 addresses 164.308(a)(2)
CP-1 addresses 164.308(a)(7)(i) and 164.308(a)(7)(ii)(B)
CP-2 addresses 164.308(a)(7)(i), 164.308(a)(7)(ii)(B), and 164.312(a)(2)(ii)
CP-6 addresses 164.308(a)(7)(ii)(B)
CP-7 addresses 164.308(a)(7)(ii)(B)
CP-8 addresses 164.308(a)(7)(ii)(B)
CP-9 addresses 164.308(a)(7)(ii)(B) and 164.312(c) (objective d satisfied by 3.8.9)
CP-10 addresses 164.308(a)(7)(ii)(B)
PM-2 addresses 164.308(a)(2)
PS-7 addresses 164.308(b)(1)
RA-1 addresses 164.308(a)(1)(i)
SA-9 addresses 164.308(b)(1)
SC-8 addresses 164.312(e)(2)(i) (confidentiality addressed by 3.13.8)
SI-1 addresses 164.312(c)
SI-7 addresses 164.312(c)
Updating 3.12.4 to include PL-2(a)[12-13] addresses 164.308(a)(1)(ii)(B)
Addressable Controls
Implementing the required controls above will also help address addressable requirements:
CP-2 addresses 164.308(a)(7)(ii)(D) and 164.308(a)(7)(ii)(E)
CP-9 addresses 164.310(d)(2)(iv)
SC-8 addresses 164.312(c)(2) and 164.312(e)(2)(i)
SI-7 addresses 164.312(c)(2) and 164.312(e)(2)(i)
To fulfill the remaining addressable requirements, consider adding the following controls:
CP-2(8) addresses 164.308(a)(7)(ii)(E)
CP-3 addresses 164.308(a)(7)(ii)(D)
CP-4 addresses 164.308(a)(7)(ii)(D)
MA-1 addresses 164.310(a)(2)(iv)
MA-6 addresses 164.310(a)(2)(iv)
RA-2 addresses 164.308(a)(7)(ii)(E)
RA-2(1) addresses 164.308(a)(7)(ii)(E)
Updating 3.2.1 to include AT-2(a)[1] addresses 164.308(a)(5)(ii)(A)
Updating 3.2.2 to include AT-3(a)[1] addresses 164.308(a)(5)(ii)(A)
Updating 3.7.1 to include MA-2(a) addresses 164.310(a)(2)(iv)
Conclusion
NIST SP 800-171 falls short of fulfilling the HIPAA Security Rule. The tailoring for confidentiality leaves gaps around integrity and availability.
Tailoring out NFO controls also created gaps around requirements made explicit within HIPAA. Organizations tasked with meeting these requirements should add controls from NIST SP 800-53.
The crosswalk resource describes the supportive relationships between these concepts. If you're looking to take your GRC program beyond excel, take a look at K2GRC.
