Scrutineer · By framework

HIPAA risk assessment software and risk analysis tool

Your last security risk analysis covered the EHR. It did not cover the imaging archive, the shared mailbox the front desk uses for referrals, or the eleven vendors holding ePHI on your behalf. That gap is the finding in almost every enforcement action OCR has announced under its Risk Analysis Initiative.

Scrutineer inventories where ePHI actually lives, runs the analysis against all of it, and keeps the remediation trail that shows each risk was managed, not just listed.

or try it below ↓

Control-mapped findings · linked evidence · you decide what to remediate

The Scrutiny Desk

Illustrative sample · not an audit attestation

SOC 2 ISO 27001 HIPAA GDPR PCI DSS

Controls in evidence-linked report out

AI scrutinizes you decide

Why it works

What you get with HIPAA risk assessment

The Security Rule does not say annual, and the calendar you are working to came from a payment program

Look up the obligation itself and the frequency is not there. 45 CFR 164.308(a)(1)(ii)(A) reads, in full: "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 or business associate." That specification is Required, not Addressable, so there is no reasonable-and-appropriate escape hatch on it. What it does not contain is a number, a month, or the word annual. The annual habit comes from somewhere else entirely: the CMS Medicare Promoting Interoperability and MIPS Security Risk Analysis measure, which asks eligible clinicians and hospitals to conduct or review a security risk analysis of certified EHR technology at least once each calendar year, in the calendar year in which the EHR reporting period falls, and to attest that they did. That is an attestation measure attached to a payment program, scoped to certified EHR technology. It is a good habit and it is not the Security Rule. The practical consequence matters, because organizations that treat the calendar as the obligation end up with a compliant-looking annual document that covers one system, while the specification they are actually judged against asks about all ePHI they hold. OCR findings almost never turn on the date. They turn on scope and accuracy.

The rule the market is selling against is not the rule being enforced

On January 6, 2025, HHS published a Notice of Proposed Rulemaking titled "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," Federal Register document 2024-30983, RIN 0945-AA22, running 125 Federal Register pages. It proposed removing the Addressable and Required distinction so that nearly everything becomes required, and adding explicit duties: a technology asset inventory and network map, multi-factor authentication, encryption of ePHI at rest and in transit, annual audits of Security Rule compliance, and vulnerability scanning and penetration testing on a defined cadence. The comment period closed March 7, 2025. It has not been finalized. Reporting on the 2026 Unified Agenda places RIN 0945-AA22 on the Long-Term Actions list with July 2027 given as the anticipated timeframe for final action, which in practice signals that HHS does not expect to issue a final rule within the next twelve months, and any compliance date would then sit well beyond that. OCR received close to 5,000 comments on it. Two things follow. Buying a platform today because it promises readiness for a rule that does not exist yet is buying a forecast. Meanwhile the 2003 Security Rule, with its Required risk analysis specification, is the rule OCR is enforcing right now, and it is the one generating settlements.

Running the free SRA Tool is not the same as having done a risk analysis

The HHS and ONC Security Risk Assessment Tool is a genuinely useful, genuinely free desktop application aimed at small and medium practices, and its own disclaimer says plainly that "Use of this tool is neither required by nor guarantees compliance with federal, state or local laws." The reason is structural rather than a matter of quality. The tool analyzes what you tell it about. It does not discover ePHI, it does not read your vendor agreements, and it does not know about the network share the billing team set up in 2019. So an organization can complete every question honestly and still fail the specification, because the specification asks for an accurate and thorough assessment of the ePHI the entity holds, and a questionnaire scoped by the person answering it is only as complete as their memory of the environment. This is the failure pattern in the enforcement record: not that no assessment was done, but that the one on file was not enterprise-wide. OCR has been extending the same reasoning into the next specification along, 164.308(a)(1)(ii)(B) risk management, which is also Required and asks you to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. A register of risks with nothing recorded against them satisfies neither.

What it handles

Controls in, an evidence-linked report out

