Most Security Risk Analysis work goes wrong before anyone answers a single question about safeguards. It goes
wrong at the inventory, because an SRA can only evaluate risk to systems it knows exist.
Miss a system, and every downstream control question about it is unasked. The report comes back clean. The
system is still there.
What the rule asks for
45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of potential risks and vulnerabilities
to the confidentiality, integrity, and availability of electronic protected health information held by the
organization.
Two words carry the weight. Accurate and thorough. Both are properties of scope before they are properties of
analysis, and scope is the inventory.
The systems that get missed
In practice, the EHR is never the problem. Everyone inventories the EHR. What gets missed is everything that
touches ePHI without being thought of as a clinical system:
- Backup and disaster recovery targets. Snapshots of a database holding ePHI are ePHI. Retention windows on backup media routinely outlive the retention policy written for the primary system.
- Log aggregation and observability. Application logs capture request payloads. If a payload carries a patient identifier and the log ships to a third-party platform, that platform is in scope and probably needs a business associate agreement.
- Non-production environments. Staging seeded from a production dump is the single most common ePHI location that no one lists. It usually has weaker authentication and broader developer access than production, which is the exact inversion you do not want.
- Message queues, caches, and object storage. Anything holding a payload in transit tends to hold it longer than the design assumed. Dead-letter queues are the specific offender.
- Endpoints. Laptops with local exports, imaging workstations, and the shared front-desk machine where someone saved a spreadsheet to the desktop in 2023.
- Fax and scan-to-email. Still everywhere in healthcare, still routing PHI through systems nobody inventories.
Anything the organization uses to create, receive, maintain, or transmit ePHI is in scope. That phrasing is
broader than most inventories treat it, and the gap between the phrasing and the practice is where findings
live.
Build the flows, not just the list
A flat asset list tells you what exists. It does not tell you what to worry about. Data flow tells you both.
For each system holding ePHI, capture: what enters it, what leaves it, where it goes next, who can reach it, how
that access is granted and revoked, and how long the data stays. Then trace the paths end to end.
The trace is where the surprises are. A flow that ends at "third-party analytics" needs a business associate
agreement and probably needs to stop carrying identifiers. A flow that ends at "vendor support tunnel" needs to
answer who opens it, whether it is logged, and whether it closes.
Access is a system property, not a policy statement
Once flows exist, access review becomes answerable. Not "do we have an access policy," which everyone does, but:
Does every account map to a named human or a documented service identity? How many accounts belong to people who
left? When someone changes role, does old access get removed or does new access get added on top? Are
administrative accounts separate from daily-use accounts? Does anyone review any of this on a schedule, and is
the review written down?
That last question is the one that decides whether an auditor sees a program or a policy document. A control you
perform and do not document is, for evidentiary purposes, a control you did not perform.
What this means for scale
At one location with a couple of systems, this is a spreadsheet afternoon.
Past a few sites it stops being a spreadsheet problem. Each location has its own network, its own physical
environment, its own local devices, and often its own shadow workflow that solved a real problem in a way the
central policy did not anticipate. An inventory built centrally and pushed outward will describe the intended
architecture. The SRA needs the actual one.
Which is why multi-site organizations tend to get more out of an assessment where each site is evaluated on its
own conditions and the results reconcile into a single program view. One report per site is a filing cabinet.
One program that accounts for eleven sites is a defensible position.
The order that works
- Inventory every system that creates, receives, maintains, or transmits ePHI. Go wider than feels necessary, including non-production and backup.
- Map the flows between them and out to third parties. Trace to the actual endpoint, not the intended one.
- Reconcile access against the flows. Compare granted access to used access.
- Then answer the safeguard questions, which will now be about real systems.
- Document the reasoning behind every risk rating, especially the ones you accepted.
Step five is the one that gets skipped, and it is the one that matters when someone asks why a known gap was
left open. A documented accepted risk with a rationale is a defensible decision. The same gap with no rationale
is a finding.
One clarification on timing
HIPAA requires the risk analysis. HHS has stated that the Security Rule does not specify how frequently to
perform it. Annual review is best practice and the CMS Promoting Interoperability program requires an annual
attestation, so a yearly cadence is a sound default for reasons that are real. The point worth internalizing is
that a material change to your environment matters more than the calendar. Migrate a system, acquire a
practice, or add a site, and the previous analysis is describing an architecture you no longer run.
Medcurity builds Security Risk Analysis tooling for healthcare organizations, with expert review and onsite
physical safeguard assessments where they are needed. Self-serve SRA starts at $499 per year for small
practices. More at medcurity.com.
