HICP 405(d) for HIPAA programs: what it adds and what it doesn't

How does HICP 405(d) fit into a HIPAA Security Rule program?

A customer, payer or board member asks whether your HIPAA program uses HICP, and wants to know if that means you are compliant. The short answer: the *Health Industry Cybersecurity Practices* publication is a voluntary HHS 405(d) resource that covers five threats and ten cybersecurity practices. It is not a certification and it is not a legal safe harbor. HICP itself states that its use is neither required by nor a guarantee of compliance with federal, state or local law, and HHS does not certify organizations against it. The question to answer internally is therefore not "are we HICP certified?" but "which HICP practices do we use to meet Security Rule requirements, and where is the evidence?"

Responsibility stays with your organization. You own the controls, the risk analysis and the decisions about which HICP practices fit your environment. An implementation partner can configure systems, collect logs, draft procedures and assemble the evidence that shows each practice operating. Only an independent auditor, assessor or certification body issues a report or certificate, and no HICP practice or HHS publication changes that. Ask any provider who says otherwise to put the claim in writing and to name the assessor who would sign it.

Practical steps follow from this. Map each HICP practice to the Security Rule standards it supports, and record which practices your risk analysis has ruled in or out, with reasons. Confirm the volume that fits your size: HICP Technical Volume 1 is written for small organizations and Volume 2 for medium and large ones, and small organizations with a managed service provider may hand that provider the main document and Volume 1. Then check the current edition and HHS performance goals directly on the HHS 405(d) site before citing them, since the guidance is updated over time and your customers will compare your wording with the published text.

Which HICP volume fits your organization size

HICP Technical Volume 1 is written for small healthcare organizations, such as independent practices and small clinics that run a limited number of systems and have few or no dedicated security staff. It translates the ten cybersecurity practices into simpler actions that a small team, or an outside IT provider, can carry out without a large security program. Most small organizations will use Volume 1 as the working guide and the main HICP document as the reference for the reasoning behind each practice.

Scope of the guide: Volume 1 focuses on the practices a small environment can realistically implement, such as email protection, endpoint protection, access management and backups.
Companion reading: Use the main HICP document alongside Volume 1 so the threat context for each practice is clear.
Tailoring step: The practices are recommendations to tailor after a risk assessment, so the guide does not replace your own analysis of where ePHI lives.
Staff time: The guide assumes limited in-house capacity, so record who owns each action and who approves changes.
Documentation: Keep written decisions for each practice you adopt, deferred or declined, since these support your HIPAA policies and documentation.

Before relying on this volume, confirm the current edition and volume number on the HHS 405(d) site.

Is HICP a recognized security practice under HITECH section 13412?

HICP can count as a recognized security practice, but only in the way HITECH section 13412 allows. Public Law 116-321 defines recognized security practices as standards and practices developed under section 2(c)(15) of the NIST Act, approaches promulgated under section 405(d) of the Cybersecurity Act of 2015, and other cybersecurity programs recognized by statute or regulation. HICP comes from the HHS 405(d) Program under that second category, so it falls within the definition. The statute does not list HICP by name as a required control set, and HICP itself states that it is neither required by nor a guarantee of compliance with federal, state or local law. Read the publication as a source of practices you may adopt, not a checklist that earns recognition by itself. The statute leaves the choice of practices to the entity. Under the provision, the covered entity or business associate determines which recognized security practices it has in place, consistent with the Security Rule. That means the work starts with your own risk analysis: identify which of the five threats HICP addresses (social engineering, ransomware, loss or theft of equipment or data, insider data loss, and attacks on network-connected medical devices) apply to your ePHI, then decide which of the ten practices, and which volume, match your size and environment. Document that reasoning, because it is the evidence an investigator will ask to see.

Recognition changes how OCR weighs your practices, not whether the Security Rule applies. The Security Rule's safeguards remain fully in force, and a recognized practice does not excuse a missing required implementation specification or an unaddressed risk. Where practices are in place and documented, OCR may consider them when it sets penalties or resolves audits and investigations. Confirm the exact weighting rules, the look-back period and what OCR expects as proof in the sibling topic on recognized security practices under the 2021 HITECH amendment, which covers those points in detail. Before relying on HICP in an OCR matter, ask your counsel or compliance lead to confirm how your documented practices map to your Security Rule risk analysis and risk management plan.

