A HIPAA risk assessment is the documented evaluation of the risks facing electronic protected health information (ePHI). Providers, health plans, and their business associates all have to complete one. It is not optional. 45 CFR §164.308(a)(1)(ii)(A) of the HIPAA Security Rule requires it by name. The U.S. Department of Health and Human Services (HHS) reports that a missing risk analysis is among the findings OCR cites most often.
A compliant assessment covers nine elements HHS names in its risk analysis guidance, and this guide groups them into six working steps. You end up with a scoped inventory of every place ePHI lives, and a scored list of the threats against it.
Then you write the plan that brings the high-scoring ones down. Most practices repeat the whole exercise once a year, and again after any major system change. The same discipline sits behind medical office HIPAA compliance generally.
Here’s how to conduct a HIPAA risk assessment in six steps: define the scope, inventory ePHI assets, identify threats and vulnerabilities, assess existing security controls, determine likelihood and impact of each risk, and document findings in a risk management plan. The full walkthrough for each step is below.
Key takeaways
A HIPAA risk assessment is legally required under 45 CFR §164.308(a)(1)(ii)(A) for every covered entity and business associate that handles ePHI.
HHS names nine elements of a compliant risk analysis, and this guide groups them into six working steps.
OCR expects the assessment to be accurate and thorough, covering every system, location, and workflow where ePHI exists.
Risk assessment and risk management are separate obligations, so identifying the risks satisfies only half the requirement.
Pabau’s audit logs, role-based access controls, and encrypted patient records support the technical safeguards the assessment reviews.
What is a HIPAA risk assessment and who must conduct one?
A HIPAA risk assessment is a systematic, documented evaluation of the threats and vulnerabilities facing ePHI across an organization’s systems, workflows, and physical sites. The Security Rule’s wording is “accurate and thorough”. OCR reads that to mean the assessment cannot stop at one department, one system, or one location.
Three categories of organization have to complete one:
- Covered entities: providers who transmit health information electronically, health plans, and healthcare clearinghouses
- Business associates (BAs): vendors and contractors that handle ePHI for a covered entity, from EHR vendors to billing companies to cloud storage providers
- Business associate subcontractors: anyone handling ePHI on behalf of a BA inherits the same obligation under the HITECH Act
Smaller practices and aesthetic providers are not exempt. A practice that transmits health information electronically for a standard healthcare transaction is a covered entity, whatever its size. Cash-pay aesthetic practices usually come into scope the moment they accept insurance or bill electronically.
Risk assessment vs. risk management: Key differences
Risk assessment and risk management are related but legally distinct obligations under the Security Rule. A large share of OCR citations go to organizations that ran an assessment and then never built the management plan that follows it.
The assessment feeds the management plan. You cannot build a workable plan without knowing which risks exist. Completing the assessment and then acting on none of it is itself a compliance failure.
How to conduct a HIPAA risk assessment: Step by step
HHS guidance identifies nine core elements for a compliant risk analysis. The six steps below cover all nine, and two of those steps carry more than one element each, which is where the schedule usually slips.
Practices working through this the first time find steps 3 and 5 the slowest. Give both dedicated time rather than treating them as quick checkboxes.

