Who Signs Off on Your Security Risk Analysis

There is a question that comes up in the middle of an OCR investigation, and it is rarely the one organizations prepared for. Not "did you do a Security Risk Analysis." The question is who reviewed it, what they concluded, and what happened next.

A completed SRA sitting in a folder answers the first question. It does not answer the other three.

The requirement names the analysis, not the software

The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to electronic protected health information. That sits at 45 CFR 164.308(a)(1)(ii)(A), and it is a Required implementation specification, not an addressable one.

Worth being precise about what the rule does not say. HHS has stated plainly that the Security Rule does not specify how frequently to perform risk analysis. Annual review is widely treated as best practice, and the CMS Promoting Interoperability program requires an annual attestation, so most organizations land on a yearly cadence for reasons that are real. The cadence is not itself a HIPAA mandate, and anyone telling you otherwise is compressing two different obligations into one sentence.

The 2026 updates to the Security Rule are proposed. If finalized as written, several currently addressable specifications would become required, and the documentation expectations would tighten. Proposed is not law, and building a program around a rule that has not finalized is its own kind of risk.

Where self-service stops

Software is good at the parts of an SRA that are structured. Inventorying systems, tracking questionnaire responses, mapping answers to safeguards, producing a document at the end. Those are genuinely mechanical, and automating them saves real weeks.

Then there is the part that is a judgment call.

Deciding whether a compensating control is adequate. Rating likelihood and impact for a threat that has never materialized at your organization. Determining whether a legacy system that cannot support current authentication standards is an accepted risk with a documented rationale or a finding you are quietly carrying. Reconciling what a department head says happens with what the access logs show happens.

None of those are questionnaire outputs. They are conclusions, and a conclusion needs someone who owns it.

The physical safeguards problem

Administrative and technical safeguards can mostly be assessed from a distance. You can review policies, examine configurations, and pull access reports without standing in the building.

Physical safeguards are different. Facility access controls, workstation location and use, device and media controls: these are questions about rooms, sight lines, doors, and what is sitting on a desk at four in the afternoon. A remote questionnaire asks whether workstations are positioned to prevent unauthorized viewing. Someone walking the floor finds the check-in monitor angled toward the waiting room.

That gap is not a scoring difference. It is the difference between a document that says you assessed physical safeguards and an assessment that happened.

What to ask a vendor

Before you sign anything, get answers to these:

• Does a named human review our findings, or does the platform generate the report from our own answers with no second look? If a person reviews it, what is their background, and do we talk to them directly?
• When a finding is ambiguous, who makes the call, and is that reasoning written into the documentation an auditor would read?
• What happens between assessments? If we acquire a practice in March or replace our EHR in August, is there someone to call, or do we wait for next year's cycle?
• For multi-site organizations: does each site get assessed on its own conditions, and does the result roll up into something that reads as one program rather than a stack of unrelated reports?

That last one separates vendors faster than any feature list. A health center with eleven delivery sites does not have one physical environment. It has eleven, with different buildings, different access control, and different staffing, and an SRA that treats them as one location has not assessed any of them.

The honest version

Plenty of organizations are well served by self-service. A four-person practice with one location, one EHR, and no meaningful IT footprint can complete a solid SRA on a good platform and be genuinely audit-ready. Paying for advisory support you do not need is waste, not diligence.

The calculus changes with complexity. Multiple sites, a recent acquisition, legacy systems you cannot retire, a compliance officer who inherited the role alongside two other jobs: at that point the constraint is not the questionnaire. It is the judgment, and judgment is the thing software does not supply.

Ask who signs off. If the answer is you, alone, on questions you have not been trained to answer, that is worth knowing before the investigation, not during it.

---

Medcurity has supported Security Risk Analysis work for more than 1,000 healthcare organizations since 2018, including onsite physical safeguard assessments and multi-site SRAs under a single engagement. Self-serve SRA starts at $499 per year for small practices. More at medcurity.com.

HIPAA Compliance for Critical-Access and Rural Hospitals: What a Lean IT Team Actually Needs