How HHS performance goals relate to HICP

HHS publishes voluntary healthcare Cybersecurity Performance Goals aligned with HICP and CISA to help organizations decide what to do first. The cards below show how a HIPAA program can use those goals to sequence HICP work and what evidence each goal should leave behind.

Start from the goals, not the full list

HICP describes ten practices across two technical volumes, which can read as an undifferentiated backlog. The performance goals act as a filter that picks the high-impact items to fund and staff first. Before you schedule work, confirm which goals HHS currently publishes and map each one to the HICP practice it draws on. Record that mapping in your HIPAA risk management plan so the sequencing decision is traceable to your own risk analysis.

Use the goals to set order

Sequence work by risk and dependency. Access management and asset inventory usually come before network segmentation or medical device controls, because you cannot protect or monitor systems you have not listed. Ask each team lead for a dated plan that names the goal being addressed, the owner, and the system scope. Treat the order as a decision you can explain to an OCR investigator, not as a fixed rule that HHS sets.

Evidence for access goals

Access-related goals need evidence that accounts are issued, changed and removed on documented triggers. Gather the current user list for each ePHI system, a sample of joiner, mover and leaver tickets, and privileged account reviews with dates and reviewers. Pair these with the access control and person or entity authentication safeguards in 45 CFR 164.312, so one set of records supports both the goal and the Security Rule requirement.

Evidence for asset and network goals

Asset and network goals depend on a current inventory of hardware, software, and network connections that touch ePHI. Keep an exported inventory with owners, data classifications and last-review dates, plus network diagrams that show segmentation between clinical systems and general IT. Ask whether medical devices appear in the inventory and whether vendor-maintained devices are covered by your monitoring. Missing devices are the most common gap auditors find when they test this area.

Evidence for response and recovery goals

Incident and vulnerability goals need proof that the process runs, not just that it is written. Retain patch reports with dates and exceptions, scan results with remediation tickets, and at least one tabletop exercise record showing who decided, who communicated and what was restored. Confirm that these records feed the breach risk assessment process, which depends on dates and scope that you can reconstruct from logs.

Governance ties the goals together

Governance goals ask that someone with authority own the cybersecurity program and report on it. Evidence includes a named security official, board or executive reporting minutes, an approved budget line for each priority, and a review cycle for the goals themselves. Confirm these records meet the Security Rule documentation expectations in 45 CFR 164.316, including retention and availability, since they are what an assessor will read first when testing whether your priorities are real.

How to map HICP practices to your HIPAA risk analysis

This sequence turns the HICP practices from a general reference into a documented set of decisions tied to the ePHI you actually hold and the threats you actually face. The output is a traceable record that links each risk to a practice, an owner and a rationale.

Confirm the risk analysis and ePHI inventory
Start from your current HIPAA risk analysis and the inventory of systems, devices, applications and vendors that create, receive, maintain or transmit electronic protected health information. The privacy or security lead confirms that every ePHI location is listed and that the risks already identified are current. The step is done when you can point to a dated risk analysis and an inventory that someone outside the project has reviewed. Gaps found here go into the gap log rather than being fixed silently.
Select the HICP volume for your organization
Choose the HICP technical volume that matches your size and complexity. Volume 1 addresses small healthcare organizations, and Volume 2 addresses medium and large ones. If a managed service provider runs your environment, confirm with that provider which volume and main document it will work from, since HICP suggests small organizations with an MSP hand over the main document and Volume 1. The output is a written selection, signed by the security official, with the reason for it recorded.
Link each practice to the threats it addresses
Work through the ten HICP practices and, for each one, identify which of the five threats it reduces: social engineering, ransomware, loss or theft of equipment or data, insider data loss, and attacks on network-connected medical devices. Record the link using the ePHI locations from step one, so an email protection practice is tied to the mail systems that carry PHI, not left as a general statement. Illustrative example: a practice on endpoint protection may map to ransomware risk on workstations that open clinical documents. The output is a practice-to-threat matrix for your environment.
Assess current state and record gaps
For each practice and mapped threat, compare what your environment does today with what the HICP text describes. Record the current control, the evidence that shows it operates, and the gap where evidence is missing or the control is absent. Involve the people who run each system, because documentation often describes intended controls rather than operating ones. The output is a gap register in which every entry names the risk it relates to and the system affected.
Record tailoring and risk decisions
HICP presents its practices as recommendations to tailor after a risk assessment, not as a mandatory control list. For each gap, decide whether to implement the practice, implement an alternative, accept the risk with a stated reason, or transfer it through a contract or vendor arrangement. Record the decision, the reasoning and any compensating measure in the risk management plan. Confirm with counsel or your compliance lead that the decision is consistent with your obligations under the Security Rule, because HICP does not itself establish compliance. The output is a signed set of tailoring decisions.
Assign owners and remediation tracking
Give every gap and every implemented practice a named owner, a status and a place in the remediation plan. Owners should be people with authority over the system concerned, and the security official should hold the consolidated view. Where a service provider or business associate does part of the work, record that dependency and the contract terms that govern it. The output is an owned remediation register that can be reviewed at each risk analysis update.
Document the rationale and review cycle
Assemble the mapping, gap register, tailoring decisions and owners into one document set, and state the rationale for each choice in plain language. Set the review trigger, such as a material change to systems, a security incident or the next scheduled risk analysis update. Keep the documentation available to the people who must act on it. The step is complete when an independent reviewer can follow a single HICP practice from threat to evidence to owner without asking the author.

