The risk analysis in 45 CFR 164.308(a)(1)(ii)(A) is the HIPAA Security Rule requirement covered entities and business associates most often fail, usually because what they hold is a questionnaire of yes and no answers rather than an assessment of risk to each place electronic protected health information (ePHI) lives. The rule requires "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of the ePHI an organisation holds, and the HHS Office for Civil Rights (OCR) runs a Risk Analysis Initiative that focuses investigations on exactly this provision. This template performs the analysis: nine numbered sections that take [Organisation] from scope and ePHI inventory through threat and vulnerability pairs, likelihood and impact scoring, risk levels and a risk management plan, following the nine elements in HHS guidance. It is for HIPAA security officials, compliance leads and IT teams at providers, health plans, clearinghouses and business associates. What the Security Rule requires overall is explained in the HIPAA Security Rule Guide; this page is the worksheet.
How to use this template
- Replace text in square brackets, such as [Organisation], [Security official], [Privacy officer] and [Approver], with your own names. Keep the completed analysis as a dated, version-controlled document.
- Work in order. Scope (section 1) and the ePHI inventory (section 3) decide what the rest covers; a risk analysis that leaves out a system holding ePHI is not "accurate and thorough", however well the rest is scored.
- Score every threat and vulnerability pair against every asset group in section 6, not once for the organisation as a whole. HHS describes risk as the combination of the likelihood that a threat exploits a vulnerability and the resulting impact.
- The Security Rule does not prescribe a method or format. The scales below follow NIST SP 800-30, which HHS guidance draws on. You may use a different scale if you apply it consistently and document it.
- Small and medium providers can use the free HHS and ONC Security Risk Assessment (SRA) Tool (version 3.7 at the time of writing) instead of, or alongside, this worksheet. HHS states the tool may not suit larger organisations and that using it does not by itself guarantee compliance.
- Regulatory text was checked on 8 November 2026. A proposed update to the Security Rule was issued as a notice of proposed rulemaking on 27 December 2024; HHS states the current rule remains in effect while that rulemaking is under way. See the HHS HIPAA Security Rule Update (2025 NPRM) Guide.
1. Purpose and scope
1.1 This risk analysis meets 45 CFR 164.308(a)(1)(ii)(A) for [Organisation], acting as a [covered entity / business associate / hybrid entity].
1.2 Scope covers all ePHI that [Organisation] creates, receives, maintains or transmits, in any electronic medium, at all locations, including: [sites], remote and home working, cloud and SaaS services, medical devices, backups and archives, and systems run by business associates on [Organisation]'s behalf.
1.3 Exclusions, if any, are listed with a reason: [none / list]. Paper records are out of scope of the Security Rule but are covered by [Privacy Rule process].
1.4 Assessment period: [start date] to [end date]. Previous analysis: [date, version].
2. Roles and approval
| Role | Name | Responsibility |
|---|---|---|
| [Security official] (164.308(a)(2)) | [Name] | Owns the analysis and the risk management plan |
| Asset and system owners | [Names] | Confirm inventory, current controls and impact ratings for their systems |
| IT and security | [Names] | Provide vulnerability scan results, configuration evidence, logs |
| [Privacy officer] | [Name] | Confirms ePHI types, data flows and business associate relationships |
| [Approver] (senior leadership) | [Name] | Approves risk levels, the treatment plan and acceptance of residual risk |
3. ePHI inventory and data flows
3.1 List every system, service, device class and data flow that holds or moves ePHI. Group similar assets (for example "clinical workstations, 140") but never merge assets with different controls.
| Asset ID | Asset or flow | ePHI type and volume | Location and hosting | Owner | Accessed by (people and non-human identities) | Business associate |
|---|---|---|---|---|---|---|
| A-01 | [Electronic health record] | [Full clinical records, ~120,000 patients] | [Vendor-hosted SaaS] | [Name] | [Clinicians via SSO; interface engine service account; billing API key] | [Vendor, BAA dated ...] |
| A-02 | [Email and file sharing] | [Referral letters, results] | [Cloud tenant] | [Name] | [All staff] | [Provider, BAA dated ...] |
| A-03 | [Backups] | [Full copies] | [Location] | [Name] | [Backup service account] | [...] |
3.2 Include service accounts, API keys, interface engine credentials and remote access accounts in the "accessed by" column. Attackers often reach ePHI through these rather than through a clinician's login. See the Healthcare Identity Security Guide.
3.3 Attach or reference a data flow diagram showing how ePHI enters, moves within and leaves [Organisation].
4. Threats and vulnerabilities
4.1 For each asset group, record reasonably anticipated threats (natural, human intentional, human accidental, environmental) and the vulnerabilities each could exploit. Use the starter catalogue and add your own from incident history, scan results and sector threat intelligence.
| Threat | Example vulnerabilities to test for | Evidence source |
|---|---|---|
| Ransomware via remote access | Remote access portal without MFA; unpatched VPN appliance; flat network | External attack surface scan, MFA enrolment report |
| Credential phishing | No phishing-resistant MFA; email authentication not enforced | Identity provider report, DMARC record |
| Misconfigured cloud storage or server | Public buckets or indexable web servers holding ePHI | Cloud posture scan |
| Leaked or stale machine credentials | API keys in code, service accounts with no owner, no rotation | Secrets scan, service account inventory |
| Insider misuse | No access reviews; no audit log review (164.308(a)(1)(ii)(D)) | Access review records, log review tickets |
| Lost or stolen device | Unencrypted laptops or removable media | Endpoint management encryption report |
| Business associate compromise | No BAA; no security assessment of the vendor | BAA register, vendor assessments |
| Power, flood or hardware failure | Untested backups; no contingency plan (164.308(a)(7)) | Restore test results |
5. Current security measures
5.1 For each pair, record the safeguards already in place and whether they are configured and used as intended, citing evidence (screenshot, report, policy, ticket). Note where a Security Rule implementation specification is addressable: under 164.306(d) you either implement it or document why it is not reasonable and appropriate and implement an equivalent alternative where reasonable.
5.2 Test, do not assume. "MFA is on" must be backed by an enrolment report showing who is not covered, including remote access, administrators and vendors.
6. Likelihood, impact and risk level
6.1 Likelihood scale (probability that the threat exploits the vulnerability in the next 12 months, given current measures):
| Score | Likelihood | Guide |
|---|---|---|
| 1 | Very low | No known occurrence in sector; strong, tested controls |
| 2 | Low | Possible but unlikely; controls in place with minor gaps |
| 3 | Moderate | Has occurred in the sector; controls partial |
| 4 | High | Common attack path in the sector; controls weak or untested |
| 5 | Very high | Already occurred here or actively targeted; no effective control |
6.2 Impact scale (harm to confidentiality, integrity or availability of ePHI, patients and operations): 1 Very low (no ePHI exposed, no disruption); 2 Low (few records, under one hour of disruption); 3 Moderate (hundreds of records or a day of disruption to a non-clinical service); 4 High (thousands of records, reportable breach, disruption to clinical care); 5 Very high (large-scale breach, patient safety affected, multi-day outage). Adjust thresholds to [Organisation]'s size and record them.
6.3 Risk score = likelihood x impact. Risk levels: 1 to 4 Low, 5 to 9 Medium, 10 to 16 High, 20 to 25 Critical.
6.4 Scoring worksheet (one row per asset, threat and vulnerability):
| Ref | Asset | Threat / vulnerability | Current measures | L | I | Score and level | Owner |
|---|---|---|---|---|---|---|---|
| R-01 | A-01 EHR | Ransomware / remote access portal without MFA for 12 vendor accounts | MFA for staff only; EDR on servers | 4 | 5 | 20 Critical | [Name] |
| R-02 | A-01 EHR | Leaked credential / interface engine service account password unchanged since 2019 | Vaulted for admins only | 3 | 4 | 12 High | [Name] |
| R-03 | A-03 Backups | Ransomware / backups reachable from domain admin | Daily backups, no immutable copy | 3 | 5 | 15 High | [Name] |
The Change Healthcare attack in 2024 began with stolen credentials on a remote access portal that did not require MFA, which is why remote access deserves its own row for every vendor and staff population. See the Change Healthcare breach analysis.
7. Risk management plan
7.1 For every Medium, High and Critical risk, record the response (mitigate, transfer, avoid, accept), the security measures to implement, owner, due date and target residual score. This plan meets 164.308(a)(1)(ii)(B): measures "sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level".
7.2 Deadlines by level: Critical [30 days], High [90 days], Medium [180 days], Low [review at next analysis]. Choose measures using the 164.306(b)(2) factors: size, complexity and capabilities; technical infrastructure; cost; and the probability and criticality of the risk.
7.3 Accepted risks are signed by [Approver] with a reason and review date. Cost alone is a factor, not a justification for leaving a Critical risk open.
7.4 Track the plan in the Risk Register Template or an equivalent register.
8. Documentation and retention
8.1 Retain this analysis, the risk management plan and supporting evidence for 6 years from creation or the date last in effect, whichever is later (164.316(b)(2)(i)).
8.2 Make the documentation available to those responsible for implementing the measures (164.316(b)(2)(ii)).
9. Review and update
9.1 Review this analysis at least [annually] and when triggered by: a security incident, a new system or service holding ePHI, a merger or change of ownership, significant staff changes, or new threats. This supports the periodic evaluation required by 164.308(a)(8).
9.2 Record the review date, what changed and the next scheduled review: [table].
Implementation guidance
HHS elements to template sections. HHS guidance lists nine elements a risk analysis should include. Use this table to show an auditor or OCR investigator where each is met.
| HHS element | Template section | Evidence to keep |
|---|---|---|
| Scope of the analysis | 1 | Signed scope statement |
| Data collection | 3 | ePHI inventory and data flow diagram |
| Identify and document threats and vulnerabilities | 4 | Threat catalogue, scan reports |
| Assess current security measures | 5 | Configuration evidence per control |
| Determine likelihood of threat occurrence | 6.1, 6.4 | Scored worksheet |
| Determine potential impact | 6.2, 6.4 | Scored worksheet |
| Determine the level of risk | 6.3, 6.4 | Risk levels and corrective actions |
| Finalise documentation | 8 | Approved, dated document |
| Periodic review and updates | 9 | Review log |
Steps for a first analysis:
- Weeks 1 to 2: agree scope, roles and scales (sections 1, 2 and 6.1 to 6.3) with [Approver].
- Weeks 2 to 5: build the ePHI inventory from procurement records, the identity provider's app list, cloud accounts, network scans and business associate agreements. Interview department heads for shadow systems.
- Weeks 4 to 7: collect evidence of current measures and run vulnerability and configuration scans.
- Weeks 6 to 8: score pairs in a workshop with system owners, so that ratings are challenged rather than self-declared.
- Weeks 8 to 9: write the risk management plan, obtain approval and start Critical remediation immediately.
- Ongoing: update on triggers and review annually. A risk analysis that is never repeated becomes inaccurate as systems change.
Small versus large organisations. A small practice with an EHR, email and a handful of devices can complete this in a few weeks, or use the SRA Tool. A hospital system or large business associate should run the analysis per facility or service line, roll results into an enterprise register, and align scoring with its enterprise risk method, such as NIST SP 800-30. See the NIST SP 800-30 Risk Assessment Guide.
Common failure patterns:
- Checklist instead of analysis: a gap assessment against the Security Rule's standards, with no assets, threats, likelihood or impact, does not meet the risk analysis specification.
- Incomplete inventory: the EHR is assessed, but not the backup system, the medical device network, the analytics database copy or the SaaS tools a department bought. In OCR's March 2025 settlement with Health Fitness Corporation, ePHI on a misconfigured server was discoverable on the internet from around 2015 and OCR found no accurate and thorough risk analysis until 2024.
- Analysis without management: risks are scored and filed, with no plan, owner or dates, so 164.308(a)(1)(ii)(B) is not met.
- Machine identities ignored: service accounts, interface credentials and vendor remote access are not listed as access paths. See the NHI Risk Scoring Guide.
- Done once: the analysis predates a cloud migration or acquisition and is never updated.
Framework mapping: the analysis corresponds to NIST SP 800-53 Rev. 5 RA-3 (Risk Assessment), RA-7 (Risk Response) and CM-8 (System Component Inventory), and to NIST CSF 2.0 ID.AM-07 (data inventories), ID.RA-01, ID.RA-03, ID.RA-04, ID.RA-05 and ID.RA-06. NIST SP 800-66 Rev. 2 maps each Security Rule standard to CSF subcategories and 800-53 controls.
Metrics: percentage of ePHI systems in the inventory with a scored risk row; number of Critical and High risks open past their due date; days since the last analysis update; percentage of remote access accounts (staff and vendor) with MFA; and percentage of business associates with a current BAA and security assessment.
References: 45 CFR 164.308 Administrative safeguards · HHS: Guidance on Risk Analysis · ONC and HHS: Security Risk Assessment Tool · NIST: SP 800-66 Rev. 2 Implementing the HIPAA Security Rule · 45 CFR 164.306 Security standards: general rules · 45 CFR 164.316 Policies and procedures and documentation requirements · HHS: OCR settles Security Rule investigation with Health Fitness Corporation · HHS: HIPAA Security Rule NPRM
This template summarises the HIPAA Security Rule risk analysis requirement and is not legal advice; adapt it to your organisation and confirm current requirements with HHS. Related NHI Mgmt Group resources: HIPAA Security Rule Guide · HIPAA Breach Notification Rule Guide · Vendor Security Assessment Template · IT Asset Inventory Template