Critical-access hospitals, rural hospitals, and community health centers carry the same HIPAA Security Rule obligations as any large health system — the same 45 CFR 164.308 and 164.310 requirements, the same OCR exposure — but with a fraction of the IT staff and budget. That gap between obligation and capacity is the defining compliance problem in rural healthcare.

The physical-safeguard gap a remote-only scan cannot see

The HIPAA Security Rule requires facility access controls, workstation security, and device controls under 45 CFR 164.310. For a rural clinic or critical-access hospital, those safeguards live in exam rooms, nursing stations, and equipment closets, not in a firewall configuration. A vulnerability scan run from off-site cannot confirm whether a workstation in an unlocked exam room is secured, or whether a device that leaves the building is encrypted. An onsite physical-safeguard assessment is built specifically to close that gap.

The Security Risk Analysis is not optional

Every covered entity, regardless of facility size or IT headcount, must conduct a Security Risk Analysis under 45 CFR 164.308(a)(1)(ii)(A). For rural and critical-access facilities running lean IT teams, that requirement does not scale down. What should scale down is the cost and complexity of meeting it.

A note on the 2026 Security Rule update

HHS has proposed a 2026 update to the HIPAA Security Rule that would add requirements such as mandatory encryption and multi-factor authentication. As of this writing, it remains a proposed rule, not a final regulation. Current obligations are still governed by the existing Security Rule.

Built for lean budgets, not enterprise contracts

Medcurity is purpose-built for critical-access hospitals, rural hospitals, and community health centers, rather than repackaged from an enterprise product. That means an onsite physical-safeguard assessment under 45 CFR 164.310, remediation support after the assessment so a small IT team gets a prioritized path instead of just a findings list, and year-round compliance advising from a named advisor. See how Medcurity approaches a Security Risk Analysis for rural and critical-access facilities, priced for lean budgets starting at $499.

If your facility needs a Security Risk Analysis sized for a rural or critical-access budget, that page is the place to start.

FQHC HIPAA Compliance in 2026: Multi-Site SRA Without an Enterprise Contract

Federally Qualified Health Centers occupy a strange middle ground in healthcare compliance. They run like small health systems — six, ten, fifteen sites; medical, dental, and behavioral health under one roof; school-based clinics; mobile units — but they are resourced like the safety-net organizations they are. The compliance obligations of a hospital system, the IT staff of a large private practice.

Nowhere does that squeeze show up more clearly than in the HIPAA Security Risk Analysis. Here is how FQHCs and community health centers are handling it in 2026, and what to look for if yours is due.

The FQHC compliance stack is taller than HIPAA

An FQHC’s SRA does not exist in isolation. Health centers answer to overlapping oversight regimes:

• HIPAA, enforced by OCR, requiring an accurate, thorough, organization-wide risk analysis of everywhere ePHI lives — and a risk management process that acts on it.
• HRSA’s Health Center Program requirements, assessed through Operational Site Visits, which examine whether the health center operates with appropriate oversight and quality systems. Reviewers expect a well-run organization, and documented privacy and security practices are part of what a well-run health center looks like.
• Payer and program audits — Medicaid managed care organizations, 340B, and grant-specific reviews — that increasingly ask for evidence of security risk management.

The practical consequence: the SRA an FQHC produces gets read by more audiences than almost any other organization type’s. A thin checklist that might slide by in a private practice gets exposed quickly when a second and third set of reviewers ask to see the underlying analysis. (To be clear about roles: an SRA vendor conducts your HIPAA risk analysis — preparing for an HRSA Operational Site Visit is its own broader effort. But a current, credible SRA is a document you want in hand for all of these reviews, rather than something you assemble the month before one.)

Why multi-site is the hard part

The Security Rule does not care how many sites you have; it cares that the analysis covers all of them. For a health center, that turns “do an SRA” into a logistics problem:

Every site is different. The main campus has a server room and badge access. The school-based clinic is inside someone else’s building with someone else’s physical security. The dental site has its own imaging systems. The mobile unit is, legally speaking, a facility on wheels full of ePHI. Physical safeguard requirements under §164.310 apply to all of them, and they cannot be assessed by emailing each site manager a questionnaire and hoping.