Step 1: Define the scope
The scope has to cover every system, location, and workflow where ePHI is created, received, maintained, or transmitted. The omissions that draw OCR scrutiny are predictable: remote employee laptops, personal phones used for clinical messaging, third-party cloud storage, and legacy fax-to-email gateways.
A practice that already runs a paperless, HIPAA-compliant practice has fewer physical sites to scope, but a wider electronic surface to account for.
- Clinical systems: EHR, practice management software, lab portals
- Administrative systems: billing platforms, scheduling tools, email
- Physical locations: all practice sites, off-site storage, home offices with ePHI access
- Third-party integrations: payment processors, telehealth platforms, cloud backup services
Step 2: Inventory ePHI assets
Map every data flow: where ePHI starts, where it moves, and where it comes to rest. This is a bigger job than listing your software. A practice on a cloud EHR still has to account for ePHI elsewhere. Email attachments to referring providers, photos on staff phones, and exported reports in a shared drive all count.
Step 3: Identify threats and vulnerabilities
Threats are the forces that could exploit a weakness and compromise ePHI. OCR groups them into three categories:
- Human threats: unauthorized access, phishing, insider misuse, workforce errors
- Environmental threats: floods, fires, and power failures affecting server rooms or devices
- Technical threats: malware, ransomware, unpatched software, unsecured APIs
Vulnerabilities are the weaknesses those threats exploit. Weak passwords, missing encryption, loose access controls, and untrained staff are the four that turn up most often in practice.
Step 4: Assess existing security controls
Work through each threat-vulnerability pair and judge whether your current safeguards address it. The Security Rule sorts controls into three groups. They are administrative (policies, training, access management), physical (facility locks, workstation controls, device disposal), and technical (encryption, audit logs, automatic logoff). Write down which safeguards are in place, and mark every risk that currently has no control behind it.
Step 5: Determine likelihood and impact of each risk
Score each risk on likelihood times impact. OCR does not prescribe a scoring model, so the three-tier approach below is a widely used and defensible starting point. This single step carries three of the nine HHS elements: likelihood, impact, and the resulting risk level.
Step 6: Document findings and implement a risk management plan
Documentation is the evidence OCR asks for during an investigation, so treat it as part of the work rather than a write-up afterwards. The written record has to include the scope, the methodology, and the data sources. It also carries the finding for each risk, the assigned risk levels, and the management plan with remediation dates. This step also carries the periodic review element, so note when the assessment is due to be revisited.
Pro Tip
Document your methodology, not just your findings. OCR investigators ask which systems were reviewed, who took part, what sources were consulted, and how likelihood and impact were scored. A one-page summary will not answer those questions.
How often the assessment has to be repeated
The Security Rule requires a “periodic” assessment under 45 CFR §164.306(e) but sets no fixed interval. OCR guidance instead names the events that call for a fresh assessment or a documented review. Waiting for a breach to prompt one is both reactive and expensive.
- New technology: EHR migrations, telehealth platforms, cloud storage adoptions
- Significant system changes: new integrations, API connections, major software updates
- Workforce changes: large-scale hiring, restructuring, or the departure of security personnel
- Facility changes: new practice locations, office moves, remote work policy changes
- Post-breach: any security incident involving unauthorized access to ePHI
- Mergers and acquisitions: inheriting another organization’s systems and data flows
Most practices settle on an annual cycle as the baseline and add event-driven reviews when one of the triggers above fires. An annual cadence also lines up with workforce training, which makes the assessment easier to fold into compliance work you already do.
How this differs from the breach notification rule
The Security Rule risk analysis is a different exercise from the four-factor breach risk assessment in the Breach Notification Rule (45 CFR §164.402). One is a scheduled review of your whole ePHI estate. The other is a same-week judgment call about a single incident.
When an unauthorized disclosure of ePHI happens, covered entities have to run that four-factor test to decide whether the incident is a reportable breach:
- Nature and extent of the PHI involved: which identifiers were exposed, and how easily the person could be re-identified
- The unauthorized person who used or received the PHI: whether the recipient is another covered entity or someone who could exploit the data
- Whether PHI was actually acquired or viewed: log evidence that the data was or was not opened
- Extent to which the risk has been mitigated: whether the receiving party gave satisfactory assurances that the data was destroyed
If the four-factor analysis cannot show a low probability of compromise, the disclosure is treated as a reportable breach. The two assessments connect in practice. A thin Security Rule analysis leaves weaker controls behind it, and weaker controls produce more incidents that need the four-factor test.
Common mistakes that draw OCR scrutiny
OCR settlement descriptions and audit findings point to a consistent set of failures, and none of them are limited to large hospital systems.
- Scope too narrow: limiting the assessment to the EHR and ignoring email, mobile devices, third-party integrations, and the physical sites where ePHI exists
- Missing business associate coverage: never checking that BAs ran their own assessments, or leaving ePHI sent to BAs outside the scope
- No documentation: running a verbal review, or working off a checklist without keeping the written output OCR can request
- One-and-done thinking: treating the assessment as a single event rather than a standing obligation that follows system and workflow changes
- Conflating assessment with management: documenting risks while putting no formal plan behind the high and medium findings
- Vague risk statements: writing “data may be compromised” instead of a specific threat-vulnerability pair tied to a named system and location
Tools and templates worth using
The most widely used free resource is the ONC/OCR Security Risk Assessment (SRA) Tool. It was built jointly by the Office of the National Coordinator for Health Information Technology and the HHS Office for Civil Rights. It is designed for small and mid-sized practices. It walks you through each element of the risk analysis and produces a report that maps onto the documentation OCR expects to see.
Whatever tool or template you pick, OCR scrutiny means it has to capture:
- Every ePHI location across administrative, clinical, and physical environments
- Identified threats and vulnerabilities per safeguard category
- An inventory of current controls, marked where a risk has no control behind it
- Likelihood and impact scores for each risk pair
- An overall risk level determination, with the reasoning written down
- A linked risk management plan with remediation timelines
Automated tools speed up data gathering and produce formatted reports, but OCR’s position is that no tool replaces a human-led review. The tool structures the process. Clinical and operational judgment decides what the findings mean for your workflow and your risk profile.
Dedicated HIPAA compliance software is worth comparing if you would rather keep the evidence in one system year-round. For organization-specific questions, particularly around BA relationships or new technology, qualified HIPAA counsel is the right call.
Penalties for skipping the risk analysis
OCR enforces HIPAA through civil monetary penalties (CMPs) set across four tiers by level of culpability, as defined in 45 CFR §160.404. The amounts below are HHS’s inflation-adjusted figures, effective January 28, 2026. OCR publishes the outcomes of its investigations in its resolution agreements. If an incident has already happened, the next step is knowing what to do if you violate HIPAA.
A missing risk analysis has been the cited violation in a long run of major OCR settlements. Civil penalties are not the only exposure. Egregious cases can be referred to the Department of Justice for criminal prosecution, particularly where a breach was deliberately concealed. State attorneys general also hold independent enforcement authority under HITECH, so one violation can attract both federal and state action.
How Pabau supports HIPAA-compliant practice management
When a practice runs its assessment, the platform holding the patient records is one of the biggest variables in the result. Most of step 4 comes down to what that system can prove: who opened a record, when, and under what permission. Practices on disconnected tools usually spend that step chasing screenshots and vendor emails.
Practice management software like Pabau ships those controls as standard, so the evidence is already there when you sit down to write the assessment up. Our compliance management software includes role-based access controls that limit ePHI to authorized staff.
It records every access and change in an audit log, and encrypts patient records at rest and in transit. Pabau also provides business associate agreements for covered entities in the US, which every BA relationship involving ePHI needs in place first.

