How HIPAA consultants run risk analyses across multiple client practices

A fractional HIPAA compliance consultant, a virtual Chief Information Security Officer (vCISO) serving healthcare clients, or a managed-service provider with a healthcare practice book faces a challenge that a single-practice compliance lead does not: the same structured compliance work must be done accurately, efficiently, and client-specifically for each engagement — and the documentation has to hold up if any one of those clients comes under OCR scrutiny.

This article describes the compliance framework consultants work within, the structure of a typical client engagement, and the documentation burden they are managing across a multi-client practice. It is written for compliance professionals who already understand Health Insurance Portability and Accountability Act (HIPAA) broadly and want a clear-eyed account of the core deliverables, their regulatory anchors, and what makes them defensible.

The compliance framework: what the rule requires

Every covered entity and business associate under HIPAA must produce two linked documents under 45 CFR § 164.308(a)(1) — the risk analysis and the risk management plan. These are the primary deliverables of a HIPAA consulting engagement with a covered entity.

The risk analysis (45 CFR § 164.308(a)(1)(ii)(A)) requires:¹

An accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.

OCR's 2010 final guidance on this provision identifies eight required elements:²

1. Scope — identify the ePHI the covered entity creates, receives, maintains, or transmits
2. Threat identification — identify reasonably anticipated threats to that ePHI
3. Vulnerability identification — identify potential vulnerabilities to confidentiality, integrity, and availability
4. Current controls — assess the security measures currently in place
5. Likelihood determination — document the probability that each threat will exploit each vulnerability
6. Impact analysis — document the potential impact of a threat occurrence
7. Risk level assignment — assign a risk level to each threat-vulnerability combination
8. Final documentation — document the findings and risk levels in the assessment

The risk management plan (45 CFR § 164.308(a)(1)(ii)(B)) requires implementing security measures to reduce risks and vulnerabilities to a "reasonable and appropriate level." In practice, this means a prioritized action plan that maps each identified risk to a remediation step, a responsible party, and a timeline for implementation.³

Both documents must be dated. OCR's consistent position is that a risk analysis older than twelve months is presumptively stale; the proposed 2026 Security Rule update — still in NPRM status as of June 2026 — would make annual cadence the explicit regulatory floor.⁴

Why this is the center of gravity in enforcement

Every enforcement action under OCR's Risk Analysis Initiative — 16 settlements between October 2024 and early 2026, totaling more than $2 million in penalties — traced back to a covered entity that could not produce a current, defensible risk analysis when OCR investigated.⁵ The Initiative has targeted small and mid-size practices and business associates deliberately; it is designed to apply consistent pressure on the segment historically underenforced.

In January 2026, OCR Director Paula M. Stannard confirmed the Initiative would continue and expand to also target risk management failures — practices must now demonstrate not only that they conducted a risk analysis but that they have taken action to reduce identified risks.⁶

For consultants: the practices you serve are the practices this enforcement pattern targets.

Structuring an engagement

A well-structured engagement has four phases that produce defensible documentation at each step.

Phase 1: intake and scope definition

The risk analysis cannot be generic. The scope must reflect the specific practice's actual electronic systems — named EHR vendor, named billing platform, named email provider, named cloud backup, every portable device policy, every vendor with electronic protected health information (ePHI) access. This is the phase where the analysis becomes practice-specific rather than templated.

Core intake work:

• Map every system that creates, receives, maintains, or transmits ePHI
• Identify all vendors with ePHI access; confirm business associate agreement (BAA) status for each
• Confirm who holds the Privacy Official and Security Official designations; document if undocumented
• Review any prior risk analysis; note its date and what has changed since

The deliverable from intake is a scoped asset inventory — a named list of every ePHI system and transmission pathway the analysis will cover. This is the foundation; if it misses a system, the analysis misses the risks that system carries.

Phase 2: the risk assessment itself

Working through the eight elements from OCR's guidance, threat by threat, vulnerability by vulnerability, using a documented methodology. The standard OCR points to is NIST SP 800-30 — its structured format for identifying threats, vulnerabilities, likelihood, impact, and risk level is defensible because OCR itself cites it.⁷

The format matters as much as the substance. OCR investigators have described reviewing risk analyses that describe the practice's security situation in narrative paragraphs but do not assign specific risk levels to specific threat-vulnerability pairs. That format fails the "documented methodology" requirement even if the underlying thinking was sound — there is no way for a reviewer to verify how any risk level was determined.

A structured risk register — each row a threat-vulnerability pair, each row carrying a likelihood rating, an impact rating, a derived risk level, and a current-control note — is the format that holds up under review.

Phase 3: the risk management plan

The risk analysis identifies what is exposed. The risk management plan documents what the practice will do about it, in priority order, with responsible parties and timelines.

For a small practice with limited IT resources, a realistic risk management plan is not a 90-day sprint to implement every security control in the NIST framework. It is a prioritized list: the highest-risk items addressed first, each with a concrete action (not "improve encryption" but "enable full-disk encryption on all workstations by [date]"), a named responsible party, and a target completion date.

The risk management plan is the document that demonstrates the analysis was not a compliance exercise but a genuine starting point for remediation. OCR now explicitly evaluates this under the expanded Risk Analysis Initiative.⁶

Phase 4: the supporting documentation package

The risk analysis and risk management plan sit at the center of a documentation package that a comprehensive engagement should produce or confirm:

