HIPAA risk analysis checklist: 27-point review before an audit

Before an audit, review your HIPAA risk analysis against what Office for Civil Rights (OCR) investigators actually check: that a current document exists (dated within the past 12 months), that its scope names every system, vendor, and location touching electronic protected health information (ePHI), that it identifies specific threats and vulnerabilities with likelihood and impact ratings, and that a Risk Management Plan is tied to it. The 27-point checklist below is organized around exactly those findings.

OCR investigators do not grade on effort. They grade on documentation. When an investigation opens — whether from a complaint, breach report, or the Risk Analysis Initiative — the first document requested is the risk analysis. The investigator's initial assessment of your practice happens in minutes: is there a document, is it dated recently, does it name actual systems or use generic language.

This checklist reflects what OCR looks for. It is organized into four phases: preparation, scope definition, threat analysis, and documentation quality. Use it to prepare your analysis, or to review an existing analysis before it is tested in an investigation.

Phase 1: Pre-analysis preparation

Before beginning the risk analysis, ensure you have the information required to make it accurate and specific.

1. Asset inventory complete

• List of all devices (computers, laptops, tablets, phones, printers, servers) that store or transmit ePHI
• List of all software systems that touch ePHI (electronic health record (EHR), practice management, billing, email, imaging, backup)
• Vendor inventory including business associates with ePHI access
• Network diagram or description showing how systems connect
• Location inventory (primary office, satellites, remote worker setups)

2. Access inventory complete

• List of all workforce members with ePHI access by role
• Documentation of access levels (who can see what)
• List of former employees whose access should be revoked (and confirmation it was)
• Inventory of personal devices used for work (bring your own device (BYOD) phones, home laptops)

3. Current controls documented

• Administrative controls: policies, training records, access management procedures
• Physical controls: facility access, workstation security, device disposal
• Technical controls: encryption status, access controls, audit logging, automatic logoff

4. Previous analysis reviewed

• Prior risk analysis located (if any)
• Date of prior analysis noted
• Changes since prior analysis identified (new systems, vendors, locations, staff)
• Gaps in prior analysis noted for correction

Why this matters: OCR settlements cite practices that conducted risk analyses without accurate inventory. An analysis based on incomplete information fails the accuracy standard before the first threat is assessed.

Phase 2: Scope definition

The scope sets the boundaries of the analysis. OCR looks for completeness.

5. Organization identification

• Legal name of covered entity
• All locations included in scope
• Number of employees and workforce members
• Specialty or type of practice

6. Responsible party identified

• HIPAA Security Officer named
• Contact information provided
• Authority to conduct analysis documented

7. Systems in scope named specifically

• Primary EHR: [Vendor name, version, hosting model]
• Practice management system: [Vendor name, integration with EHR]
• Email system: [Platform, encryption status, mobile access]
• Imaging systems: [PACS vendor, storage location, backup]
• Telehealth platform: [Vendor, security features, business associate agreement (BAA) status]
• Billing/clearinghouse: [Vendor, transmission methods]
• Backup systems: [Vendor, frequency, encryption, offsite status]
• Cloud storage: [Vendor, data types stored, access controls]

8. ePHI types identified

• Patient demographic information
• Clinical notes and diagnoses
• Billing and insurance information
• Appointment schedules
• Communications (patient portal messages, emails)
• Imaging files and diagnostic results

Red flag for investigators: Generic system descriptions like "our EHR" without vendor names, or "email" without specifying the platform. Specific names demonstrate the analysis was conducted; generics suggest copying.

Phase 3: Threat and vulnerability analysis

This is the core of the risk analysis. OCR expects to see specific threats to your specific environment.

9. Adversarial threats assessed

• Ransomware (likelihood assessed for your practice size/region)
• Phishing and business email compromise
• Insider threat — intentional misuse by authorized user
• Third-party/vendor compromise (business associate breach)
• Physical theft of devices with ePHI

10. Accidental threats assessed

• Misdirected email or fax (wrong recipient)
• Lost or stolen laptop/phone/tablet
• Accidental deletion or corruption
• Unintentional disclosure by staff
• Configuration error exposing data