That maps onto the technical safeguards the Security Rule asks you to assess. Audit log configuration answers the audit controls standard (§164.312(b)). Role-based access answers the access control standard (§164.312(a)(1)). Encryption answers the transmission security standard (§164.312(e)(1)). So you can point at settings and exports instead of rebuilding the picture from memory every year.
See how Pabau supports your HIPAA compliance workflow
Pabau provides audit logs, role-based access controls, encrypted patient records, and business associate agreements. Together they cover the technical and administrative safeguards your risk assessment has to evaluate.
Conclusion
The practices that come through an OCR investigation well are rarely the ones with the most controls. They are the ones who can produce a dated document showing what they looked at, what they found, and what they did about it. That document is the whole point of the exercise.
So the trade-off worth remembering is time now against evidence later. Two days a year to scope, score, and write it up is cheap. Reconstructing a year of decisions under an investigator’s deadline is not. Start with the scope, because every other step inherits its blind spots.
Pabau’s audit logs, role-based access controls, and encrypted patient records take most of the technical safeguard workload off that write-up. Book a demo to see how those controls produce the evidence your next risk assessment will need.
Continue your research
Want the technical safeguards in more depth? EHR security covers the encryption, access control, and audit settings your assessment has to review.
Operating under GDPR as well as HIPAA? GDPR checklist for UK clinics outlines the parallel documentation and access control duties for practices working across jurisdictions.
Does workforce error keep showing up in your risk register? HIPAA training for employees explains how to build and document the training your assessment will reference.
Frequently asked questions
What is the main purpose of a HIPAA risk assessment?
A HIPAA risk assessment is the evaluation the Security Rule requires. It covers the threats and vulnerabilities facing electronic protected health information (ePHI) across an organization’s systems and workflows. Its purpose is to give you an accurate picture of current exposure, so you can build a targeted risk management plan on top of it.
Who is required to conduct a HIPAA risk assessment?
All HIPAA covered entities (healthcare providers, health plans, and healthcare clearinghouses) and their business associates must conduct one under 45 CFR §164.308(a)(1)(ii)(A). Business associate subcontractors who handle ePHI on behalf of a BA inherit the same obligation under the HITECH Act.
How often should the assessment be repeated?
The Security Rule requires a periodic assessment but sets no fixed calendar interval. Most practices run a full review annually. They add event-driven assessments after new technology deployments, system changes, workforce restructuring, facility moves, breaches, and mergers.
What does the Security Rule require the assessment to cover?
It has to be accurate and thorough, and cover the confidentiality, integrity, and availability of all ePHI the organization creates, receives, maintains, or transmits. In practice that means a defined scope, an ePHI inventory, and threat and vulnerability identification. You also need a review of current controls, likelihood and impact scoring, documented risk levels, and a risk management plan.
Can I use a template or tool instead?
Yes. The free ONC/OCR Security Risk Assessment Tool is a widely accepted starting point. OCR’s position is that automated tools assist but do not replace a human-led analysis. Any tool you pick has to capture every ePHI location, the threat-vulnerability pairs, scored risk levels, and a remediation plan.
What happens if a covered entity fails to conduct a HIPAA risk assessment?
A missing risk analysis is one of the most frequently cited violations in OCR enforcement actions. Civil monetary penalties run from $145 to $73,011 per violation, capped at $2,190,294 per violation category per year, depending on the level of culpability. Repeated or willful failures can also be referred to the Department of Justice for criminal prosecution.
How does it relate to the Breach Notification Rule?
The Security Rule risk assessment is a proactive, periodic review aimed at systemic ePHI vulnerabilities. The Breach Notification Rule’s four-factor assessment is a reactive, incident-specific evaluation run after an unauthorized disclosure, to decide whether it is a reportable breach. The two are separate requirements under separate HIPAA regulations.