What must be in place before you cite HICP to a customer or regulator

HICP is a set of voluntary practices, not a certification, so citing it only helps if the surrounding HIPAA program is already in order. The cards below cover the artifacts and checks that should exist first, and each one explains how to confirm it before you make the claim.

A current HIPAA risk analysis

HICP tells you to tailor its practices after a risk assessment, so the risk analysis is the foundation for every practice you claim. Confirm that it covers every location where electronic protected health information lives, including cloud accounts, backups, laptops, medical devices and vendor-hosted systems. Check the date of the last review and whether it records the threats HICP names, such as ransomware and social engineering. An analysis that predates a major system change is not current, and an assessor will ask about that gap first.

Written policies under 164.316

Section 164.316 requires written policies and procedures for Security Rule requirements, and the documentation must be kept current and retained. Each HICP practice you cite should map to a policy or procedure that someone can read and follow. Check that each document names its owner, has a review date, and reflects how systems actually run today. A policy that describes a tool you no longer use is weaker evidence than no policy, because it shows the program is not maintained.

Named owners for each practice

Each of the ten HICP practices needs a named person who is accountable for running it, not just a team mailbox. Ownership should cover email protection, endpoint protection, access management, data protection, asset management, network management, vulnerability management, security operations, medical device security and governance. Confirm that each owner knows the practice exists, has the authority to fund or change it, and is listed in the security oversight records. Gaps often appear in medical device security and asset management, where clinical and IT teams each assume the other is responsible.

Evidence that practices actually run

A practice claim without operating records will not hold up under questioning. Collect dated outputs such as backup restore test logs, patch compliance reports, access review sign-offs, phishing simulation results and vulnerability scan summaries. Check that the evidence covers a sustained period rather than a single day, and that someone reviewed and acted on the exceptions. Ask whether each record can be produced quickly and whether it would survive a request for the underlying system logs.

A documented tailoring rationale

HICP states its practices are recommendations to tailor after a risk assessment, not a mandatory control list. For every practice you do not implement fully, or implement differently from the HICP volume your size points to, write down why and what you did instead. Check that the rationale links back to a specific risk from your analysis and has been approved by the security official. A rationale that says only that a control is too expensive will not satisfy an assessor, because it does not show that a reasonable alternative was considered.

Who owns HICP adoption, and who can help

This table compares the three parties involved in adopting HICP inside a HIPAA program: the covered entity or business associate, an implementation partner, and an independent assessor. Read each row as a question about who decides, who does the technical work, and who signs off on the result. The main takeaway is that HICP adoption is never certified, and only an independent party can issue a report about it.