Point Scrutineer at a framework or a vendor and it maps every control, pulls the evidence it can find, flags the gaps and scores the risk, returning a report with linked evidence and a prioritized remediation list. Scrutineer is decision support for readiness, an accredited auditor still issues the attestation.

Builds the ePHI inventory first, so the analysis is scoped to where the data actually is rather than to the systems someone remembered
Covers the whole estate in one assessment: EHR, imaging, email, backups, endpoints, cloud infrastructure and the vendors holding ePHI for you
Carries the administrative, physical and technical safeguards of 45 CFR 164.308, 164.310 and 164.312 as controls you evidence, not prose you write
Separates Required from Addressable and records the documented rationale where you implement an equivalent measure instead
Tracks remediation against each identified risk with an owner and a date, which is the 164.308(a)(1)(ii)(B) risk management half most assessments skip
Keeps every business associate in the same register, with the BAA, the assurances collected and the date each was last reviewed
Reuses one control set across HIPAA, SOC 2, ISO 27001 and PCI, so a hospital or a health tech vendor stops running four parallel evidence hunts
Produces a dated, versioned assessment you can hand to OCR, a health system customer, or your cyber insurer without rebuilding it from scratch

HIPAA RISK ASSESSMENT readiness_report

READINESS · 82%

ACCESS CONTROL 91

evidence · MFA enforced and access reviews evidenced.

CHANGE MGMT 78

evidence · Mostly covered; one approval log left untested.

VENDOR RISK 64

evidence · Two subprocessors missing a current review.

ENCRYPTION 86

evidence · Data encrypted in transit and at rest, evidenced.

Example report layout, not customer data

Why Scrutineer

One platform that maps controls and scores risk

Not a static questionnaire, not a pass-fail black box, and not a spreadsheet you maintain by hand. Live control mapping across SOC 2, ISO 27001, HIPAA, GDPR and PCI, automatic evidence and a prioritized gap list, returned as a report you can act on. The AI scrutinizes, you decide.

Mapped to real controls

Every framework is broken down into the controls it actually requires, each scored on a red to amber to green scale, so readiness stays transparent and consistent.

Evidence behind every finding

Each control links to the exact evidence that satisfies it, the policy, the config, the log line, so the finding is auditable and your readiness is defensible.

A prioritized gap list

Open gaps roll up into a ranked remediation list, so the highest-risk findings sit at the top and your team fixes what matters before the audit begins.

ePHI location reference

Where ePHI actually lives, and whether your risk analysis reached it

Every published guide to HIPAA risk analysis runs on the nine elements of the assessment method. That is not where assessments fail. They fail on scope, because the analysis was built around the systems someone could name in a meeting. So this table runs on location: who owns it internally, whether it typically makes it into the assessment at all, what OCR asks to see, and the specific reason each one gets missed.

Where ePHI lives	Who owns it internally	Does it make the risk analysis	What OCR asks to see	Why it gets missed
EHR or practice management system	Clinical IT or the EHR vendor	Almost always. This is the system people mean when they say they did the SRA	Access controls, audit log review, user provisioning and termination records	It does not. This is the one location that is reliably covered
Backups, snapshots and disaster recovery copies	Infrastructure or a managed service provider	Frequently missing. Backups are treated as an IT function, not an ePHI location	Encryption state, retention, restore testing, and who can access the backup console	The data is a copy, so nobody files it under ePHI, and ransomware cases turn on exactly this
Email, shared mailboxes and secure messaging	IT, usually with no clinical owner at all	Rarely, beyond a line saying email is encrypted	Encryption in transit, retention, mailbox delegation, and what happens to referral attachments	Referral and prior authorization traffic accumulates ePHI in a mailbox nobody considers a repository
Imaging, PACS and diagnostic modalities	Radiology, often with vendor-managed appliances	Sometimes named, seldom assessed, because the vendor manages the appliance	Network segmentation, authentication on the modality, and vendor remote access controls	Vendor-managed means someone else patches it, which gets read as someone else owns the risk
Connected medical devices and infusion pumps	Biomedical engineering, a separate department from IT	Almost never. Biomed inventories and IT inventories are different spreadsheets	A device inventory, supported software versions, and compensating controls where patching is impossible	Two departments each assume the other counted them, and neither list feeds the risk analysis
Employee endpoints, mobile devices and home offices	IT, with real gaps for contractors and locums	Partially, usually as a policy statement rather than an assessed control	Encryption enforcement, MDM enrollment coverage, and remote wipe evidence	Policy is confused with control. A written mobile policy is not evidence that devices are encrypted
ePHI held by business associates and their subcontractors	Nobody, in most organizations	Least covered location by a wide margin, and typically the largest population of records	A current BA inventory, executed BAAs, and the assurances you collected and reviewed	You do not hold it, so it does not feel like yours. The Security Rule disagrees, and the biggest reported breaches keep landing here