Document	Regulatory anchor	Note
Privacy Official designation (written)	§ 164.530(a)(1)(i)	Dated, signed; names individual
Security Official designation (written)	§ 164.308(a)(2)	Dated, signed; names individual
Risk Analysis Report	§ 164.308(a)(1)(ii)(A)	Scoped, structured, dated, methodology documented
Risk Management Plan	§ 164.308(a)(1)(ii)(B)	Prioritized, action-specific, timelined
BAA inventory with executed agreements	§ 164.308(b)(1)	Current; covers every ePHI vendor
Written privacy and security policies	§§ 164.530(i), 164.308–164.316	Reflect actual practice
Training documentation	§ 164.530(b)(2)(ii)	Dated; names participants; describes content
Notice of Privacy Practices	§ 164.520	Posted; provided at first service; current
Breach log	§ 164.414	Documents incidents and four-factor analysis

This is not an exhaustive policy library — it is the minimum documentation set. Practices with significant gaps in any row need a remediation plan that addresses the gap explicitly, not just a note that the gap exists.

The multi-client documentation challenge

Serving ten to twenty practices means managing ten to twenty documentation packages, each practice-specific, each requiring annual updates, each potentially subject to OCR review at any time.

The challenges that create risk in a multi-client practice:

Templating that produces generic output. A risk analysis that names the specific EHR, the specific email provider, and the specific backup vendor is defensible. A risk analysis that says "EHR system" and "cloud backup" without naming them is not. The temptation to templatize for efficiency is real; the risk is that the resulting analysis looks to an investigator like a form someone filled in, not an accurate analysis of this practice's environment.

Annual update discipline. Risk analyses age. A client whose initial engagement was completed in 2023 and has not been updated since has a stale analysis that OCR would treat as presumptively non-compliant. The engagement model must include a defined annual update cadence, not just an initial production.

BAA currency. Healthcare practices add vendors regularly — a new telehealth platform, a changed billing service, a new IT support provider. If the BAA inventory is only audited at the annual engagement review, the list will routinely contain gaps. The engagement model should include a standing process for the client to notify the consultant when new vendors are added.

Officer designation maintenance. Office managers turn over. Practice owners change their minds about who should hold the role. If the designated Privacy or Security Official leaves the practice and no replacement designation is documented, the practice has an open compliance gap. A multi-client consultant needs a process to surface these changes, not just assume continuity.

What tools support this work

The consultant tool landscape ranges from general-purpose documentation environments (Word, Excel, SharePoint) to purpose-built HIPAA compliance platforms designed for multi-client environments.

The practical requirements for any tool used in this work:

• Practice-specific output. The risk analysis the tool produces must name the specific systems the practice uses, not generic system categories.
• Dated documentation. Every output must carry a creation date and, ideally, a methodology reference.
• NIST-aligned risk register format. The threat-vulnerability-likelihood-impact-risk-level structure that OCR expects.
• Version history. Annual updates should produce new dated documents, not overwrite the prior year's analysis (which must be retained for six years under § 164.530(j)(2)).

Platforms that produce structured, dated, NIST-aligned reports in formats OCR investigators recognize reduce the per-client production time and the risk of documentation gaps relative to building from blank templates. CoreFolio HIPAA's guided assessment produces the Risk Analysis Report and Risk Management Plan as downloadable PDFs — the specific artifacts a consultant hands the client — from a one-pass assessment that can be conducted with the practice or reviewed by the consultant after the client completes it.

What remains the consultant's judgment, not the tool's

No software produces a defensible risk analysis without human judgment applied at the key steps.

Scope verification. A tool cannot know that the practice manager uses her personal phone to schedule appointments through the EHR portal, creating a BYOD (bring your own device) exposure that the system inventory does not capture. That is discovered through intake — through a conversation with the people who actually use the systems. The consultant's role in intake is irreplaceable.

Risk level calibration. Likelihood and impact ratings are not purely algorithmic. A threat that is high-likelihood at a large hospital system is low-likelihood at a two-provider dental practice. A consultant who has worked with similar practices calibrates these ratings in ways that reflect the actual environment, not just a default template.

Risk management planning. Identifying a risk is the analysis. Determining which remediation action is realistic, affordable, and appropriate for this practice's specific situation is a judgment call. That judgment — which risks to address first, what "reasonable and appropriate" looks like for a practice of this size and complexity — is where consultant expertise delivers the most concrete value.

The tool produces the document. The consultant makes it accurate.

Sources

---

Sources current as of June 2, 2026. This article is educational and does not constitute legal advice.

Footnotes

1. 45 CFR § 164.308(a)(1)(ii)(A). Full text via the Legal Information Institute, Cornell Law School: https://www.law.cornell.edu/cfr/text/45/164.308. Last verified June 2, 2026. ↩

2. U.S. Department of Health and Human Services, Office for Civil Rights, Guidance on Risk Analysis Requirements under the HIPAA Security Rule (July 14, 2010). Identifies eight required elements of a HIPAA-compliant risk analysis. https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html ↩

3. 45 CFR § 164.308(a)(1)(ii)(B). Requires implementation of "security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." ↩

4. Notice of Proposed Rulemaking, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 90 Fed. Reg. 898 (Jan. 6, 2025). Comment period closed March 7, 2025. Not finalized as of June 2, 2026. The proposed text would make annual risk-analysis cadence an explicit regulatory requirement. ↩

5. U.S. Department of Health and Human Services, Office for Civil Rights. Resolution agreements under the Risk Analysis Initiative, October 2024–June 2026. https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/ ↩

6. HIPAA Journal, OCR's Risk Analysis Initiative to Continue in 2026 with Expanded Focus (January 2026). Reports OCR Director Paula M. Stannard's confirmation that the Initiative continues and will expand to include risk management failures. https://www.hipaajournal.com/ ↩ ↩²

7. National Institute of Standards and Technology, Guide for Conducting Risk Assessments, NIST Special Publication 800-30, Revision 1 (September 2012). https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final ↩