Question	Covered entity or business associate	Implementation partner (such as DeployOpen)	Independent auditor or assessor
Who owns the HICP practices?	Owns the decision to adopt each practice and the tailoring that follows the risk assessment	Advises on how practices map to systems, but does not set the organization's risk appetite	Tests the practices against the organization's documented decisions; does not choose them
Who performs the risk analysis?	Performs and signs the HIPAA risk analysis and decides which HICP recommendations apply	Can prepare asset inventories and technical inputs for the analysis on request	Reviews the analysis for completeness and consistency with observed systems
Who configures systems?	Accountable for every system holding ePHI, including vendor-hosted ones	Configures and hardens self-hosted open-source platforms in the client's infrastructure under a written scope	Samples configurations and logs to test whether they match the stated controls
Who produces the evidence?	Retains policies, logs, tickets, training records and decision records	Prepares evidence packs, runbooks and configuration exports as agreed in the scope	Reviews evidence and records what was observed and what was not
Who issues reports or certificates?	Cannot issue a HICP certificate; may share internal summaries with customers	Does not issue audit reports, attestations or certifications	Only the independent party issues a report, and only for the scope it tested
What does a fixed scope cover?	Sets the boundary of systems, sites and people included in the program	Agrees deliverables, timelines and exclusions in writing before work begins	Tests the boundary it is given; a narrower scope yields a narrower conclusion
Is HICP adoption certified?	No. HICP is voluntary and is not a certification or a guarantee of compliance	No. Implementation support does not change this	No. A third-party review can describe observed practices but is not a HICP certificate

Common ways HICP adoption stalls or misleads

HICP is a practical, voluntary set of practices, and most stalled programs fail in predictable ways: they treat it as a certificate, skip the risk analysis, adopt everything at once, or cannot show the controls work. Each card below names one pitfall and the check that keeps your program honest.

Treating HICP as a compliance checklist

HICP states that its use is neither required by nor a guarantee of compliance with federal, state or local law, and HHS states that no Security Rule standard requires certification. A program that ticks all ten practices and calls itself HIPAA compliant has skipped the legal test. Check that your HIPAA documentation maps each Security Rule requirement to an owner, a control and evidence, with HICP cited as a recognized practice source rather than the proof itself.

Skipping the risk analysis

HICP's practices are recommendations to tailor after a risk assessment, so the risk assessment comes first. Adopting practices without knowing where ePHI lives, which threats apply and how likely each is leaves you guessing which practices matter most. Ask who owns the analysis, when it was last updated after a significant change, and whether it names the five threats HICP addresses: social engineering, ransomware, loss or theft of equipment or data, insider data loss, and attacks on network-connected medical devices.

Adopting every practice without tailoring

Volume 1 targets small organizations and Volume 2 targets medium and large ones, so a clinic that reads the larger volume will face controls it cannot staff or operate. Wholesale adoption also buries the high-impact items under low-value work. Build a short list from your risk analysis, assign each practice a scope and owner, and record which practices you deliberately defer and why. Recording the reasons is what makes a deferral defensible.

Lacking evidence of operation

Having a policy for email protection or access management does not show the control runs. Auditors and OCR investigators ask for records: access reviews with dates and reviewers, patch and scan reports, backup restore tests, and incident tabletop notes. Set a recurring evidence calendar for each practice, keep logs for the period you must defend, and test restores rather than assuming backups work. Gaps in operating evidence are the most common reason a documented practice fails in review.

Assuming a managed service provider owns decisions

HICP suggests that small organizations with a managed service provider hand it the main document and Volume 1, but delegation of tasks is not delegation of accountability. The covered entity or business associate still owns its risk decisions, its risk acceptances and its HIPAA obligations. Before signing, confirm in writing which HICP practices the provider operates, which evidence it delivers and how often, and who approves exceptions. Keep a named internal owner who can answer for every practice.

Using HICP without a current threat baseline

HICP is a published set of practices, and threats change faster than publications are revised. A program that treats the 2023 Edition as the final word may miss newer attack patterns affecting its own systems, including new medical device exposures or vendor integrations. Schedule a review of the threat list against your environment and the latest HHS 405(d) materials, and document what changed in your risk analysis and practice selection each time you review.

Questions buyers ask about HICP and HIPAA

Is HICP required under HIPAA?