The last row is the one that decides outcomes. ePHI held by business associates and their subcontractors is simultaneously the largest population of records most organizations are accountable for and the location least likely to appear in their risk analysis, because it does not feel like theirs to assess. The Security Rule names the business associate in the same sentence as the covered entity, and the breach reports keep arriving from that tier.

Good questions

Questions about HIPAA risk assessment

A HIPAA risk assessment, called a risk analysis in the regulation, is an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the electronic protected health information your organization holds. It is a Required implementation specification at 45 CFR 164.308(a)(1)(ii)(A), which means every covered entity and every business associate owes it, with no reasonable-and-appropriate opt out.

One thing above all: whether the analysis was enterprise-wide and accurate. OCR opened a Risk Analysis Initiative aimed squarely at this single specification, and by 2026 had announced more than a dozen enforcement actions under it. The recurring finding is not a missing document. It is an analysis that existed and covered only part of the environment, usually the EHR, while ePHI sat in backups, shared mailboxes and vendor systems the assessment never reached.

No date is set, because the rule is not final. HHS proposed it on January 6, 2025 and took comments until March 7, 2025. Reporting on the 2026 Unified Agenda places RIN 0945-AA22 on the Long-Term Actions list with July 2027 as the anticipated timeframe for final action, and as proposed the rule would become effective 60 days after publication with compliance due 180 days after that. Plan against the 2003 Security Rule, which is what OCR enforces today.

In practice, nothing. The regulation uses "risk analysis" and the market says "risk assessment," and they refer to the same Required specification. The distinction worth drawing is a different one: risk analysis is identifying and rating the risks, while risk management at 164.308(a)(1)(ii)(B) is implementing measures that reduce them. Both are Required, and organizations that do the first and skip the second are the ones getting findings.

The Security Rule sets no frequency at all. The word annual does not appear in the risk analysis specification. The annual expectation comes from the CMS Promoting Interoperability and MIPS Security Risk Analysis measure, which asks participants to conduct or review an analysis at least once each calendar year. The defensible standard is to reassess whenever the environment changes materially: a new EHR, an acquisition, a new location, a breach, or a significant new vendor.

Start by inventorying where ePHI is created, received, maintained and transmitted, including vendors. Then identify threats and vulnerabilities for each location, assess current security measures, rate likelihood and impact, and document a risk level for each finding. Finish with the part that gets skipped: assign an owner and a date to every risk you intend to reduce, and record what you actually did. The documentation is the deliverable.

Anyone competent to do it. HIPAA does not require an external assessor, a certification, or a licensed firm, unlike SOC 2 or ISO 27001. You can run it internally with software, hire a consultant, or combine both. What OCR examines is the quality and scope of the analysis and the evidence that it drove remediation, not who signed it. Internal ownership tends to age better, because the person maintaining it knows the environment.

No. The SRA Tool published by HHS and ONC is optional, free, and aimed at small and medium practices, and HHS states that using it does not guarantee compliance. It is a structured questionnaire, so it analyzes what you enter. It cannot discover an ePHI repository you forgot, read your business associate agreements, or track remediation over time, which are the areas where enforcement findings concentrate.

