Why Critical-Access and Rural Hospitals Need a Healthcare-Native Security Risk Analysis

Most of the security risk analysis (SRA) tooling a rural or critical-access hospital gets pitched was not built for a hospital. It was built for a horizontal governance, risk, and compliance market — SaaS companies, fintechs, anyone chasing a SOC 2 report — and then pointed at healthcare because healthcare is where the regulatory pressure lives. For a 25-bed critical-access hospital (CAH) running a lean compliance function, that mismatch is not cosmetic. It decides whether your risk analysis survives contact with the Office for Civil Rights (OCR).

Here is the case for choosing a healthcare-native SRA over a generic GRC platform, laid out the way a compliance officer actually has to defend the decision.

What the HIPAA Security Rule requires today (and what is only proposed)

Two things are worth separating, because vendors routinely blur them.

Required now: the HIPAA Security Rule already obligates covered entities to conduct an accurate and thorough risk analysis of the confidentiality, integrity, and availability of the electronic protected health information (ePHI) they hold — 45 CFR §164.308(a)(1)(ii)(A) — and to manage the risks that analysis surfaces under §164.308(a)(1)(ii)(B). Physical safeguards across your facilities are a first-class requirement under §164.310, not an appendix. None of that is new, and none of it is optional for a hospital of any size.

Proposed, not law: in early 2025 HHS issued a notice of proposed rulemaking that would modernize the Security Rule — among other things it would, if finalized as written, tighten the cadence and specificity of the risk analysis requirement. That rule is still a proposal. Anyone telling a rural hospital it "must now" do something because of the 2026 update is describing a draft as if it were enforceable. Plan for the direction of travel; document to the standard that is in force.

The reason this distinction matters for tool choice: a healthcare-native assessment is built around the Security Rule's actual implementation specifications. A horizontal GRC tool maps to a generic control catalog and leaves you to argue, after a breach, that your crosswalk satisfied §164.308. That argument is yours to lose.

The scoping problem is worse at a hospital, and generic tools hide it

The most common — and most cited — risk analysis failure is scope. OCR's consistent position is that the analysis must cover all ePHI the organization creates, receives, maintains, or transmits, wherever it lives. At a hospital that reaches far past the electronic health record:

• Biomedical and imaging devices with embedded storage — infusion pumps, ultrasound carts, PACS
• Laboratory and pathology systems, and departmental "shadow" databases and spreadsheets
• Voicemail, fax servers, and transcription platforms
• Cloud services adopted by a single department without central IT review
• Backup media, decommissioned equipment awaiting disposal, and offsite storage

A tool designed for a software company assumes ePHI lives in a handful of cloud apps with clean APIs. It has no vocabulary for a wiring closet that doubles as a supply room at your outpatient clinic three towns over. A healthcare-native SRA starts from the assumption that ePHI is scattered across clinical, biomedical, and physical environments — and forces an asset inventory that spans them. An SRA that cannot produce that inventory is, in OCR's framing, a partial analysis, and partial is the word that appears in enforcement findings.

Physical safeguards you cannot assess from a desk

Section 164.310 — facility access controls, workstation security, device and media controls — is the requirement most often skipped in hospital SRAs, precisely because it cannot be answered from a questionnaire. Multi-campus and rural systems are the most exposed: the main hospital may have badge-controlled server rooms while a remote clinic secures its network gear behind a door that is propped open all day.

This is where the delivery model, not just the software, matters. Some assessment approaches — Medcurity's hospital engagements are one example — build an onsite §164.310 physical-safeguard assessment into the SRA, sending people to the buildings rather than scoring physical security by self-report. A pure-software GRC product cannot do that by design; it was never meant to leave the browser.

Multi-site under one engagement, not fifteen disconnected checklists

A rural health system is rarely one building. It is a hospital plus a cluster of clinics, an infusion center, maybe a couple of acquired practices — five to fifteen or more delivery sites, each generating ePHI, each a potential finding. Generic tools treat each site as a separate project or a separate license, and the compliance officer becomes the human integration layer stitching fifteen partial analyses into something that looks enterprise-wide.

Healthcare-native SRAs increasingly support multi-site assessment under a single engagement — every facility rolled into one analysis, one dashboard, one defensible enterprise picture. For a lean rural compliance team, that consolidation is often the entire difference between an SRA that gets finished and one that stalls in spreadsheet reconciliation.

Software output versus a reviewed, defensible product

OCR does not grade a hospital on whether it bought software or hired consultants. It grades the analysis on whether it was accurate, thorough, enterprise-wide, and acted upon. That standard exposes the weakness of software-only tooling: a completed questionnaire with yes/no answers and no reasoning is attestation, not analysis. Most defensible methodologies anchor to NIST — SP 800-30 for the risk-assessment mechanics, and NIST SP 800-66 Rev. 2, HHS and NIST's own guide to implementing the HIPAA Security Rule, for the mapping. The question is whether your tool merely records answers or actually demonstrates how you got from "here are our systems" to "here are our ranked risks."

The healthcare-native models worth evaluating pair guided, Security-Rule-mapped analysis with expert human review of the finished product and year-round advisory access, rather than shipping raw software output and calling it done. NIST mapping — including SP 800-66 — should be something the platform does for you, not homework it leaves on your desk.

Where a hospital should not pick Medcurity — the honest version

A comparison that always concludes "buy us" is a sales sheet, not guidance, so here is the honest boundary. If you are a large integrated delivery network (IDN) or an enterprise health system with a mature internal security organization and appetite for a heavyweight, consultant-led engagement, a firm like Clearwater — or a comparable enterprise consultancy — is frequently the better fit. That tier wants deep bespoke advisory and enterprise GRC integration, and it is a segment purpose-built consultancies serve well.

The healthcare-native, guided-SRA model is strongest exactly where the horizontal tools and the enterprise consultancies both fit worst: rural hospitals, critical-access hospitals, FQHCs, community health centers, and multi-clinic systems that need enterprise-grade rigor without an enterprise-sized compliance department. If that is you, the built-for-healthcare option is not a compromise — it is the closer match.

The checklist for choosing

However you resource it, evaluate any hospital SRA against six questions:

1. Does it force an ePHI asset inventory that spans clinical, biomedical, and physical environments — not just the EHR?
2. Does it map to the Security Rule's implementation specifications and to NIST (SP 800-30 / SP 800-66 Rev. 2), or to a generic control catalog?
3. Does it assess §164.310 physical safeguards at the facilities, or by questionnaire?
4. Can it cover every delivery site under one engagement and one enterprise view?
5. Does a named expert review the finished analysis, or does software output ship unreviewed?
6. Does it produce a living risk-management record — ranked risks, owners, target dates, progress — rather than a shelf document?

Medcurity's hospital security risk analysis is one model built around those six answers for the rural, critical-access, and multi-site segment; it is worth comparing side by side against both the horizontal GRC tools and the enterprise consultancies to see which matches your scale. Whatever you choose, choose against the standard OCR will actually apply — because the next records request grades your analysis, not your vendor's logo.

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.