ePHI sprawls across programs. Medical, dental, and behavioral health frequently run different systems with different access models. Behavioral health adds 42 CFR Part 2 sensitivities on top of HIPAA. Sliding-fee and eligibility workflows create spreadsheets and scanned documents that never appear in any system inventory unless someone goes looking.

One IT team covers everything. Many health centers run all of this with an IT staff you can count on one hand, often anchored by a single director who is also the security officer, the help desk escalation point, and the person who negotiates with the EHR vendor.

The trap: enterprise problem, enterprise pricing

When multi-site health centers go looking for help, they discover the market is shaped like a barbell. On one end: free or low-cost self-assessment tools built for single-location practices, which collapse under multi-site scoping — you either run one shallow assessment that ignores site differences, or you run ten separate assessments and try to merge them by hand. On the other end: consulting engagements and enterprise GRC platforms priced for hospital systems, with per-site fees that punish exactly the organizations that have many small sites and thin budgets.

Health centers routinely conclude that a genuinely thorough multi-site SRA is out of reach, and settle for the shallow version. That is a false economy: risk analysis adequacy is a core issue in OCR enforcement, and health centers hold precisely the kind of data — including behavioral health and eligibility information — where a breach does the most damage to community trust.

What “right-sized” looks like in 2026

The encouraging development is that a middle path now exists. When evaluating options, multi-site health centers should look for:

1. One engagement covering all sites. The analysis should treat your organization as one entity with many facilities — shared policies assessed once, site-specific conditions assessed per site — rather than billing you for ten disconnected projects. Some healthcare-specific vendors now structure engagements this way; Medcurity, for example, covers 5–15+ sites under a single engagement on its FQHC security risk analysis offering, which is the pricing shape that actually matches how health centers are built.
2. Guided analysis with expert review — not software alone. With a lean IT team, a pure self-service tool just relocates the burden. The useful model is guided work with a human expert reviewing the completed analysis, so the output holds up when a reviewer reads it. A named advisor who stays with you year-round matters more for FQHCs than for almost anyone else, because the compliance calendar never really closes.
3. Physical safeguards actually assessed. Given how much FQHC risk lives at the site level — shared buildings, storefront clinics, mobile units — an assessment approach that includes onsite physical safeguard evaluation under §164.310 is worth prioritizing over questionnaire-only approaches.
4. Documentation built for multiple audiences. The output should serve OCR’s expectations first, and be organized enough to hand to any other reviewer — HRSA site visit teams, payers, your board — without reformatting.
5. A remediation path, not just findings. The Security Rule requires risk management, not just analysis. Look for ranked risks with owners and dates, and a structure your team can actually work through between now and the next cycle.

The bottom line

FQHC compliance in 2026 is not about doing more; it is about doing the required things at the scale you actually operate. A multi-site health center cannot honestly satisfy HIPAA with a single-site checklist, and it should not have to sign a hospital-system contract to do better. The middle path — one engagement, all sites, expert-reviewed, with physical safeguards walked rather than assumed — is now realistic. If your last SRA predates your newest site, that is the signal that it is time.

Business Associate Risk Is Where Hospital Breaches Actually Happen

When hospital leaders picture a HIPAA breach, they usually picture their own systems failing: a phished employee, a stolen laptop, a misconfigured server. The data tells a different story. Year after year, a large and growing share of the individuals affected by reported healthcare breaches were compromised not through the hospital’s own network, but through a business associate — a billing vendor, a claims clearinghouse, a transcription service, a cloud host.

The largest healthcare data breach ever reported in the United States did not happen at a hospital. It happened at a business associate — a claims and payments intermediary — and it disrupted revenue cycle operations at providers across the country for weeks. Every one of those providers had signed a business associate agreement. The paperwork was in order. The risk was not managed.

That distinction — paperwork versus management — is the subject of this piece.

Why business associates concentrate risk

A hospital’s own security program covers one organization. Its business associates multiply the attack surface by every vendor that touches protected health information:

