HIPAA risk analysis template for small practices

Every Office for Civil Rights (OCR) settlement that cites a risk analysis failure includes the same finding: the practice either had no analysis, or the analysis they had was generic, outdated, or incomplete. The requirement sounds straightforward — 45 CFR § 164.308(a)(1)(ii)(A) mandates an "accurate and thorough assessment of the potential risks and vulnerabilities" to your electronic protected health information (ePHI). But the settlement documents reveal what those two words, "accurate" and "thorough," actually mean in enforcement.

Accurate means the analysis reflects your practice's specific environment — not a downloaded template with bracketed placeholders left unfilled. Thorough means complete scope: every system, every vendor, every transmission path that touches ePHI. Most free templates fail on both counts.

This article describes the structure a defensible risk analysis needs. The structure is knowable; filling it accurately for your specific environment is the work that satisfies OCR.

What the rule requires

The Security Rule has required risk analysis since 2005. The specific provision is at 45 CFR § 164.308(a)(1)(ii)(A):

Conduct 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.

Three standards from that sentence appear in nearly every OCR resolution agreement:

Accurate. The analysis must reflect what your practice actually uses. OCR has cited practices for risk analyses that named the wrong electronic health record (EHR), listed vendors no longer in use, or described network configurations that did not match reality. An accurate analysis is specific, not generic.

Thorough. Every system that creates, receives, maintains, or transmits ePHI must be included. The analysis that covers your cloud EHR but omits your email system (which your front desk uses to send appointment reminders) is not thorough. The analysis that names your primary EHR vendor but omits your IT provider with administrative access is not thorough.

Current. OCR treats analyses older than 12 months as presumptively stale. The proposed 2026 Security Rule would make annual review explicit. Either way, a dated analysis from 2019 does not satisfy a 2026 requirement.

HHS's 2010 guidance on risk analysis explicitly maps the requirement to National Institute of Standards and Technology (NIST) SP 800-30 Rev. 1 methodology. OCR investigators look for the NIST structure: scope definition, threat identification, vulnerability assessment, likelihood and impact estimation, and risk determination.

The structure of a defensible template

A template provides the skeleton. The work is filling it accurately for your environment. Here is the structure NIST 800-30 prescribes and OCR expects.

Section 1: Scope definition

Purpose: Define the boundaries of the analysis so an investigator can determine whether the scope was appropriate.

Template format:

• Organization: [FILL: Practice legal name, locations, number of employees]
• Responsible party: [FILL: Name and title of HIPAA Security Officer]
• Analysis date: [FILL: Completion date of this analysis]
• Review cycle: [FILL: Annual or as-triggered by specific events]
• Systems in scope: [FILL: List every system that touches ePHI — EHR, practice management, email, imaging, backup, telehealth]
• Locations in scope: [FILL: Primary office, satellite locations, remote workforce endpoints]
• Data types: [FILL: Patient demographics, clinical notes, billing information, insurance data, appointment schedules]

The scope section is where many analyses fail. Listing "the EHR" without naming the vendor and version is insufficient. Listing "email" without specifying the platform (Google Workspace, Microsoft 365, etc.) is insufficient. OCR expects specificity because it demonstrates the analysis was actually conducted, not copied.

Section 2: ePHI inventory

Purpose: Identify every place ePHI lives or moves within the scope.

Template format:

Asset ID	Asset Type	Description	Location	ePHI Types	Access Level
[ID-001]	[FILL]	[FILL]	[FILL]	[FILL]	[FILL]

Asset categories to inventory:

1. Information systems — EHR, practice management, patient portal, billing system
2. Infrastructure — Servers, network equipment, internet connection
3. Endpoints — Workstations, laptops, tablets, smartphones that access ePHI
4. Transmission paths — Email, file sharing, VPN, cloud backup, interfaces
5. Physical media — Backup drives, USB devices, printed records awaiting destruction
6. Third-party services — Business associates with ePHI access

The inventory must be current. An inventory that lists a former employee's laptop or a discontinued cloud service fails the accuracy test.

Section 3: Threat and vulnerability identification

Purpose: For each asset, identify what could go wrong and what would make it possible.

Template format:

Asset ID	Threat Category	Specific Threat	Vulnerability	Likelihood	Impact	Risk Level
[ID]	[Adversarial/Accidental/Environmental/Structural]	[FILL: e.g., Ransomware]	[FILL: e.g., Unpatched OS]	[High/Med/Low]	[High/Med/Low]	[Critical/High/Med/Low]

