HHS 405(d) HICP | Health Industry Cybersecurity Practices, 2023 Edition
How Identity and Access Management Supports the HHS 405(d) Health Industry Cybersecurity Practices
The HHS 405(d) Health Industry Cybersecurity Practices (HICP), 2023 Edition, is a publication of the HHS 405(d) Program and the Health Sector Coordinating Council 405(d) Task Group that recommends ten cybersecurity practices. This page lists all ten 405(d) HICP practices by their official titles. It marks the one where identity and access management is typically the principal means of implementation, the four where identity contributes, and the five that sit outside identity scope (GCA classification).
Under HITECH Act section 13412, added by Pub. L. 116-321, HHS is to consider whether a covered entity or business associate adequately demonstrated that recognized security practices were in place for not less than the previous 12 months when making certain HIPAA determinations. Recognized security practices include approaches promulgated under section 405(d) of the Cybersecurity Act of 2015.
For CIOs and compliance leaders
- Identity and Access Management (HICP-P03) is the one practice where identity is typically the principal means of implementation.
- Identity also contributes to Email Protection Systems, by enforcing multifactor authentication for email access, and to Data Protection and Loss Prevention, Security Operations Center & Incident Response, and Cybersecurity Oversight and Governance, where identity data feeds work owned by other teams.
- Under HITECH section 13412, HHS is to consider whether recognized security practices were in place for not less than the previous 12 months when making certain HIPAA determinations.
Reference material, not a compliance determination. This matrix reflects GCA's practice view as of . It does not certify, warrant or predict the outcome of any assessment, audit or examination. The HHS 405(d) HICP publication controls. Read the full notice.
The matrix
- Primary
- Supporting
- Outside identity scope (GCA classification)
Showing 10 of 10 requirements
| Requirement | Requirement description (GCA summary) | HITECH section 13412 recognized security practice | Identity relevance (GCA classification) | GCA approach | Platform families that commonly provide relevant capabilities | Evidence commonly examined |
|---|---|---|---|---|---|---|
| HICP-P03 practices: HICP cybersecurity practices | Identity and Access Management GCA description: practice area covering how users and systems are identified, authenticated, provisioned, reviewed and deprovisioned for access to health information systems. In practice: Each person has one verified identity, signs in with MFA, receives access by role, and managers periodically review who can reach clinical systems. |
|
Primary
Why this classificationThe practice area for identity lifecycle, authentication and access governance. Identity and access management is typically the principal means of implementing it. GCA classifies at the practice level and names a sub-practice only where it decides the class. |
Authoritative identity records, multi-factor and phishing-resistant authentication, role-based provisioning, privileged access controls and periodic access review commonly contribute to this practice area. |
Platform families that commonly provide relevant capabilities
|
Evidence commonly examined
|
| HICP-P01 practices: HICP cybersecurity practices | Email Protection Systems GCA description: practice area covering controls on email systems as a delivery path for phishing and malware. In practice: Messaging and security teams own email filtering and phishing education; identity requires MFA to sign in to email and blocks older mail protocols that cannot take a second factor. |
|
Supporting
Why this classificationEmail protection is mostly filtering, encryption and awareness work owned by messaging and security teams. One sub-practice, multifactor authentication for email access, is an identity control, so identity and access management contributes to it by enforcing MFA and by restricting legacy protocols that cannot take a second factor. The education and phishing-simulation sub-practices are outside identity scope. |
Enforcing multi-factor authentication for email access and restricting legacy authentication protocols through access policy commonly contribute to this practice. |
Platform families that commonly provide relevant capabilities
|
Evidence commonly examined
|
| HICP-P04 practices: HICP cybersecurity practices | Data Protection and Loss Prevention GCA description: practice area covering classification, protection and monitoring of health information to reduce loss and exposure. In practice: Data owners decide where sensitive data lives; identity limits who can reach those repositories by role and has managers review that list periodically. |
|
Supporting
Why this classificationData classification, encryption and loss prevention tooling. Primary ownership usually sits with data security. Access rights to data repositories are an identity contribution. |
Role-based access to data repositories and periodic review of who can reach sensitive data commonly contribute to data protection. |
Platform families that commonly provide relevant capabilities
|
Evidence commonly examined
|
| HICP-P08 practices: HICP cybersecurity practices | Security Operations Center & Incident Response GCA description: practice area covering monitoring, detection and handling of security events and incidents. In practice: The security operations team watches for threats; identity supplies sign-in logs, privileged activity records and alerts about risky accounts. |
|
Supporting
Why this classificationMonitoring and incident handling. Primary ownership usually sits with security operations. Identity signals are one input. |
Identity provider sign-in logs, privileged activity records and identity threat detection commonly feed monitoring and incident response. |
Platform families that commonly provide relevant capabilities
|
Evidence commonly examined
|
| HICP-P10 practices: HICP cybersecurity practices | Cybersecurity Oversight and Governance GCA description: practice area covering leadership accountability, policy and measurement of the security program. In practice: Leadership sets security policy and tracks progress; identity adds figures such as review completion, MFA coverage and privileged account counts to that reporting. |
|
Supporting
Why this classificationProgram governance. Primary ownership usually sits with executive and security leadership. Identity metrics and access review reporting are inputs. |
Access review completion, MFA coverage and privileged account metrics commonly serve as identity inputs to security program reporting. |
Platform families that commonly provide relevant capabilities
|
Evidence commonly examined
|
| HICP-P02 practices: HICP cybersecurity practices | Endpoint Protection Systems GCA description: practice area covering protection of workstations, servers and mobile devices that access health information. |
|
Outside identity scope (GCA classification)
Why this classificationIn GCA's classification, endpoint security tooling and configuration usually sit with endpoint security; no identity contribution is typical. Device trust signals used in access policy are a related identity topic. |
Not applicable | Not applicable | Not applicable |
| HICP-P05 practices: HICP cybersecurity practices | IT Asset Management GCA description: practice area covering inventory and lifecycle control of hardware, software and data assets. |
|
Outside identity scope (GCA classification)
Why this classificationAsset inventory and lifecycle. Primary ownership usually sits with IT operations. Service account and device identity inventories are related identity topics. |
Not applicable | Not applicable | Not applicable |
| HICP-P06 practices: HICP cybersecurity practices | Network Management GCA description: practice area covering network architecture, segmentation and traffic controls. |
|
Outside identity scope (GCA classification)
Why this classificationNetwork design and controls. Primary ownership usually sits with network engineering. |
Not applicable | Not applicable | Not applicable |
| HICP-P07 practices: HICP cybersecurity practices | Vulnerability Management GCA description: practice area covering discovery and remediation of weaknesses in systems and software. |
|
Outside identity scope (GCA classification)
Why this classificationScanning and patching. Primary ownership usually sits with security operations and IT. Identity configuration weaknesses can be assessed separately. |
Not applicable | Not applicable | Not applicable |
| HICP-P09 practices: HICP cybersecurity practices | Network Connected Medical Device Security GCA description: practice area covering security of medical devices that connect to networks. |
|
Outside identity scope (GCA classification)
Why this classificationMedical device security. Primary ownership usually sits with clinical engineering and security. Device credentials and service identities are a related topic. |
Not applicable | Not applicable | Not applicable |
No requirements match the current filters.
Summary
- Primary
- 1
- Identity platforms or processes are typically the principal means of implementing the requirement.
- Supporting
- 4
- Another discipline owns the requirement. Identity configuration or evidence contributes.
- Outside identity scope (GCA classification)
- 5
- Listed for completeness, with a one-line note on what the requirement is.
How to read the matrix
- HITECH section 13412 recognized security practice
- Under HITECH Act section 13412 as added by Pub. L. 116-321, recognized security practices include approaches promulgated under section 405(d) of the Cybersecurity Act of 2015. HHS is to consider whether a covered entity or business associate adequately demonstrated that such practices were in place for not less than the previous 12 months when making certain HIPAA determinations. The section does not limit HHS's authority to enforce the HIPAA Security Rule. True marks a practice that is part of HICP; the statute attaches to the 405(d) approach as a whole.
- Identity relevance
Identity relevance is a GCA classification of whether identity capabilities are typically the principal means of implementing a requirement (Primary), contribute to a requirement owned by another discipline (Supporting), or usually sit outside identity work (Outside identity scope (GCA classification)).
It describes where primary implementation ownership usually sits. It is not a statement about whether identity configuration could be relevant to a particular incident, finding or environment. Every "Outside identity scope (GCA classification)" classification carries a rationale, and other classifications show one where GCA has recorded it, under "Why this classification" beside the label.
- Platform families
- Product families that commonly provide capabilities relevant to a requirement. A blank cell means GCA has not mapped a platform family to the requirement. It does not mean a product lacks a capability.
- Evidence
- Examples of artifacts commonly examined. The list is not complete, and it is not a statement that any artifact is sufficient. Assessors determine sufficiency.
Sources
- Health Industry Cybersecurity Practices (HICP) 2023 Edition, HHS Cyber Gateway U.S. Department of Health and Human Services
- HHS 405(d) Program U.S. Department of Health and Human Services, Administration for Strategic Preparedness and Response
- Public Law 116-321 (H.R. 7898), enacted January 5, 2021, adding HITECH Act section 13412 (42 U.S.C. 17941), Recognition of Security Practices U.S. Congress, via the U.S. Government Publishing Office
Important notice
Purpose. This HHS 405(d) HICP identity traceability matrix is general educational reference material, written by Robert Ivey and published by GCA Technology Services ("GCA") to help organizations plan identity and access management work. It is not legal, audit, accounting or compliance advice, and it is not a substitute for advice from qualified professionals who know your environment.
No compliance determination. Whether an organization meets a requirement is decided by the applicable assessor, auditor, certifying body or regulator, applying the governing requirements to that organization's actual systems, policies and evidence. Nothing in this matrix states or implies that any organization, product, service or configuration meets or complies with any requirement, or that any assessment, audit, examination or certification will have any particular outcome.
Classifications are practice opinion. Relevance classifications, offering mappings, platform mappings and evidence examples are the author's professional judgment as of the date shown. They are not regulatory classifications and are not statements of the standard of care. Other qualified practitioners may reasonably classify requirements differently, and the right answer for a given environment depends on its facts.
Evidence examples are illustrative. Evidence listed is an example of artifacts commonly examined. It is not a complete list, and it is not a statement that any artifact is sufficient. Assessors determine sufficiency.
Source text controls. Requirement text and references come from the sources listed on this page. Where this matrix differs from a source, the source controls. Regulations, guidance and assessment methods change, so confirm current requirements with the issuing authority before relying on them.
Products and services. Platform names identify product families that commonly provide capabilities relevant to a requirement. A blank cell means GCA has not mapped that platform family to the requirement. It does not mean the product lacks a capability. GCA makes no representation about any third party's products, features, roadmaps or government authorization status, including FedRAMP, DoD Impact Levels and similar programs. Confirm capabilities with the vendor and authorization status with the authorizing program.
GCA services. Offering descriptions identify the type of GCA service that addresses an area. The scope, deliverables, terms and outcomes of any GCA engagement are defined only by a signed agreement and Statement of Work, and this page does not change those terms.
No relationship; no reliance. Reading or using this matrix does not create a client, advisory or other relationship with GCA or the author. To the fullest extent permitted by law, this material is provided "as is," without warranties of any kind, express or implied, including accuracy, completeness, merchantability and fitness for a particular purpose, and GCA is not liable for any decision made or action taken in reliance on it.
No client data. This matrix contains no client data. Any example organization is fictitious.
Version 1 · Prepared · Last reviewed · Reviewed every 90 days · View changelog
© 2026 Quasius Investment Corp. d/b/a GCA Technology Services. The selection, arrangement, classifications and annotations in this matrix are GCA's original work. You may use this matrix within your organization for planning and may quote short portions with attribution to GCA and a link to this page. Republishing the matrix in whole or in substantial part requires GCA's written permission. Only the official practice titles from HHS 405(d) Health Industry Cybersecurity Practices are used, for reference. Row identifiers such as HICP-P03 are GCA labels that follow the order of the ten practices. All descriptions on this page are GCA's own and are not the publisher's text. HHS 405(d) Health Industry Cybersecurity Practices is published by the HHS 405(d) Program with the Health Sector Coordinating Council. Each publisher retains whatever rights it holds in the publication, and neither endorses this page.
Microsoft and Microsoft Entra are trademarks of the Microsoft group of companies. SailPoint, IdentityIQ and Identity Security Cloud are trademarks or product names of SailPoint Technologies, Inc. or its affiliates. Netwrix is a trademark of Netwrix Corporation. Okta is a trademark of Okta, Inc. Ping Identity is a trademark of Ping Identity Corporation. CyberArk is a trademark of Palo Alto Networks, Inc. or its affiliates. BeyondTrust is a trademark of BeyondTrust Corporation. Delinea is a trademark of Delinea Inc. HICP is a publication of the Health Sector Coordinating Council and the U.S. Department of Health and Human Services, neither of which endorses this page. All other trademarks belong to their respective owners. These names identify products and programs only and do not imply endorsement by, sponsorship by or affiliation with any of these companies or programs, except where a GCA partnership is expressly stated elsewhere on gca.net.
Changelog
- Version 1: First publication.
Frequently Asked Questions
Which HICP practice is the primary identity practice?
Identity and Access Management (HICP-P03) is the one practice where identity is typically the principal means of implementation in this matrix. Identity also contributes to four others: Email Protection Systems, Data Protection and Loss Prevention, Security Operations Center & Incident Response, and Cybersecurity Oversight and Governance (GCA classification).
What does HITECH section 13412 ask HHS to consider?
HHS is to consider whether a covered entity or business associate adequately demonstrated that recognized security practices were in place for not less than the previous 12 months when making certain HIPAA determinations. Recognized security practices include approaches promulgated under section 405(d) of the Cybersecurity Act of 2015.
Why does this page use titles and GCA descriptions instead of HICP text?
This page uses the official practice titles and GCA-written descriptions. It does not quote the publication.
How does HICP relate to the HIPAA Security Rule?
HICP-P03 is recorded as related to HIPAA standards 164.308(a)(3)(i), 164.308(a)(4)(i), 164.312(a)(1) and 164.312(d). The relationship is GCA judgment, not a regulatory crosswalk.