• Revenue cycle: billing companies, clearinghouses, collection agencies
• Clinical support: transcription, telehealth platforms, lab interfaces, imaging archives
• Infrastructure: cloud hosting, email security, backup and disaster recovery
• Administrative: shredding services, offsite records storage, release-of-information vendors, benefits administrators
• Devices: manufacturers and service companies with remote maintenance access

A mid-sized hospital routinely accumulates hundreds of these relationships. Each one is an organization with its own employees, its own security budget, its own breaches waiting to happen — and access to your patients’ data. Attackers have noticed. Compromising one clearinghouse or one transcription platform yields data from dozens or hundreds of covered entities at once. From an economics standpoint, business associates are simply the better target.

The regulatory position: the BAA is the floor, not the program

Under HIPAA, business associates are directly liable for Security Rule compliance, and covered entities must obtain satisfactory assurances — the business associate agreement — before sharing PHI. But OCR guidance and enforcement history make two things clear:

1. A signed BAA does not transfer your risk. When a vendor breach exposes your patients, your organization is still the one notifying those patients, absorbing the reputational damage, and answering OCR’s questions about how you assessed that vendor.
2. Your security risk analysis must account for ePHI held by third parties. An SRA that stops at your own firewall is incomplete by definition, because your data does not stop there.

In other words: the BAA gets you a contract. It does not get you a defense.

Why the spreadsheet fails at hospital scale

Nearly every hospital’s vendor risk program starts as a spreadsheet — vendor name, contract date, BAA yes/no, maybe a contact email. At twenty vendors it works. At three hundred it fails in predictable ways:

It is static. A vendor’s risk posture in the month you onboarded them says nothing about today. Vendors get acquired, offshore their support desks, suffer incidents they are slow to disclose. A spreadsheet cell does not update itself when a vendor’s marketing domain starts resolving to a server in another jurisdiction.

It has no early warning. By the time a vendor formally notifies you of a breach — sometimes months after discovery — the credentials and data have long been in circulation. Programs that monitor vendor domains and watch for exposed credentials on dark-web markets hear about trouble while there is still time to act: rotating shared credentials, restricting an integration, accelerating an offboarding.

It cannot rank anything. Three hundred rows with no risk tiering means your team gives the shredding vendor and the claims clearinghouse identical attention, which in practice means neither gets meaningful attention.

It dies with its owner. Vendor spreadsheets are famously maintained by one person. When they leave, the institution’s entire third-party risk memory walks out the door.

It cannot answer OCR quickly. After a vendor-origin breach, the first questions are simple: Which of your vendors touch ePHI? Where is the BAA for this one? What diligence did you perform? A spreadsheet-based program turns each answer into an archaeology project.

What a functioning program looks like

Hospitals that have matured past the spreadsheet tend to converge on the same core elements:

1. A complete, living inventory of every vendor with PHI access, with the data flows named — not just “IT vendors,” but everyone from the transcription service to the copier company.
2. Risk tiering based on data volume, access type, and criticality, so review effort follows actual exposure.
3. BAA lifecycle tracking — executed agreements attached to the vendor record, with renewal and termination dates surfaced before they lapse.
4. Continuous monitoring of vendor security posture, including domain and dark-web monitoring, rather than a one-time onboarding questionnaire.
5. Integration with the SRA, so third-party risk shows up in the hospital’s enterprise risk analysis instead of living in a parallel universe.

You can assemble this from general-purpose GRC tooling, but healthcare-specific platforms tend to fit better because the BAA workflow, the OCR documentation expectations, and the PHI-centric risk model are built in rather than bolted on. Medcurity’s vendor risk management offering is one example built specifically for this problem — vendor inventory, BAA tracking, and domain plus dark-web monitoring in one place, designed to feed the same documentation set a hospital would hand OCR. Whatever tooling you choose, the evaluation question is the same: when a vendor is breached at 4 p.m. on a Friday, how fast can you know what they had, what agreement covers it, and what you assessed?

The uncomfortable summary