No. HICP is a voluntary publication from the HHS 405(d) Program, and HICP itself states that its use is neither required by nor a guarantee of compliance with federal, state or local laws. The HIPAA Security Rule in 45 CFR Part 164 Subpart C is the binding obligation. HICP helps an organization decide which practices to adopt against the threats it faces, and the organization still has to run its own risk analysis and document how it addresses each Security Rule requirement. Confirm with your counsel which state laws apply to your organization, since HICP does not map to them.

Does using HICP count as a recognized security practice?

HICP is one of the source types the HITECH amendment names as a potential recognized security practice. Under Public Law 116-321, section 13412, an entity determines which recognized practices it has in place, consistent with the Security Rule, and HHS considers them when it assesses penalties or audit outcomes. Using HICP alone does not settle the question. The organization should document which practices it implemented, how it chose them after a risk assessment, and how they were kept in operation. Treat the recognition as something you evidence, not something the publication grants.

Which HICP volume should a healthcare organization use?

HICP splits its technical guidance by size. Technical Volume 1 is written for small healthcare organizations, and Technical Volume 2 is written for medium and large ones. The main document applies to all sizes. HICP recommends that small organizations with a managed service provider give the provider the main document and Volume 1 so the provider can plan the work. Choose the volume that matches your operational footprint, not your revenue alone, and confirm with your managed service provider which volume it will use to scope its controls.

Do we need a consultant to adopt HICP?

Not necessarily. An internal team with security and clinical systems knowledge can work through the main document and the relevant technical volume, provided it has time and someone who can make decisions on risk. A consultant or implementation partner is most useful when the internal team lacks experience with network segmentation, endpoint tooling, identity systems or medical device networks, or when it needs an outside view of the risk analysis. Any outside party prepares systems, controls and evidence. Only the organization owns its controls, and only an independent assessor issues an assessment report.

How much internal staff effort does HICP adoption need?

The effort depends on how many of the ten practices already exist, how many systems hold ePHI, and how much of the environment is managed by third parties. The main drivers are the size of the asset inventory, the number of clinical and medical devices on the network, the state of identity and access management, and whether backups and incident response plans have been tested. Work usually involves a clinical or operational owner, an IT lead, a security lead and an executive sponsor. Ask any partner to show the work breakdown in the written scope before you agree a timeline, and confirm the estimate against your own asset inventory.

Does an outside HICP or HIPAA assessment prove compliance?

No. HIPAA has no certification, and HHS does not endorse or recognize private certifications. A third-party assessment can test specific controls and produce findings, but it cannot establish that an organization is compliant with the Security Rule, and it does not prevent OCR from later finding a violation. HICP adoption carries the same limit. What an assessment can give you is evidence that defined controls were tested at a point in time against a stated scope. Ask any assessor to state its scope, method and limits in writing, and treat its report as one input into your own compliance record.

Who is responsible if we adopt HICP through a vendor?

The covered entity or business associate remains responsible for its own HIPAA compliance. A vendor that prepares systems or evidence does not take over that responsibility. Write the division of duties into the contract: which party owns each control, who maintains the evidence, how changes are approved and who receives incident notices. Where a vendor handles ePHI on your behalf, a business associate agreement must also be in place. Any implementation partner, including DeployOpen, works within the scope agreed in writing and does not issue audit reports or certifications.

How DeployOpen maps HICP practices to your HIPAA environment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the HICP practices you adopt show up in working systems and written evidence. We start from your risk analysis and the practices you select, then hand over what your team and your assessor need to review.

How we scope

We confirm which HICP volume fits your organization size and which of the ten practices your risk analysis puts in scope.
We map each in-scope practice to the systems, data flows and owners in your environment, including any managed service provider role.
Every engagement is fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We implement or harden the self-hosted platforms behind practices such as access management, endpoint protection and network management in your cloud or data center.
We configure logging, backup and vulnerability management workflows so that they produce records you can show during a review.
We run security testing against the configured systems and record the findings and remediation steps for your review.

How we hand over

We document configurations, procedures and responsibilities so your staff can operate and explain each practice after handover.
We prepare evidence packages that map each practice to the artifacts that support it, for your own compliance review.
We state clearly that your organization owns its HIPAA program, and that HICP use does not by itself guarantee compliance.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
Retainers can cover updates to platforms and evidence as your risk analysis changes or the HIPAA Security Rule is revised.
Your independent auditor or assessor remains the only party that issues reports or attestations about your compliance.