It becomes the violation, independent of any breach. OCR opened a Risk Analysis Initiative specifically to pursue failures of this one specification, and the enforcement pattern is consistent: after an incident, the investigation finds no accurate and thorough enterprise-wide risk analysis, and that finding anchors the resolution agreement and corrective action plan. Settlements have run from tens of thousands of dollars into seven figures depending on size and history.

Yes. Since the 2013 Omnibus Rule, business associates are directly liable for Security Rule compliance, and 164.308(a)(1)(ii)(A) names the business associate explicitly. A health tech vendor, billing company, cloud host or analytics provider handling ePHI owes the same Required risk analysis a hospital does. Subcontractors of business associates owe it too, which is why the vendor chain matters more here than in most frameworks.

At minimum: the scope of ePHI covered, a data collection method, identified threats and vulnerabilities, an assessment of current security measures, likelihood and impact ratings, a determined risk level for each finding, and documentation of the whole thing. OCR guidance treats those as the elements of a compliant analysis. Add the ePHI inventory that produced the scope, because the scope statement is where most assessments quietly go wrong.

A gap analysis compares your current state to the Security Rule requirements and lists what is missing. A risk analysis asks a harder question: given your environment, what could actually happen to ePHI, how likely is it, and how bad would it be. A gap analysis is a useful starting point and it does not satisfy 164.308(a)(1)(ii)(A) on its own, because it is measured against a checklist rather than against your data.

Published figures vary too widely to quote a single number honestly. The drivers are what matters: the number of locations and systems in scope, whether an ePHI inventory already exists, how many business associates you hold, whether you need an on-site walkthrough, and whether you are buying a one-time report or software that maintains the analysis between reviews. A consultant-delivered report priced once is usually the most expensive option per year, because it is stale by the next quarter.

It has to. The specification covers ePHI held by the covered entity or business associate, and ePHI a vendor processes on your behalf is still within your risk picture. In practice that means a current inventory of business associates, an executed BAA for each, a record of the assurances you obtained, and a review date. This is the least covered area in most assessments and the one where the largest reported breach counts keep appearing.

They overlap and they are not identical. The CMS measure is scoped to certified EHR technology and asks you to attest that you conducted or reviewed an analysis in the calendar year, including addressing encryption of data. The Security Rule specification is scoped to all ePHI you hold. An assessment built for the CMS attestation will usually be narrower than the one OCR expects, which is exactly how organizations end up with a document that satisfies an auditor and not a regulator.

Not in the current Security Rule text, which is part of why so many assessments are incomplete. The January 2025 proposed rule would add an explicit written inventory of technology assets and a network map, updated at least annually and after material changes. That proposal has not been finalized. As a practical matter you cannot produce an accurate and thorough analysis of the ePHI you hold without knowing where it is, so the inventory is already the first step whether or not it is written into the rule.

Read every compliance and risk question

Keep reading

Guides that go deeper on HIPAA risk analysis

Best HIPAA risk assessment software

The five kinds of tool sold for this, what each produces, and which one fits a practice versus a health system.

Read the guide

HIPAA compliance checklist

The administrative, physical and technical safeguards in order, with what counts as evidence for each.

Read the guide

How to conduct a cybersecurity risk assessment

The general method behind the HIPAA-specific one: scoping, threat identification, rating and treatment.

Read the guide

Explore more

More ways to scrutinize compliance and risk with Scrutineer

SOC 2 compliance

Map controls to the Trust Services Criteria, collect evidence, and close gaps before audit.

Learn more

SOC 2 compliance software

A platform that maps SOC 2 controls, automates evidence, and tracks readiness continuously.

Learn more

ISO 27001 compliance

Map your ISMS to Annex A, automate evidence, and stay certification-ready.

Learn more

See every use case See pricing Back to Scrutineer

Stop guessing about readiness. Scrutinize on real evidence.

Point Scrutineer at a framework or a vendor and it maps every control, gathers evidence and scores the risk, returning an evidence-linked report and a prioritized gap list. The AI scrutinizes, you decide.

See pricing

SOC 2, ISO 27001, HIPAA, GDPR & PCI · evidence-linked controls · readiness, not certification