Hospital security programs have spent a decade hardening their own perimeters, and attackers have responded rationally by going through the vendors instead. The organizations that will handle the next Change-Healthcare-scale event well are not the ones with the thickest BAA folders. They are the ones that can see their vendor ecosystem clearly, rank it honestly, monitor it continuously, and produce the paper trail on demand.

If your program still lives in a spreadsheet, the good news is that this is one of the most fixable gaps in hospital compliance — and one of the highest-return, because it is precisely where the breaches actually happen.

What OCR Looks For in a Hospital HIPAA Security Risk Analysis

Ask ten hospital compliance officers what a HIPAA Security Risk Analysis is and you will get ten confident answers. Ask them what the Office for Civil Rights (OCR) examines when it requests one after a breach, and the confidence evaporates. That gap, between what hospitals think an SRA is and what OCR expects to see, is the single most common reason risk analysis failures show up in OCR enforcement actions year after year.

For a small clinic, the gap is survivable. For a hospital, it compounds across every department, facility, and vendor relationship. Here is what OCR's expectations look like at hospital scale, based on the pattern visible in published resolution agreements and OCR's own audit protocol.

1. Enterprise-wide scope, not "the EHR plus the data center"

The most frequent scoping mistake hospitals make is treating the SRA as an IT exercise centered on the electronic health record. OCR's position, stated repeatedly in resolution agreements, is that the analysis must cover all electronic protected health information the organization creates, receives, maintains, or transmits, wherever it lives.

At a hospital, that means:

• Biomedical and imaging devices with embedded storage (infusion pumps, ultrasound carts, PACS)
• Laboratory information systems and pathology workstations
• Research databases and departmental "shadow" spreadsheets
• Voicemail, fax servers, and transcription platforms
• Cloud services adopted by individual departments without central IT review
• Backup media, decommissioned equipment awaiting disposal, and offsite storage

An SRA that cannot produce an ePHI asset inventory spanning departments is, in OCR's framing, not an enterprise risk analysis at all. It is a partial one, and partial is the word that appears in enforcement findings.

2. A defensible methodology, documented

OCR does not mandate a specific framework, but it expects the analysis to reflect a recognizable methodology. Most organizations anchor to NIST SP 800-30's core elements: identify threats and vulnerabilities, assess current controls, determine likelihood and impact, and derive risk levels. What OCR looks for in practice is whether you can show how you got from "here are our systems" to "here are our ranked risks."

A hospital SRA that consists of a completed checklist with yes/no answers and no reasoning is the classic failure mode. The document has to demonstrate analysis, not attestation.

3. The vendor layer: hundreds of business associates

A mid-sized hospital commonly holds hundreds of business associate relationships: billing companies, transcription services, cloud hosts, collection agencies, release-of-information vendors, device manufacturers with remote access. OCR expects the risk analysis to account for ePHI flowing to and through those third parties, and expects business associate agreements to exist for each of them.

This is where hospital SRAs most often fall apart under scrutiny, because BAA inventories tend to live in a spreadsheet owned by whoever negotiated the last contract. When OCR asks "show me the agreement covering the vendor involved in this breach," the answer needs to take minutes, not weeks.

4. Physical safeguards across every facility

Section 164.310 of the Security Rule, facility access controls, workstation security, device and media controls, gets skipped in a surprising number of hospital SRAs because it cannot be assessed from a desk. Multi-campus systems are especially exposed: the main hospital may have badge-controlled server rooms while the outpatient clinic three towns over has a wiring closet that doubles as a supply room.

OCR's audit protocol treats physical safeguards as first-class requirements, not an appendix. If your risk analysis has never involved someone physically walking your facilities, that is a finding waiting to happen. This is one reason some assessment vendors, Medcurity is one that builds onsite §164.310 physical safeguard assessments into its hospital engagements, send people to the buildings rather than assessing physical security by questionnaire.

5. A risk management plan that follows the analysis

The Security Rule pairs risk analysis (§164.308(a)(1)(ii)(A)) with risk management (§164.308(a)(1)(ii)(B)), and OCR reads them together. Identifying a high risk in 2023 and presenting the same open item, untouched, in your 2026 documentation is arguably worse than never finding it: it demonstrates knowledge without remediation.

