HIPAA Compliance · 2026-06-13 · 10 min read
HIPAA Security Risk Analysis Checklist for 2026: What OCR Actually Wants to See
OCR is putting fresh attention on HIPAA security risk analysis. This practical 2026 checklist shows small and mid-size healthcare teams how to scope ePHI, document risk, prioritize remediation, and prepare audit-ready evidence.
Why risk analysis deserves its own 2026 playbook
Most HIPAA programs fail quietly before they fail publicly. The policy binder exists. The EHR vendor says the platform is secure. Someone ran a vulnerability scan last year. A spreadsheet lists a few vendors. Everyone assumes that adds up to HIPAA compliance.
It usually does not.
The HIPAA Security Rule risk analysis requirement is narrower than "do security" and broader than "run a scan." It asks whether your organization has performed an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information, or ePHI.
That means the work has to connect the dots between patient data, systems, people, vendors, threats, safeguards, and follow-through. If an auditor or investigator asks how you know your ePHI is protected, the answer cannot be "our IT provider handles that." It has to be documented.
This topic is especially timely in 2026 for three reasons.
First, HHS OCR has initiated 2024-2025 HIPAA audits focused on Security Rule provisions most relevant to hacking and ransomware. Second, OCR's public guidance continues to describe risk analysis as foundational to choosing appropriate safeguards. Third, OCR's January 2026 cybersecurity guidance on system hardening points back to risk analysis and risk management as the context for deciding which baselines, patches, MFA controls, logging settings, and endpoint protections are appropriate.
One important status note: as of this publication date, June 13, 2026, the HIPAA Security Rule update is still a proposed rule, not final law. The current Security Rule remains in effect. But waiting for a final rule before tightening your risk analysis is the wrong bet. OCR is already looking at whether organizations understand their ePHI environment and can prove they are managing risk.
What a HIPAA security risk analysis is not
A useful security risk analysis starts by clearing out the common substitutes.
It is not just a vulnerability scan. A scan may identify technical weaknesses, but it does not show which ePHI workflows are exposed, how likely harm is, what safeguards are reasonable, or who owns remediation.
It is not just an EHR security statement. Your EHR may protect data inside its own platform, but HIPAA risk extends to workstations, mobile devices, cloud storage, email, billing systems, analytics tools, integrations, backups, vendors, exports, screenshots, and human workflows.
It is not just an annual policy review. Policies describe intent. Risk analysis tests reality.
It is not just a questionnaire. A questionnaire can help gather information, but the final work product should show scope, method, findings, risk decisions, remediation priorities, and evidence.
It is not one-and-done. Your risk analysis should be refreshed when material changes occur: new systems, new locations, new vendors, new integrations, new AI tools, new telehealth workflows, new user roles, acquisitions, security incidents, or major infrastructure changes.
The 10-part HIPAA security risk analysis checklist
Use this checklist as a practical structure. Smaller practices can keep the artifacts lightweight. Larger organizations may need deeper detail. Either way, the goal is the same: show that the organization knows where ePHI lives, how it moves, what could go wrong, what safeguards exist, and what still needs remediation.
1. Define the ePHI scope before reviewing controls
Start with the data, not the tools.
Identify every place your organization creates, receives, maintains, or transmits ePHI. Include clinical records, patient demographics, billing data, insurance information, lab results, images, prescription data, appointment details, telehealth records, portal messages, intake forms, scanned documents, call recordings, support tickets, and exported reports.
A common mistake is limiting scope to the EHR. OCR will not care that a spreadsheet was "outside the EHR" if it contained patient names, diagnoses, insurance IDs, or treatment information.
Evidence to keep:
- ePHI data inventory
- systems and workflows included in scope
- systems excluded from scope and why
- date of review
- reviewer and approver
2. Build an asset inventory that includes boring systems
Risk analysis needs an asset inventory, but the word "asset" should not only mean servers. For a healthcare practice, assets include laptops, desktops, tablets, phones, printers, scanners, routers, firewalls, Wi-Fi networks, backup drives, EHR systems, billing software, email, cloud folders, password managers, remote access tools, and medical devices that store or transmit ePHI.
The boring assets are often where risk hides. A front-desk scanner, shared mailbox, old laptop, unmanaged tablet, or exported billing report can create more real exposure than the system everyone already monitors.
Evidence to keep:
- device and software inventory
- owner or department
- ePHI status
- location
- support status
- encryption status
- patch responsibility
- last review date
3. Map how ePHI moves
Most risk is created in movement. A patient completes an intake form. A staff member downloads a report. A claim is sent to billing. A specialist receives records. A vendor gets access for support. A backup is copied to cloud storage. A clinician sends a message from a phone.
Your risk analysis should map the highest-risk data flows in plain language. You do not need a perfect enterprise architecture diagram to start. You do need enough detail to show how ePHI enters, moves through, and leaves the organization.
Evidence to keep:
- ePHI flow diagrams or workflow notes
- inbound sources
- outbound destinations
- transmission methods
- vendors involved
- encryption or secure transport controls
- manual workarounds
4. Include business associates and hidden vendors
Vendor risk belongs inside the risk analysis because business associates may create, receive, maintain, or transmit ePHI on your behalf.
Do not only review vendors already listed in your compliance spreadsheet. Pull from invoices, browser extensions, SSO apps, email forwarding rules, practice management software, marketing forms, scheduling tools, transcription services, outsourced billing, answering services, IT support, cloud storage, backup providers, analytics products, AI tools, and document signing platforms.
For each vendor, determine whether they touch PHI, whether a BAA is required, whether one is signed, what service they provide, what systems they access, and what evidence you have that their controls are appropriate.
Evidence to keep:
- vendor inventory
- PHI access classification
- BAA status
- vendor owner
- risk tier
- review date
- renewal or termination date
- remediation items
5. Identify threats and vulnerabilities in context
A threat is something that could cause harm. A vulnerability is a weakness that could be exploited by a threat.
For healthcare teams, common threats include ransomware, phishing, credential theft, lost devices, unauthorized employee access, misdirected emails, exposed cloud folders, weak remote access, unsupported software, vendor compromise, natural disasters, power loss, and insider misuse.
Common vulnerabilities include missing MFA, shared accounts, weak passwords, incomplete logging, old operating systems, unmanaged devices, unencrypted laptops, lack of backups, weak vendor review, poor termination workflows, and policies that are not followed in practice.
The point is not to list every possible bad thing. The point is to identify realistic risks to your actual ePHI environment.
Evidence to keep:
- threat list
- vulnerability list
- source of findings
- affected systems or workflows
- related ePHI
- current safeguards
6. Rate risk in a way humans can defend
Risk scoring does not need to be mathematically fancy. It needs to be consistent and explainable.
A practical model uses likelihood, impact, and current control strength. For example, phishing against email accounts may be high likelihood. If email contains patient data and MFA is incomplete, the impact may also be high. That risk deserves priority.
Avoid vague labels without rationale. "Medium risk" is not useful unless the reader can see why it was scored that way.
Evidence to keep:
- scoring method
- likelihood criteria
- impact criteria
- risk rating for each finding
- rationale
- reviewer notes
7. Connect safeguards to specific risks
Controls should not float separately from risks. If the risk is unauthorized remote access, the safeguards might include MFA, conditional access, device posture checks, VPN restrictions, logging, and periodic access review. If the risk is ransomware, safeguards might include patching, endpoint protection, offline backups, recovery testing, phishing training, least privilege, and network segmentation.
This is where OCR's system-hardening guidance becomes practical. Patching, removing unnecessary services, enabling security tools, and applying baselines should be tied back to the systems that store or transmit ePHI.
Evidence to keep:
- safeguard mapped to risk
- implementation owner
- implementation date
- configuration evidence
- policy or procedure reference
- exception notes
8. Create a remediation plan with owners and dates
A risk analysis without remediation is a snapshot, not a management process.
Every material gap should have an owner, priority, target date, status, and expected evidence. If leadership accepts a risk temporarily, document who accepted it, why, for how long, and what compensating controls exist.
The most defensible programs do not pretend everything is fixed. They show that risks are known, prioritized, assigned, and tracked.
Evidence to keep:
- remediation register
- owner
- due date
- status
- completion evidence
- accepted risk documentation
- leadership sign-off
9. Build the evidence packet as you go
Do not wait until an audit to assemble evidence. Create a lightweight packet while the work is fresh.
That packet should include the risk analysis report, data inventory, asset inventory, vendor inventory, methodology, risk register, remediation plan, meeting notes, approvals, and key control evidence.
Strong filenames matter more than people think. "MFA screenshot final final.png" is not evidence management. Use names that describe the control, system, date, and owner.
Evidence to keep:
- final risk analysis report
- supporting inventories
- remediation register
- approval record
- evidence index
- next review date
10. Refresh after real changes, not just calendar anniversaries
Annual review is the floor, not the full program.
Trigger a risk-analysis update when the organization adds a new EHR module, starts telehealth, changes billing vendors, adopts an AI tool, opens a new location, changes cloud storage, connects a new integration, experiences a security incident, or materially changes remote access.
This keeps the risk analysis connected to the business instead of becoming a yearly paperwork ritual.
Evidence to keep:
- change log
- trigger event
- scope of review
- new or changed risks
- decisions made
- updated remediation items
What OCR or an auditor will expect to see
If someone asks for your security risk analysis, they are usually looking for more than a PDF. They want proof that the process was accurate, thorough, current, and connected to action.
Be ready to show:
- where ePHI is created, received, maintained, and transmitted
- which systems and vendors are in scope
- how risks were identified
- how likelihood and impact were scored
- which safeguards already exist
- which gaps remain
- who owns remediation
- what has been fixed
- what leadership reviewed and approved
- when the analysis will be refreshed
The weakest answer is "we use a secure EHR." The stronger answer is "here is our ePHI inventory, here is our system map, here are the top risks we found, here is what we fixed, here is what remains, and here is the owner and date for each open item."
A 30-day SRA plan for small healthcare practices
If your practice has not done a real risk analysis, start small but make the work concrete.
Week 1: Inventory ePHI, systems, users, devices, vendors, and data flows. Do not score risk yet. Just find the moving pieces.
Week 2: Identify threats and vulnerabilities. Focus on the workflows that touch the most ePHI or create the easiest access path for attackers.
Week 3: Score risks and choose safeguards. Prioritize MFA, backups, patching, endpoint protection, access review, vendor BAAs, email security, logging, and encryption.
Week 4: Write the report and remediation plan. Assign owners, due dates, and evidence expectations. Schedule the next review before the month ends.
The goal is not perfection. The goal is a living risk-management process that a real team can maintain.
Common mistakes to avoid
The first mistake is copying a generic template and never adapting it to your environment. Templates can help structure the work, but they cannot identify your ePHI.
The second mistake is treating risk analysis as an IT-only task. Compliance, operations, clinical leadership, billing, HR, and vendor owners often know workflows that IT has never seen.
The third mistake is ignoring vendors that feel administrative. Billing, scheduling, marketing, transcription, answering services, legal support, and analytics can all touch PHI.
The fourth mistake is failing to document accepted risk. If you cannot fix something immediately, write down the interim decision.
The fifth mistake is separating risk analysis from evidence. If you cannot produce proof of the safeguard, the safeguard may not help you during review.
How Shieldra helps
Shieldra is built for the unglamorous work that makes HIPAA defensible: keeping evidence current, connecting findings to remediation, tracking vendors and BAAs, organizing audit trails, and helping small teams understand what to do next.
A strong HIPAA security risk analysis is not just a compliance document. It is the map that tells your team where patient data lives, where exposure exists, and what to fix first.
That is why the best time to start is before OCR, a customer, a cyber insurer, or a breach forces the question.
Quick FAQ
Is a HIPAA security risk analysis the same as a risk assessment?
People often use the terms interchangeably. Under the HIPAA Security Rule, the required implementation specification is risk analysis. In practice, many teams call the broader project a security risk assessment, or SRA. The important thing is that the work accurately and thoroughly evaluates risks and vulnerabilities to ePHI.
How often should we do a HIPAA security risk analysis?
Review it at least annually and whenever material changes occur. New systems, vendors, workflows, locations, integrations, AI tools, incidents, or infrastructure changes can all justify an update.
Does our EHR's HIPAA compliance cover our practice?
No. Your EHR may provide important safeguards inside its platform, but your organization is still responsible for workforce access, devices, exports, vendors, email, backups, policies, training, incident response, and the rest of the ePHI environment.
Is the 2026 HIPAA Security Rule final?
As of June 13, 2026, HHS OCR's public materials still describe the Security Rule update as proposed, and the current Security Rule remains in effect. Organizations should prepare for the direction of travel, but should not describe proposed requirements as final law.
What is the fastest useful first step?
Build the ePHI inventory. If you do not know where patient data lives and moves, every later control decision becomes guesswork.