NIST threat categories to assess:

• Adversarial: Threats from individuals or groups intending harm (ransomware, phishing, insider misuse)
• Accidental: Unintentional actions by authorized users (misdirected email, lost device, configuration error)
• Environmental: Natural or facility-related events (fire, flood, power loss, hardware failure)
• Structural: Failures of organizational processes or system design (insufficient backup, lack of access review)

For each asset, identify at least one threat in each applicable category. OCR settlements cite practices that considered "cyber threats" generally but failed to name specific threats to their specific environment.

Section 4: Current controls assessment

Purpose: Document what protections are already in place for each threat-vulnerability pair.

Template format:

Asset/Threat	Existing Controls	Control Effectiveness	Gaps Identified
[FILL]	[FILL]	[Full/Partial/None]	[FILL]

Control categories (per 45 CFR Part 164, Subpart C):

• Administrative: Policies, procedures, training, access management
• Physical: Facility access, workstation security, device controls
• Technical: Access controls, audit controls, integrity controls, transmission security

Be accurate about effectiveness. Claiming "antivirus" as a control against ransomware is only accurate if the antivirus is current, monitored, and tested. OCR has cited practices for listing controls that were not actually implemented or verified.

Section 5: Risk register

Purpose: Synthesize findings into a prioritized list of risks requiring management.

Template format:

Risk ID	Description	Likelihood	Impact	Risk Level	Proposed Mitigation	Timeline	Responsible
R-001	[FILL: Specific description]	[H/M/L]	[H/M/L]	[Critical/High/Med/Low]	[FILL]	[FILL]	[FILL]

Risk level determination:

• Critical: High likelihood × High impact (address immediately)
• High: High/Medium combinations requiring prompt action
• Medium: Moderate risk with planned mitigation
• Low: Acceptable with existing controls

The risk register is the foundation of your Risk Management Plan under 45 CFR § 164.308(a)(1)(ii)(B). OCR expects to see the connection: every risk in the register maps to a specific mitigation in the plan.

Section 6: Methodology documentation

Purpose: Enable an investigator to understand how risk levels were determined and reproduce the analysis.

Template format:

• Methodology framework: NIST SP 800-30 Rev. 1
• Likelihood scale: [Define your scale — e.g., High = observed in organization/industry within past year; Medium = plausible but not observed; Low = theoretical only]
• Impact scale: [Define your scale — e.g., High = breach affecting >500 individuals or business disruption >24 hours; Medium = limited breach or disruption; Low = minimal effect]
• Data sources: [What informed your assessment — logs, interviews, vendor documentation, industry reports]
• Assumptions: [Any assumptions made due to information gaps]
• Limitations: [Scope exclusions, if any, and rationale]

OCR investigators read methodology sections. An analysis that cannot defend its own reasoning is treated as if it does not exist.

Why most free templates fail

Free templates circulating online typically fail on three counts:

Generic scope. They describe "a medical practice" rather than your specific practice. OCR's accuracy standard requires specificity.

Placeholder threats. They list "hacking" and "natural disasters" without requiring assessment of which specific threats apply to your specific environment.

Missing methodology. They provide checklists without explaining how to determine risk levels or document the reasoning. OCR expects to see the methodology, not just the conclusions.

From template to defensible analysis

A template is a starting point, not a finish line. To produce a defensible analysis from this structure, you need to:

1. Inventory accurately. Know every system, every vendor, every device that touches ePHI in your practice. Shadow IT — personal devices, shadow cloud storage — must be discovered and included.

2. Assess accurately. Rate likelihood and impact based on actual evidence, not wishful thinking. A threat you have observed in your industry is more likely than a theoretical one.

3. Document methodology. Explain how you arrived at each risk rating so an investigator can follow your reasoning.

4. Connect to action. The risk register must feed into a Risk Management Plan with specific mitigations, timelines, and responsible parties.

5. Date and sign. The analysis must carry a completion date and attribution to the responsible party.

This work typically takes 60–90 minutes for a small practice when conducted with structured guidance that ensures no steps are missed. The CoreFolio HIPAA assessment walks through each section of this template with practice-specific prompts, threat catalogs, and methodology guidance that produces the documentation structure OCR expects.

Sources