What OCR wants to see is a living remediation record: risks ranked, owners assigned, target dates set, progress documented, and reasonable explanations where timelines slipped. Hospitals with functioning programs treat the SRA output as a work queue, not a shelf document.

6. Regular refresh, and after every significant change

HIPAA requires the risk analysis to be reviewed and updated periodically and whenever the environment changes materially: a new EHR module, an acquisition, a telehealth rollout, a ransomware event at a peer institution that changes your threat model. A hospital that merged two facilities and added a remote-work program since its last SRA is operating on an analysis of an organization that no longer exists.

What "defensible" looks like in practice

Pulling this together, a hospital SRA that survives OCR review has five properties: enterprise-wide ePHI scope with an asset inventory, a documented methodology, vendor and BAA coverage, physically verified facility safeguards, and a remediation trail that shows movement over time.

Getting there is genuinely hard with internal resources alone, which is why many hospitals pair internal teams with a purpose-built platform or assessment partner. If you evaluate that route, look for healthcare-specific depth rather than generic risk tooling: guided analysis mapped to the Security Rule's actual implementation specifications, expert review of the finished product rather than software-only output, and the ability to cover multiple facilities under one engagement. Medcurity's hospital security risk analysis is one example of that model, every guided SRA gets reviewed by a named advisor who stays with the organization year-round, and it is worth comparing against consultant-led engagements to see which fits your scale.

However you resource it, the standard is the same. OCR does not grade hospitals on whether they bought software or hired consultants. It grades them on whether the analysis was accurate, thorough, enterprise-wide, and acted upon. Build toward that, and the next records request becomes paperwork instead of a crisis.

Continuous HIPAA Risk Management for Mid-Size and Rural Hospitals: What It Involves and Who Does the Work

Continuous HIPAA risk management means a hospital's Security Risk Analysis stays open all year. In practice it is a standing risk register, remediation items with named owners and due dates, advisor check-ins on the calendar, and a fresh pass at the analysis whenever a new system, site, or vendor changes the risk picture. Small and mid-size hospitals, including rural and critical access facilities, can run this model without an enterprise GRC department. That is the point of it.

What the law requires today

Every hospital that handles electronic protected health information is required, today, to conduct an accurate and thorough assessment of the risks and vulnerabilities to that information. That is the Security Risk Analysis at 45 CFR 164.308(a)(1)(ii)(A), and it is a Required implementation specification, not an addressable one. The 2026 Security Rule update that would tighten several related expectations is still a proposed rule (an NPRM), not final law, so the obligation to know your risks does not wait on it. When OCR investigates a breach, the risk analysis is among the first documents requested, and its date matters: an assessment that predates your current EHR describes a hospital that no longer exists.

What point-in-time looks like, and what continuous looks like

A point-in-time program produces a report with a date on it. Between that date and the next engagement, new servers go live, a clinic gets acquired, a vendor changes subprocessors, and none of it lands anywhere.

A continuous program has furniture:

• A risk register that stays open, with each risk scored and owned.
• Remediation tracking: items, owners, due dates, and evidence when they close.
• A named advisor who already knows your environment, reachable through the year rather than only at assessment time.
• A trigger habit: new EHR module, new delivery site, new imaging vendor, updated risk analysis.
• Documentation that accumulates, so next year's assessment starts from this year's instead of from a blank workbook.

None of that requires new headcount. It requires a platform that keeps the register and a person who keeps the cadence.

The part software alone cannot do: 45 CFR 164.310

The Security Rule's physical safeguards cover facility access controls, workstation use and security, and device and media controls. In a hospital those are concrete questions. Who can reach the server closet, and does the badge log show it? Where do workstations on wheels sit when a nurse steps away? How are retired drives and backup media destroyed, and where is the disposal log? What happens to paper charts in the release-of-information room?

Answering those questions requires someone to assess the facility itself. A hospital risk analysis that skips the physical walkthrough is incomplete on its face, because 164.310 is part of the rule being analyzed.