11. Environmental threats assessed

• Fire or flood at primary location
• Extended power outage
• Hardware failure (server, storage)
• Natural disaster (region-specific: earthquake, hurricane, tornado)

12. Structural threats assessed

• Insufficient backup or untested recovery
• Lack of access review or recertification
• Inadequate workforce training
• Missing or outdated business associate agreements
• Unpatched systems or end-of-life software

13. Vulnerabilities identified per threat

• For each threat, at least one vulnerability that would make it possible
• Vulnerabilities specific to your environment (not generic lists)
• Current controls mapped to each vulnerability

OCR pattern: Resolution agreements cite practices that listed threats but failed to connect them to specific vulnerabilities in their environment. "Ransomware is a threat" is insufficient. "Ransomware via unpatched workstations and phishing-prone email" is specific.

14. Likelihood rated with rationale

• Likelihood scale defined (High/Medium/Low with criteria)
• Each threat-vulnerability pair assigned likelihood
• Rationale documented (based on industry data, prior incidents, or environment-specific factors)

15. Impact rated with rationale

• Impact scale defined (High/Medium/Low with criteria)
• Each threat-vulnerability pair assigned impact
• Rationale documented (number of records affected, business disruption, reputational harm)

16. Risk level determined

• Risk matrix or calculation method documented
• Each risk assigned level (Critical/High/Medium/Low)
• Methodology explains how likelihood and impact combine

Phase 4: Documentation quality

The analysis must stand alone. An investigator reading it should understand what was assessed, how, and what was found.

17. Methodology documented

• Framework named (National Institute of Standards and Technology (NIST) SP 800-30 Rev. 1 per U.S. Department of Health and Human Services (HHS) guidance)
• Assessment approach described (interviews, log review, vendor documentation)
• Data sources identified
• Assumptions and limitations noted

18. Risk register complete

• Prioritized list of all identified risks
• Each risk tied to specific asset and threat
• Risk level clearly indicated
• Risk owners identified where applicable

19. Current controls assessed

• Existing controls listed per risk
• Control effectiveness rated
• Residual risk noted where controls reduce but do not eliminate risk

20. Gaps identified

• Missing controls noted
• Inadequate controls flagged for improvement
• Unacceptable risks flagged for immediate action

21. Dated and signed

• Completion date on document
• Review date scheduled (annual or event-triggered)
• Responsible party signature or attestation

Phase 5: Risk Management Plan connection

OCR requires both the analysis and the plan. They look for the connection.

22. Risk Management Plan exists

• Separate documented plan for managing identified risks
• Reference to the risk analysis it addresses (date, version)

23. Mitigations mapped to risks

• Each significant risk has a proposed mitigation
• Mitigation is specific (not "address this" but "enable multi-factor authentication (MFA) by [date]")

24. Timelines established

• Completion dates for each mitigation
• Reasonable timelines based on risk priority

25. Responsible parties assigned

• Named individual or role for each action
• Authority to complete action confirmed

26. Review cycle defined

• Plan includes scheduled review dates
• Triggers for out-of-cycle updates (breach, new system, audit finding)

27. Both documents current

• Risk analysis dated within 12 months
• Risk Management Plan updated to reflect current analysis
• Prior analysis versions retained (version history)

Using this checklist

For preparation: Work through Phases 1–3 to gather information before conducting the analysis. The checklist ensures you have what you need.

For review: After completing an analysis, use Phases 4–5 to verify quality. Each unchecked item is a potential finding in an OCR investigation.

For maintenance: Annual updates should confirm all items remain accurate. Changes to systems, vendors, or staff require revisiting relevant sections.

A defensible risk analysis is not a one-time project. It is a living documentation practice that reflects your environment accurately, thoroughly, and currently. The 60–90 minutes to conduct a structured analysis with the right guidance is the investment that satisfies the requirement. The CoreFolio HIPAA assessment guides through this checklist with practice-specific prompts, ensuring each section is complete and correctly documented.

Sources