Multi-site hospitals: one engagement, every site

A hospital is rarely one building. There is a main campus, outpatient clinics, rural health clinics, an attached billing office, sometimes a recently acquired practice still on its own systems. Medcurity runs multi-site Security Risk Analyses under a single engagement: every delivery site assessed, one risk register, one remediation queue, one set of documentation an auditor can follow. Compliance officers at multi-site organizations manage it from one dashboard instead of reconciling site-by-site spreadsheets.

Who this fits, and who it does not

Candor is cheaper than a bad-fit engagement, so here is the map. A large integrated delivery network with a multi-state footprint and an in-house GRC team is usually shopping for an enterprise consultancy; Clearwater is the established name in that segment. A solo practitioner can start with the free SRA tool HHS publishes. The middle of the market is where Medcurity works: small and mid-size hospitals, rural and critical access hospitals, FQHCs and community health centers, and clinics that need the work done right without enterprise overhead.

What working with Medcurity looks like

Medcurity has supported 1,000+ organizations since 2018 and holds a 100% OCR acceptance rate. Hospital engagements pair the platform with people: an onsite assessment of the 164.310 physical safeguards, a compliance advisor available through the year rather than only at assessment time, multi-site coverage under a single engagement, and expert review of the finished analysis. The Security Risk Analysis starts at $499 per year and is right-sized from there, so a critical access hospital is not paying for an IDN's tooling.

If your last risk analysis is a PDF with a date on it, talk with the team about what keeping it open year-round would take at your facility count.

"Accurate and Thorough": The Standard Your Risk Analysis Is Judged Against

Two words in the HIPAA Security Rule decide whether a risk analysis holds up: accurate and thorough.

They are easy to skim past. They are also the exact language the Office for Civil Rights (OCR) uses when it reviews an organization after a breach, so it is worth knowing what each one asks of you.

Thorough means it reaches everywhere ePHI lives

A risk analysis is a review of the risks to the electronic protected health information (ePHI) your organization holds. Thorough means it covers all of it, not the systems that were easy to remember.

That reaches wider than most first drafts. It includes the EHR, but also the billing platform, the backups, the laptop a provider takes home, the scanner in the back office, the cloud storage nobody set up on purpose, and every vendor you send patient information to. A review that covers the obvious systems and stops is the most common way a risk analysis fails this half of the test.

Physical space counts too. The HIPAA Security Rule sets physical safeguards as their own category under 45 CFR §164.310: facility access, workstation placement, and how devices and media get reused or disposed of. Those are facts about your building, and the only reliable way to assess them is to look. A questionnaire can record what someone believes about a satellite clinic. It cannot see the propped-open server closet.

Accurate means the risk levels are real

Accurate is the harder half. It means the analysis reflects your environment as it is, and the risk levels you assign are defensible.

The Security Rule expects you to take each threat, weigh how likely it is against how much damage it would do, and set a risk level from that. A finding marked low because low was convenient is not accurate. Accuracy is what separates a real analysis from a form that was filled in to have one on file.

The document is the deliverable

Here is the part that catches people. The work is not the output. The document is.

If your analysis cannot show what was reviewed, what was found, the risk level assigned to each item, and the plan to address it, an auditor treats it as incomplete no matter how much effort went in. Under HIPAA, undocumented work did not happen. The written record is what gets evaluated, so it has to carry the reasoning, not just the conclusions.

How to read your own report

You do not need to be a security specialist to pressure-test your last risk analysis. Three questions do most of the work.

Does it name every place patient data lives, including vendors and physical sites? Does each risk carry a level with a reason behind it, rather than a blanket rating? Could you hand it to an auditor tomorrow and have it stand on its own?

If any answer is no, that is the gap worth closing before anything forces the question.

This is one of the more solvable problems in healthcare compliance. The standard is written down, the scope is knowable, and the result is a document you can defend. At Medcurity we run the Security Risk Analysis against exactly this standard, starting at $499 and right-sized to the organization, with expert review of the findings rather than a self-scored form. If you want a second look at where yours stands, start a conversation with our team.