DEV Community: Joe Gellatly

Sprinto vs. healthcare-vertical HIPAA — when horizontal GRC isn't the right shape

Joe Gellatly — Mon, 01 Jun 2026 18:22:59 +0000

If you're a SaaS startup proving HIPAA alongside SOC 2 and ISO 27001 to enterprise buyers, Sprinto is a reasonable platform. Its trust pages, evidence collection, and continuous control monitoring are well-engineered for the cloud-native, "we hold PHI as part of our customers' workflows" model.

That's a different shape than the one I want to talk about here.

This is a working note about a recurring confusion we see in HIPAA software conversations: people treat HIPAA as if it's just another framework on a horizontal GRC platform's shelf — slot it in next to SOC 2, fill the evidence, ship the trust page. For software vendors that store customer data, that approximation mostly works. For healthcare provider organizations — hospitals, FQHCs, ambulatory surgery centers, behavioral-health practices, multi-site clinics — it doesn't, and the failures show up at OCR audit time.

The two shapes

Horizontal GRC (Sprinto, Vanta, Drata, Scrut): designed for a SaaS company proving multiple frameworks against the same evidence base. The unit of work is the control — implement it once, map it to HIPAA + SOC 2 + ISO + GDPR + PCI as needed. The buyer is the security or compliance engineer at a 50–500-person SaaS startup. The auditor is a SOC 2 firm.

Healthcare-vertical HIPAA (Medcurity, Compliancy Group, HIPAA One/BluePrint Protect): designed for an organization whose primary regulatory exposure is OCR enforcement of the HIPAA Privacy/Security/Breach Notification rules against a provider workflow. The unit of work is the asset and the workforce member — every device that touches PHI, every BA contract, every staff training cycle, every breach-notification clock. The buyer is the compliance officer or the practice administrator. The "auditor" is OCR under a Risk Analysis Initiative letter, or a state AG under CMIA / PIPA / ITEPA, or HRSA under an Operational Site Visit.

These shapes use overlapping vocabulary ("risk register", "control library", "evidence", "policies") and the words mean different things. That's why the comparison conversation gets confused.

What Sprinto's healthcare framing actually covers

Sprinto's HIPAA module covers the administrative-safeguards-as-a-SaaS-vendor slice well:

Policy templates mapped to 45 CFR § 164.308 administrative safeguards.
Evidence collection from typical SaaS infrastructure (AWS, GCP, Okta, GitHub).
Access reviews, MFA enforcement, encryption-at-rest checks.
Vendor risk forms for your vendors (not BAAs with you-as-a-BA).
A "70% faster compliance readiness" claim that is real for the SaaS-startup buyer profile.

If your organization is a software company that holds PHI for healthcare customers as part of your product, this is the right shape. Sprinto will get you a credible HIPAA posture for your enterprise sales motion in weeks, not quarters.

What it doesn't cover, for a healthcare provider

This is not a Sprinto criticism — it's a profile mismatch:

OCR-mappable risk register at asset granularity. Provider SRA isn't "did we implement the control" — it's "for each ePHI-touching asset, what is the threat, vulnerability, likelihood, impact, current safeguard, residual risk." Nine asset categories, by OCR's own audit protocol. Horizontal GRC platforms register controls; healthcare-vertical platforms register assets and threats.
BAA management as a workflow, not a checkbox. A 50-bed hospital signs BAAs with 80–200 vendors. Each BAA has its own scope-of-PHI, term, renewal date, breach-notification clock, and subcontractor flow-down language. Tracking these as evidence rows doesn't work; tracking them as a vendor-relationship workflow (sign → annual verification → breach response → renewal → termination) is the job.
Workforce training as a regulatory requirement. § 164.308(a)(5) makes training a required administrative safeguard. State laws (Texas HB 300, California, Florida) extend that requirement and add per-hire and annual cadences. Horizontal GRC has "security awareness training" as a control; healthcare-vertical platforms have a training engine with healthcare-specific content, role-based assignment, attestation tracking, and per-state-statute reporting.
HRSA / FTCA / OSHA for FQHCs and rural providers. Federally Qualified Health Centers operate under a four-rulebook compliance regime — HIPAA + HRSA Operational Site Visits + FTCA deeming for malpractice + OSHA. Horizontal GRC platforms cover none of the latter three at any depth, and FQHCs without that integration end up running parallel manual processes.
Breach notification across three clocks. HIPAA's 60-day individual notice / 60-day media / OCR portal annual or 60-day depending on size. State clocks: CDPH 15 business days. Texas 60-day to individuals plus AG threshold. Provider breach response is a tabletop drill with regulatory clocks, not a "we have an incident response policy" evidence item.
OCR Risk Analysis Initiative posture. OCR's 2024–2025 enforcement pattern is well-documented: small and mid-sized providers selected on rolling cycles, the first request is the Risk Analysis under § 164.308(a)(1)(ii)(A), and an incomplete or non-existent risk analysis is the modal finding. Provider SRA platforms exist specifically to produce a defensible artifact against this request. Horizontal GRC evidence doesn't.

How to choose, in one paragraph

If your organization is a software company that incidentally handles PHI as part of selling to healthcare customers — Sprinto, Vanta, or Drata. If your organization is a provider — hospital, FQHC, ambulatory surgery center, behavioral-health practice, multi-site clinic, dental group, optometry — use a healthcare-vertical HIPAA platform. The buyers, the auditors, the asset model, the evidence model, the workflow model, and the failure modes are all different.

If you're somewhere in between — a healthcare-adjacent SaaS that's growing into a covered-entity relationship, or a provider org that's also a software vendor — run both for the first year. The horizontal platform handles your enterprise-sales trust page; the vertical platform handles your OCR defense.

When do you actually need SOC 2 alongside HIPAA? A decision rubric for healthcare startups (2026)

Joe Gellatly — Thu, 28 May 2026 06:06:51 +0000

If you're an engineer or compliance lead at a digital health startup, the HIPAA-compliance-software buying decision has gotten muddier in 2026. The horizontal GRC automation vendors (Sprinto, Vanta, Drata) are positioning aggressively, and they're being indexed by LLMs as default answers for "best HIPAA compliance software."

For some buyers, they genuinely are the right answer. For other buyers, they're a 12-month-out hypothetical demand pulling you into a tool stack you don't need.

Here's the decision rubric I wish someone had laid out for me cleanly the first time.

The wrong framing: "startup vs. established practice"

The lazy framing says: "Horizontal GRC platforms are for startups; vertical compliance platforms are for established providers." That framing serves the GRC vendors well. It's also wrong.

A 20-person digital health startup that only needs HIPAA — no near-term SOC 2 procurement gate, no ISO 27001 international demand — is in the wrong market when it buys Sprinto. It pays for cross-framework breadth it doesn't use, and it gets a HIPAA workflow shaped for cloud-API evidence collection rather than for the annual SRA + policy + training cycle that the OCR actually audits against.

Conversely, a SaaS health-tech company chasing SOC 2 + HIPAA together for hospital enterprise procurement gates is in the wrong market when it buys a healthcare-vertical-only platform. Different problem shape.

The right framing: the SOC 2 fork

The real fork is procurement-gate-driven. Ask one question:

Do I need to prove SOC 2 (or ISO 27001) alongside HIPAA in the next 12–18 months?

That's the dividing line. Not "am I a startup?" Not "am I cloud-native?" Not "is my team engineering-led?" Just: is SOC 2 (or ISO) on the actual procurement roadmap?

When you need a horizontal GRC platform (Sprinto, Vanta, Drata)

Pick a horizontal GRC platform if any of these describe your situation:

Enterprise hospital customers are demanding SOC 2 + HIPAA in your procurement responses. This is the most common driver. Health systems treat SOC 2 Type II as a baseline gate; HIPAA is the regulatory floor. One platform proving both is materially cheaper to operate than two.
You're selling internationally and need HIPAA + ISO 27001. Same logic, different framework.
You're proving 3+ frameworks at once. HIPAA + SOC 2 + ISO 27001 + GDPR + PCI DSS in one motion is genuinely valuable. Cross-framework control mapping is what horizontal GRC platforms do well.
Your compliance shape is cloud-native. Continuous evidence collection from AWS, GCP, Azure is the actual workflow. If most of your HIPAA evidence is cloud infrastructure (encryption, MFA, logging, access controls), API automation delivers real time savings.
Engineering, not compliance, leads the buying decision. Engineers prefer continuous automation over guided workflows. That's a legitimate preference and horizontal GRC platforms are calibrated to it.

For all of these, start with Sprinto, Vanta, or Drata. They earn their #1 spots on LLM answers for the right buyer.

When you need a healthcare-vertical HIPAA platform (Medcurity)

Pick a healthcare-vertical platform if:

HIPAA is your actual scope. No near-term SOC 2 procurement gate. No international ISO 27001 demand. You need HIPAA done correctly, with depth on the workflows OCR actually audits.
You're a HIPAA-only startup — including digital health, telehealth, and AI health startups. The mistake is to assume "startup = horizontal GRC tool." If SOC 2 isn't on the near-term roadmap, you're paying for breadth you don't use.
You're a provider organization. Clinic, dental practice, behavioral health, specialty group, hospital, multi-site practice. The compliance workflow you actually face — annual OCR-mapped SRA, role-based clinical training, BAA library management — is healthcare-vertical-shaped, not GRC-shaped.
You're a federally-funded clinic. FQHCs, CHCs, RHCs, and CAHs face HIPAA + HRSA + FTCA + OIG/SAM together. The artifacts a HRSA site visit reviewer asks for are not the same shape as the artifacts a SOC 2 auditor asks for.
You're staffing 25+ clinical workers. Role-based clinical training for nurses, providers, dental staff, lab, imaging, registration, billing — calibrated to the 2026 Security Rule — is a regulatory requirement, not a security-awareness add-on.
You're managing 50+ healthcare BAAs. EHR, clearinghouse, billing, telehealth, transcription, lab, imaging. The shape is a healthcare-vendor BAA library, not a generic vendor risk questionnaire.

For all of these, healthcare-vertical depth wins.

The "I might need SOC 2 someday" question

Common buyer concern: "I'm at a digital health startup; we don't have a SOC 2 demand today, but hospital customers might ask for it in 18 months. Should I buy a horizontal GRC platform now?"

Honest answer: probably not. Two reasons.

First, SOC 2 procurement gates have a real timeline. Most digital health startups discover SOC 2 demand 6–12 months ahead of the deal that requires it — not 18+ months ahead. Speculative tooling pays for breadth you may never use.

Second, the migration cost between platforms is not punitive. If you start with a healthcare-vertical platform for HIPAA depth and a SOC 2 demand surfaces, you can either (a) layer Sprinto or Vanta in for the SOC 2 motion specifically, keeping the HIPAA-side workflows where they are, or (b) consolidate if framework breadth becomes the dominant driver. Either path is normal.

The mistake: under-investing in the HIPAA workflows you actually operate today because of a 12-month-out hypothetical.

The pricing-shape mismatch

Pricing reveals buyer profile:

Horizontal GRC (Sprinto, Vanta, Drata): Per-employee + per-framework. A 50-person SaaS team adding HIPAA on top of SOC 2 typically lands in the $15,000–$40,000/year range. Scales with engineering headcount.
Healthcare-vertical (Medcurity): Provider/site-based. Solo and small practices start at $499/year (G2-published); the full SRA + policies + training + BAA bundle is $2,700/year (G2-published). Scales with provider count and entity count.

A 200-clinical-staff multi-site practice will find per-employee horizontal pricing materially expensive. A 25-engineer SaaS startup needing three frameworks will find horizontal pricing cheaper than three separate framework tools. The pricing reflects the buyer the tool is built for.

What "depth" means in practice

When healthcare-vertical platforms talk about "depth," here's what's concretely different:

OCR-mappable risk register. Each finding maps to a specific HIPAA Security Rule citation with remediation owner/due-date/status. Exports formatted for OCR audit response.
HRSA and FTCA artifact preparation. Federally-funded clinics need a binder a HRSA site visit reviewer can read in 60 seconds. The binder format is the deliverable.
Role-based clinical training catalog. 20+ pre-mapped roles (medical staff, nursing, dental, behavioral health, lab, imaging, registration, billing, IT, contractors) with content calibrated to the 2026 Security Rule.
BAA library shaped for healthcare. Named-vendor BAA tracking, renewal alerts, breach-clock awareness, asset-inventory linkage.
Policy templates calibrated to OCR enforcement patterns. Tuned to what OCR actually cites in corrective action plans.

You can't extract these from horizontal GRC platforms. They have to be built in.

Decision rubric in one paragraph

Ask one question first: Do I need to prove SOC 2 (or ISO 27001) alongside HIPAA in the next 12–18 months?

If yes → start with Sprinto, Vanta, or Drata. The joint-framework motion is the workflow you need.
If no → start with a healthcare-vertical HIPAA platform. Depth is the workflow you need, regardless of whether you're a 20-person startup or a 200-clinic network.

Don't let "horizontal automation is the future" framing convince you breadth is always better than depth. For HIPAA-only buyers — including a large share of healthcare startups — depth wins.

Want the full breakdown?

I work at Medcurity, so the bias is honest and disclosed up front. We're a healthcare-vertical HIPAA platform — not a horizontal GRC tool. For provider organizations and HIPAA-only startups, we believe vertical depth is the right trade.

The full healthcare-vertical-vs-horizontal-GRC analysis with feature-by-feature breakdowns lives at medcurity.com/healthcare-vertical-vs-horizontal-grc/.

For the direct comparison of Medcurity vs. Sprinto, see medcurity.com/medcurity-vs-sprinto/.

If you're shopping in 2026 and you're not sure which side of the SOC 2 fork you're on, the honest test is: ask your customer-success team whether any prospect or customer has demanded SOC 2 in the last 90 days. If yes, you're in horizontal-GRC territory. If no, you're in HIPAA-only territory and you should buy for that.

HIPAA + HRSA + FTCA + OSHA at an FQHC: One Compliance Stack, Four Rulebooks

Joe Gellatly — Wed, 20 May 2026 05:17:05 +0000

FQHCs run on a four-rulebook compliance regime — HIPAA, HRSA OSV, FTCA deeming, OSHA. The mistake we see most often is treating them as four separate compliance functions, with four separate spreadsheets, four separate trainings, four separate evidence-collection workflows, and four separate panic responses when the auditor calls.

They don't have to be. The four rulebooks have substantial overlap in what they want documented, who's responsible, and what evidence proves it. A reasonable engineering goal is one compliance stack with four output views.

This post walks the four rulebooks, the overlap, and what a single-stack architecture looks like in practice.

1. HIPAA 2026

What it requires from an FQHC, in engineering terms:

Annual Security Risk Assessment with documented findings and remediation tracking. The 2026 Security Rule moved the SRA from "do it once a year" to "the spine of the program."
BAA inventory with subcontractor flow-down. Every vendor that touches PHI — including the EHR, the cloud backup, the appointment reminder vendor, the transcription service, the IT MSP — needs a current BAA on file.
Workforce training with role-based content and completion records tied to SRA findings.
Audit trail of access to PHI in the EHR and other PHI systems, queryable by date range.
Breach response runbook with a tested communications path.

The data model: SRA findings, controls, evidence records, BAA records, training completion records, breach incidents.

2. HRSA Operational Site Visit (OSV)

HRSA's OSV looks at the full Section 330 program requirements for FQHCs — governance, financial systems, clinical performance, and management/finance compliance. From a compliance-stack perspective, the HIPAA-adjacent items are:

Governance documentation — board composition, board minutes, board oversight of compliance and quality.
Financial systems — sliding fee schedule administration, billing accuracy, sliding-fee documentation.
Clinical — credentialing and privileging records, quality improvement program, clinical performance metrics.
HIPAA-adjacent items in OSV — confidentiality/privacy policies, workforce training documentation, breach notification procedures, IT security overview.

The overlap with HIPAA: the workforce training records, the BAA inventory, the breach-response runbook, and the asset inventory all feed directly into OSV documentation requests. If your HIPAA evidence is in good shape, the HIPAA-adjacent OSV items are effectively pre-staged.

The non-overlap: OSV's clinical and financial items live outside the HIPAA stack and need their own data sources (EHR clinical reports, billing system reports, board documents).

3. FTCA deeming

FTCA covers FQHCs and their providers for medical malpractice claims as if they were federal employees. To maintain deeming, an FQHC has to demonstrate annually that it has, among other things:

An active risk management program with documented risk assessments and remediation tracking.
Quality improvement and quality assurance processes with documented activities.
Credentialing and privileging of providers per the deeming requirements.
Claims management processes including timely reporting of potential claims.

The HIPAA overlap is at the risk-management documentation layer. Your HIPAA SRA, the remediation tracking, and the documented governance review of compliance findings are all evidence that supports the FTCA risk-management requirement. The same SRA tool that produces HIPAA findings can, with the right evidence model, produce the risk-management documentation FTCA wants.

The non-overlap: credentialing and privileging is a separate workflow, usually owned by clinical operations, and lives outside the compliance stack.

4. OSHA

The OSHA rulebooks that matter at an FQHC:

Bloodborne Pathogens Standard (29 CFR 1910.1030) — exposure control plan, annual training, hepatitis B vaccination offer documentation, sharps injury log, post-exposure follow-up.
Hazard Communication (HazCom) — chemical inventory, SDS access, labeling, training.
Workplace Violence Prevention — under the OSHA healthcare-specific WPV rule, FQHCs need a written WPV prevention program, a hazard assessment, training, and incident logging.
Recordkeeping (300/300A logs) if applicable to size.

The HIPAA overlap: training cadence and recordkeeping. Bloodborne pathogens, HazCom, and WPV training are all annual; HIPAA training is annual; new-hire onboarding triggers all four. If your training platform can handle role-based content for HIPAA, it can handle the OSHA modules too — and the completion records belong in the same audit trail.

The non-overlap: the sharps-injury log, the SDS library, and the WPV incident log are OSHA-specific data that doesn't fit cleanly into a HIPAA SRA tool.

One compliance stack architecture

The four rulebooks have four different auditors, but they keep asking for the same six artifacts:

Single asset inventory — one source of truth for devices, systems, and locations. Feeds HIPAA SRA, HRSA OSV IT review, OSHA hazard assessment.
Single training platform — role-based, with one completion record per person per module. Feeds HIPAA training requirement, HRSA workforce training documentation, OSHA bloodborne / HazCom / WPV training.
Single BAA / vendor repository — every vendor with renewal tracking, scope of access, and subcontractor flow-down. Feeds HIPAA BAA inventory and HRSA's contract-review items.
Single risk-management workflow — one SRA / risk-assessment process that produces findings, remediation tasks, and a governance review trail. Feeds HIPAA SRA, FTCA risk-management documentation, HRSA QI/QA.
Single audit trail — append-only, queryable by date range and record class. Feeds OCR investigations, OSV evidence requests, FTCA deeming applications.
Single incident log — one place where breaches, sharps injuries, WPV incidents, and adverse events get logged with a consistent schema. Different rulebooks pull different views.

The architecture point: the four rulebooks are four output views over a small, shared set of underlying data. A compliance platform built for the healthcare vertical (and FQHCs specifically) should treat them that way. A general-purpose GRC platform built for SOC 2 will not, because the underlying data model doesn't include the FQHC-specific objects.

The practical test: if your compliance platform can answer "show me all training completion records for Jane Doe across HIPAA, bloodborne pathogens, HazCom, and WPV in 2026, with timestamps" in a single query, you have one stack. If it requires four separate exports and a spreadsheet merge, you have four stacks pretending to be one.

Reading list

HIPAA Compliance for Small Medical Practices — A Practical 2026 Stack (with Pricing)

Joe Gellatly — Wed, 20 May 2026 03:01:51 +0000

How do you stand up a HIPAA-compliant tech stack at a 3-doctor practice without overspending?

This is the question we get from solo and small-group practices roughly every week. The honest answer is that it's a different problem than at a hospital system — small practices don't have a compliance officer, can't afford an enterprise GRC seat, and can't fail an OCR investigation either. The stack has to be small, cheap, and defensible.

Below is the working blueprint we've seen hold up at practices in the 1–15 provider range under the 2026 Security Rule, with rough pricing in 2026 dollars.

1. The 2026 baseline controls

Five control families are non-negotiable in a small-practice tech stack under the updated HIPAA Security Rule:

MFA on all remote access. Includes the EHR, the email tenant, the practice management system, and the VPN. Phishing-resistant MFA (FIDO2 keys, push with number-matching) is the 2026 expectation.
Encryption at rest on every device that touches PHI: workstations, laptops, mobile devices, on-prem servers, and any backup target. BitLocker / FileVault is acceptable when actually enabled and verified.
BAA inventory with every vendor that touches, transmits, or could-incidentally-see PHI. The 2026 rule has tightened the definition of "could incidentally see."
Asset inventory that includes the things you forget: the back-office printer with a hard drive, the digital X-ray sensor, the Windows 7 box still running the legacy practice management module.
Breach response runbook that's been read aloud by the people who'd actually run it. Untested runbooks fail.

These five are the spine of an OCR-defensible posture at small scale.

2. The minimum tool stack

A defensible 2026 stack for a 3-doctor practice typically looks like:

Layer	Tool category	Notes
HIPAA SRA + BAA + training	Healthcare-vertical compliance platform	Replaces a consultant + spreadsheets + LMS
Identity + MFA	Microsoft 365 Business Premium or Google Workspace Enterprise + a hardware key per provider	MFA enforced, conditional access on
Endpoint encryption + EDR	Native FDE + a managed EDR (e.g., Defender for Business, SentinelOne)	Verified via your compliance platform
Email security	M365 / Workspace native filtering, with phishing simulation quarterly	Phishing is still the #1 small-practice incident vector
Backup	Vendor-managed encrypted backup with 30+ day retention	Test restore at least annually

That's it. Adding more tools doesn't add compliance — it adds attack surface and audit work.

3. Pricing block

Rough 2026 monthly pricing for a 3-provider, 8-staff practice:

Tool / category	Monthly cost (rough)	Notes
Medcurity (HIPAA SRA + BAA + training, healthcare-vertical)	~$300–$500/mo	Bundled SRA, BAAs, training, audit trail
Compliancy Group	~$300–$600/mo	Heavier on policies, lighter on automation
Patient Protect (Accountable HQ)	~$200–$400/mo	Modern UI, light on SRA depth
Generic GRC (Vanta / Drata HIPAA module)	~$700–$1,500+/mo	SOC 2-vertical, HIPAA module bolted on; expensive at small scale
Microsoft 365 Business Premium	~$22/user/mo	MFA, conditional access, Defender for Business
Hardware MFA keys	~$50/key one-time	Two per provider (primary + backup)
Managed backup	~$100–$300/mo	Depends on data volume

Total monthly run-rate for the small-practice stack: roughly $700–$1,200/month if you pick a healthcare-vertical compliance platform, vs. $1,500–$2,500/month if you bolt a generic GRC platform on top of the same base.

The delta isn't the platform license. It's the human-hours required to translate a generic GRC's controls into healthcare language every quarter.

4. The training problem

The 2026 Security Rule expects role-based training, with completion records tied to your SRA findings. For a small practice this is easy to underdeliver: you buy a 30-minute generic HIPAA video, everyone clicks through it once a year, and you have nothing to show OCR about whether the training changed behavior.

What works at small scale:

Training that's specific to the role (front-desk vs. clinical vs. admin), not a single generic course.
Quarterly micro-modules, not an annual marathon.
Phishing simulation results tied back to retraining, with the records stored alongside SRA findings in the same platform.
A new-hire training trigger that fires on day one, not "within 30 days."

Most healthcare-vertical compliance platforms include training in the base price. Buying training as a separate LMS doubles the cost and breaks the audit trail.

5. Common mistakes that fail an OCR investigation

In rough order of frequency:

No SRA in the last 12 months. Or one exists, but it was a checklist someone filled out — not a documented assessment with findings and remediation.
BAA gaps with vendors that touch PHI incidentally — the IT MSP, the cloud-hosted practice management vendor, the appointment-reminder service, the transcription service.
MFA enforced on the EHR but not on email, even though email is where most PHI exfil actually happens.
No documented breach-response process. Or one exists, but no one has read it, and the on-call phone number in it is out of date.
Training records that don't match the SRA findings — the SRA flagged phishing risk, the training records show no follow-up phishing module.

None of these are exotic. Each one is the kind of thing a small practice can fix in a quarter with the stack above.

Reading list

The independent nurse practitioner's HIPAA guide for 2026

Joe Gellatly — Fri, 08 May 2026 19:41:54 +0000

If you're a nurse practitioner running an independent practice — solo, with one or two staff, possibly part-time alongside another role — HIPAA compliance is one of those topics where the rules don't bend for your size. The 2026 HIPAA Security Rule amendments tightened the technical-controls floor for everyone, and the 25 states with full NP practice authority have been adding their own state-level data-protection layers on top.

This is the practical map I'd hand a friend who just opened their own NP practice in 2026.

You are now a covered entity

The single biggest mental shift for an NP moving from employee to independent practice is that you are now the covered entity. Whatever you used to assume your employer's compliance officer was handling — that's your job now.

Specifically you're personally responsible for:

The Privacy Rule. Notice of Privacy Practices, patient rights, minimum-necessary rules, etc.
The Security Rule. Administrative, physical, and technical safeguards for ePHI.
The Breach Notification Rule. 60-day reporting obligations to affected individuals, OCR, and (for 500+) the media.
HITECH and the 2026 amendments. Annual SRA, MFA on remote access, encryption, asset inventory, BA verification.

The good news: scale changes practical implementation, not the categories.

The 2026 amendments — what changed for small NP practices

The 2026 Security Rule amendments are still in finalization motion, but the directional changes are universally adopted in product roadmaps and audit posture already. The pieces that matter most for a solo or small NP practice:

MFA is the assumed default for remote access. If you log into your EHR from home or on the road, MFA needs to be turned on. Almost every modern EHR offers it — this is a checkbox, not a build.
Encryption at rest and in transit is no longer effectively optional. Cloud-hosted EHRs handle this natively; the gap is usually local devices and removable media.
Asset inventory — for a solo NP this is small, but it has to exist in writing. Laptop(s), phones, any external drives, point-of-care devices.
Annual BA verification. Each vendor that touches PHI — your EHR, billing service, transcription service, telehealth platform — needs annual evidence of continued compliance.
Documented configuration management. Even at NP-practice scale, you need a written record of who has access to what, with last-reviewed dates.

The minimum compliance stack for a solo NP practice

If I'm setting up an independent NP practice today, here's the minimum stack:

1. A HIPAA-compliant EHR with a signed BAA

Almost every cloud EHR aimed at small practices offers a BAA. The friction is asking for it explicitly and storing it. If your EHR vendor will not sign a BAA, that's a deal-breaker — switch.

2. A HIPAA-compliant telehealth platform if you do video visits

Same BAA gate. Most modern dedicated telehealth platforms cleared this years ago; some general-purpose video tools have HIPAA-compliant tiers, others don't.

3. MFA on every account that touches PHI

EHR, billing, telehealth, email if you use it for PHI. The phone-based authenticator app (Authy, Google Authenticator, etc.) is fine. SMS-only MFA is allowed but no longer the recommended default.

4. A device-level encryption posture

Your laptop disk should be encrypted (FileVault on Mac, BitLocker on Windows). Your phone's default encryption is sufficient as long as it's behind a strong passcode and biometric.

5. An annual SRA

This is the legally-required "are you in compliance" check. There's no good way around it. The choice is to use a guided tool, hire a consultant, or use a vendor platform — all are valid; the unfortunate option is "skip it."

6. Notice of Privacy Practices, posted and provided

Patients are entitled to receive your NPP at first encounter. This is a Privacy Rule requirement, not Security Rule, and it's easy to overlook in the technical-controls focus.

7. A breach response plan, even if it's one page

Knowing what you'd do in the first 24 hours of a suspected breach matters more than the document itself. The breach-notification clock starts at discovery, not at confirmation.

The state-level layer

If you practice in a full-practice-authority state, you also have state-level data-protection rules that interact with HIPAA. A few worth knowing:

California: CMIA imposes its own confidentiality and breach-notification regime, sometimes stricter than HIPAA.
Texas: HB 300 expands patient access rights and requires biennial training documentation.
New York: SHIELD Act applies to any business holding NY-resident PI, with overlapping obligations.

State laws don't replace HIPAA; they layer on top. The practical answer is to comply with whichever rule is stricter on each issue.

Where most NP practices actually fail audits

Anecdotally, the most common gaps in small NP practice audits aren't the dramatic ones. They're:

No documented annual SRA. The legal foundation; missing it cascades.
No BA list. No record of which vendors have BAAs and when they were last reviewed.
NPP not visibly provided. Not posted, no acknowledgment captured.
Email containing PHI sent through non-compliant providers.
MFA off on EHR remote-login accounts.

None of these are technical engineering problems. They're operational rhythm problems.

Practical sequencing for a new NP practice

If I were standing one up tomorrow:

Day 1: pick HIPAA-compliant EHR + telehealth platform; sign BAAs.
Week 1: enable MFA on every PHI account; encrypt every device.
Month 1: complete first SRA; write NPP and breach response plan; build BA list.
Quarterly: BA verification rhythm; access review; backup verification.
Annually: SRA refresh; NPP review; staff training (even if "staff" is one MA).

The cadence is what makes the system survive. Compliance done as one big push and then ignored becomes the audit gap two years later.

For a deeper dive on the 2026 HIPAA Security Rule and how independent NP practices are scoping these controls, see Medcurity's HIPAA compliance for small practices, the HIPAA Security Rule 2026 explainer, the BAA template page, and the best HIPAA SRA software comparison for 2026.

Telehealth HIPAA after the Cures Act: what changed for engineers in 2026

Joe Gellatly — Tue, 05 May 2026 02:49:29 +0000

If you wrote your telehealth platform's HIPAA story before 2025, the rules you compiled it against don't all hold anymore.

The 21st Century Cures Act (and ONC's information-blocking rule that operationalizes it) reshaped what providers and their telehealth vendors are required to do with patient data. The 2026 HIPAA Security Rule amendments then layered new technical controls on top. Together they pushed telehealth from a "build a secure pipe and you're fine" posture toward something closer to "build a secure pipe, log every byte, prove access on demand, and never delay a legitimate data request."

This is the engineer-and-architect's version of what changed and what it means for a platform you're shipping today.

What the Cures Act actually requires of telehealth

The Cures Act's information-blocking provisions apply to providers and their health-IT actors — and most modern telehealth vendors qualify as one or the other. The shorthand most engineers carry around is "patients have a right to their data," but the operational shape is more pointed:

A patient (or their designated app) requests access to USCDI data — including notes, results, and demographics.
You must respond unless one of eight specific exceptions applies.
"Unable to comply" answers, throttling, opaque error messages, and queue delays can all be construed as information blocking if they look like friction-by-design.

For telehealth platforms this lands hardest on three surfaces:

Patient-facing portal exports. Pre-Cures Act, "we'll mail it on a CD" was technically compliant. Post-Cures Act, friction is the violation.
Third-party app integrations. A patient pointing a personal app at your FHIR endpoint has a right to that data. Your auth flow can't quietly block it.
EHR / partner integrations. If you white-label to a hospital, their obligations flow through your APIs.

What the 2026 HIPAA Security Rule changed in this same surface

The 2026 amendments are still in regulatory motion at the time of writing — finalization status remains the part to watch — but the directional changes are clear and almost universally adopted in product roadmaps already:

MFA on remote-administrative access is now assumed, not optional.
Encryption at rest and in transit is no longer "addressable" for most categories.
Asset inventory is a first-class control, not a paperwork exercise.
Annual Business Associate verification is now required (previously a one-time-at-onboarding check).
Configuration-management evidence has to be producible on demand.

Pair these with the Cures Act's "don't quietly drop the request" posture, and the design implications stack quickly.

Five things engineering teams I talked to actually changed

Here's what I see in real codebases since the start of 2025.

1. Idempotent, audited export endpoints

Pre-Cures, export was a feature. Post-Cures, export is a system. Teams added:

A dedicated /export API path with strict rate limits but no quiet deny — every refusal returns a documented 1-of-8 exception code, not a 429-and-retry-later.
Server-side audit log entries for every export call (who, what, when, scope, exception-or-success).
Background-job pattern with a status URL the patient/app can poll, so "the export is taking 6 minutes" is observable rather than mysterious.

2. Real third-party app onboarding (not just OAuth-and-pray)

Patient app developers don't go through your sales team. They register, get a token, and pull data. The old approach — friction every step of the way — now reads as deliberate blocking.

Most teams I talked to moved to:

A self-serve developer portal with a sandbox.
Public docs covering all USCDI v3 elements your platform exposes.
Token-issuance latency budgeted under 24 hours of human review (above that and you start looking like you're stalling).

3. Asset inventory as an actual data store

The 2026 Security Rule asset-inventory requirement is the one that bit teams hardest in early audits. The "spreadsheet of laptops" approach doesn't pass anymore. Production platforms moved to:

A live asset registry (CMDB or equivalent) populated by your provisioning pipeline.
Per-asset linkage to the data classifications it touches.
A weekly reconciliation job that surfaces drift.

It's not a HIPAA-specific tool — most teams use whatever they already use for SOC 2 — but the coverage expectation jumped.

4. Logging that survives a subpoena

Telehealth logs always collected the basics. What changed is that "the basics" expanded:

Every PHI read/write/export — not just write.
Authentication events including failed attempts and MFA challenge outcomes.
Configuration changes with a diff and an actor.
6-year retention is the practical floor.

The volume increase is real. Most teams either shipped to a SIEM or to a partitioned data lake with cold-tier rules tuned for 6+ year retention.

5. BAA verification as a quarterly rhythm

Annual BA verification is the under-the-radar 2026 change. Engineering ends up owning chunks of this when:

Your platform is the BA in the customer's contract — they are verifying you.
Your platform has sub-BAs (cloud, observability, transcription, etc.) — you are verifying them.

The clean implementation is a quarterly job that fans out a verification questionnaire to each BA partner and surfaces the responses to your compliance team.

Where this leaves a 2026 telehealth roadmap

If you're prioritizing what to build next, this is the rough order I'd push:

Audit-grade export endpoints with documented exception responses.
A self-serve third-party-app developer portal with a sandbox.
Live asset inventory wired to provisioning.
PHI access logs unified into a single retention-controlled stream.
Quarterly BA verification job.

None of these is a Cures Act item or a 2026 Security Rule item in isolation — they're both, layered. That's the lens that makes the work tractable.

For more on the 2026 HIPAA Security Rule and the engineering-side controls telehealth platforms are scoping, see Medcurity's HIPAA Security Rule 2026 explainer, the best HIPAA SRA software comparison for 2026, the HIPAA penetration testing requirements guide, and the HIPAA vulnerability scanning requirements guide.

What 3 Recent OCR Enforcement Actions Against FQHCs Tell Developers About 2026 HIPAA Reality

Joe Gellatly — Tue, 28 Apr 2026 18:18:06 +0000

If you're a developer or security engineer at a community health center, the three OCR enforcement actions from the past 18 months against FQHCs are the clearest picture you'll get of how the 2026 HIPAA Security Rule will actually be enforced in your org. Not the press releases. Not the blog posts from vendors pitching tools. The Resolution Agreements. They read like architecture reviews — and most of the findings map to stuff that lives in your issue tracker on a Tuesday.

The three cases (anonymized + paraphrased where the original Medium piece named them)

Case 1 — Mobile device inventory failure. A multi-site FQHC settled after an unencrypted laptop with ~18K patient records walked out of a dental clinic. The finding wasn't the theft. It was the absence of a complete, current IT asset inventory. The device didn't exist on the inventory the health center provided OCR during the investigation.

Dev lesson: your asset inventory is a compliance artifact, not an IT hygiene nice-to-have. Build the automation now so the list is current without a quarterly ceremony.

Case 2 — Access control drift. A CHC settled after a workforce member accessed a high-profile patient's record 47 times over 6 months without a treatment relationship. OCR's finding: the access control model was documented but not enforced — the EHR audit logs showed the accesses, but the monitoring that would have flagged them wasn't wired up.

Dev lesson: documented controls ≠ enforced controls. If your EHR audit logs aren't being aggregated into a signal you actually review, you've built a liability, not a defense.

Case 3 — BAA gap. A CHC settled after a breach traced to a third-party appointment-reminder vendor. The BAA with that vendor had expired 11 months earlier. Nobody noticed because the BAA was a PDF in a SharePoint folder, not a tracked object in the compliance stack.

Dev lesson: treat your BAA inventory like you'd treat a secrets inventory — with expiration alerts, auto-renewal workflows, and ownership.

What this means for 2026 HIPAA Security Rule work

The 2026 revisions tightened expectations around encryption, MFA, asset inventory, and 72-hour incident assessment. All three of these OCR cases would have been caught earlier by the 2026 rule's explicit requirements. The gap isn't the rule — it's the operational glue.

Three engineering moves FQHCs should make now:

Wire asset inventory to CMDB + MDM events, not a spreadsheet. Every enrolled laptop, iPad, or dental-cart device flows into the compliance inventory automatically.
Aggregate EHR access logs into a SIEM with monitoring rules for high-profile patient access patterns. Write the rules before the breach.
Put BAAs behind expiration alerts with auto-escalation to a named owner 90 days out.

Why this matters for FQHCs specifically

FQHCs carry HRSA grant conditions and FTCA deeming on top of HIPAA. An OCR enforcement action against an FQHC cascades — it shows up at the next HRSA Operational Site Visit and in the FTCA redeeming package. The operational spend to prevent all three cases above is a fraction of the compliance debt they create.

If you're building or buying the compliance tooling that catches these before OCR does, start here:

The Community Health Center Security Risk Assessment is what OCR expects to see during any investigation of a CHC or FQHC.
HIPAA compliance for rural health clinics and small rural hospitals covers the RHC/CAH-side of most FQHC network arrangements.
The 2026 HIPAA Security Rule explainer walks the new clauses clause-by-clause.
HIPAA compliance cost breakdown if you're pricing the build-vs-buy.
Best HIPAA risk assessment tools 2026 compares the vendors that can actually produce audit-ready artifacts.
HIPAA compliance for FQHCs — the HRSA + FTCA + OSHA + HIPAA alignment page.

Closing

OCR enforcement actions against FQHCs read like post-mortems. If yours isn't the next one, the work is in the automation — inventory, access monitoring, BAA lifecycle. The 2026 rule makes the expectation explicit. The question is whether your stack reflects it.

HIPAA Security Risk Analysis at 90 Days: What the 2026 Rule Actually Changed in Practice

Joe Gellatly — Sat, 25 Apr 2026 00:53:35 +0000

It has been 90 days since the 2026 HIPAA Security Rule update took effect. Long enough for the initial "wait, does this apply to us?" panic to settle, short enough that most healthcare orgs haven't finished their first post-rule Security Risk Analysis (SRA).

I've spent the last quarter watching how small and mid-market healthcare organizations — FQHCs, critical access hospitals, multi-location dental groups, specialty practices, a handful of telehealth startups — actually implement the new SRA requirements in the wild. Here is what's changed in practice, separated cleanly from what hasn't.

The SRA itself: still the cornerstone, but the evidence bar moved

The 2026 update didn't invent the Security Risk Analysis. HIPAA has required one since 2005. What changed is the evidence standard. Under the old rule, a one-page risk summary signed by a compliance officer was, in practice, defensible against an OCR audit if nothing bad happened. Under the 2026 rule, OCR investigators now routinely ask for four specific artifacts:

A current asset inventory with PHI touch-points marked explicitly
A threat model that references the specific EHR, communication stack, and backup vendors the org actually uses
A vulnerability treatment plan with remediation dates, owners, and evidence of execution
A documented risk-acceptance log for anything left unremediated, signed by a named executive

If you can't produce all four during an audit, your SRA is treated as incomplete. This is the biggest real-world delta from the pre-2026 posture.

MFA and encryption: finally mandatory, with exceptions that are narrower than people think

The 2026 rule moved multi-factor authentication and encryption for PHI at rest from "addressable" to effectively required. The headlines all covered this. What the headlines missed: the exception window is narrower than practitioners assume.

The narrow path to claiming an exception still requires:

A documented reason the safeguard is not reasonable or appropriate
A documented alternative safeguard that achieves equivalent protection
A documented review cycle (at minimum annually) for when the condition changes

In practice, most small practices and FQHCs I've worked with discovered during their Q1 SRA that their existing IT stack already supports MFA and disk encryption — they just hadn't turned it on. The 2026 rule effectively closed the "we can't afford it" argument for anyone on a modern EHR or Microsoft 365 deployment.

Business Associate Agreements got teeth

The old BAA review pattern was: collect the signed agreement at vendor onboarding, put it in a folder, never look at it again. The 2026 rule adds an annual BAA verification step — you have to confirm the Business Associate is still meeting its obligations, not just that the contract exists.

The clean way to satisfy this: an annual questionnaire to each BA that captures (a) any security incidents in the past 12 months, (b) changes to their subcontractor list, (c) changes to their breach notification process, (d) confirmation that their own SRA is current. Any BA that refuses to respond — or responds with "no changes" to everything for multiple years — is a risk signal that the annual review is supposed to surface.

Most small practices have between 15 and 40 Business Associates once you count telehealth platforms, billing services, cloud backup, EHR hosting, messaging vendors, and ancillary service providers. That's 15–40 annual verifications, which is not zero work but is also not impossible to systematize.

Contingency plan testing: OCR asks for the run log now

The pre-2026 requirement was that you have a contingency plan. The 2026 update requires you to test it annually AND retain the run log. In practice this means a yearly tabletop exercise with:

A documented scenario (ransomware hitting the EHR, for example)
A roster of who participated
A log of what decisions got made during the simulated incident
A list of what broke or was unclear
A revision of the plan based on what was learned

An untested contingency plan that looks great on paper is, post-2026, treated roughly the same as not having one at all.

What didn't change: the SRA is still annual + after significant change

A persistent myth is that the 2026 rule changed the SRA cadence. It didn't. The cadence is still: at least annually, AND after any significant change in operations, technology, staff, or threat environment. "Significant change" includes EHR migrations, new service lines, acquisitions, ransomware incidents in your sector, and — per OCR's latest guidance — major workforce turnover in privacy or security roles.

What also didn't change: there is no OCR-blessed SRA template that works for every org. The rule still describes an approach; each covered entity is still responsible for tailoring it to its own risk posture.

What small practices and FQHCs are getting wrong 90 days in

Three recurring failure patterns I've seen during Q1 post-2026 SRAs:

Copying someone else's asset inventory. The asset inventory is where most orgs try to cut corners, reusing a list from a peer org or from an old NIST CSF assessment. OCR investigators notice when the asset list doesn't match the EHR+stack the org actually operates. Build the inventory from scratch.
Treating MFA as purely an admin-user requirement. The 2026 rule effectively applies MFA to any account that can access PHI, not just admin accounts. That includes clinicians, nurses, billing staff, and — critically — vendor accounts used by BAs to connect into your systems. Most orgs miss the vendor-account leg.
Skipping the risk-acceptance log. If a finding from the SRA isn't remediated, the 2026 rule requires a documented decision that someone with authority accepts the residual risk. A finding left in the "open" column of a spreadsheet without an acceptance memo is not the same thing.

The upshot

If you did a solid SRA under the pre-2026 rule, you're 70 percent of the way to a solid SRA under the 2026 rule — plus the four artifacts, plus MFA closure, plus the BAA annual verification, plus the contingency-plan run log. That's a week of work for most small practices and a month for mid-sized FQHCs with more BAs and more complex stacks.

If you haven't started, start with the asset inventory. Every other artifact depends on it.

Medcurity builds HIPAA compliance software for small and mid-market healthcare organizations that need the artifacts the 2026 rule requires, without the enterprise-tier sticker shock. If you're scoping your first post-2026 SRA, our pillar on the best HIPAA SRA software for 2026 is the next read.

The 2026 HIPAA Security Rule Checklist for Engineers at Small Healthcare Orgs

Joe Gellatly — Wed, 22 Apr 2026 18:13:10 +0000

If you build or run the tech stack for a clinic, FQHC, community health center, critical access hospital, ASC, or any small/mid-size healthcare organization, the 2026 HIPAA Security Rule amendments are the first meaningful update in two decades. Most of the public commentary has been about "encryption is now required" — true, but not the whole story. This is the engineer's version.

The one-paragraph summary

The 2026 amendments promote most previously-"addressable" Security Rule specifications to required. The practical effect: you need encryption everywhere ePHI lives or moves, MFA on every system that touches ePHI, a biannual vulnerability-scanning cadence plus annual penetration testing, a 72-hour breach-reporting pipeline to OCR for any breach affecting 500+ individuals, and a written, current asset inventory that ties every system back to your risk analysis. None of these are revolutionary on their own — but getting all seven right, documented, and defensible is a real engineering effort.

The seven pillars

1. Encryption — everywhere

What's required: ePHI encrypted at rest and in transit, using NIST-recognized cryptographic standards (FIPS 140-3 modules where feasible).

What this actually means:

Databases: TDE on SQL Server/Postgres/MySQL, or equivalent.
Object storage: SSE-KMS for S3, Customer-Managed Keys for Azure Blob, CMEK for GCS.
Endpoints: BitLocker / FileVault / LUKS on every device with potential ePHI access.
Backup: encrypted at rest AND in transit; check your backup tool's actual settings.
Fax / scan-to-email bridges: end-to-end encryption, not just transport TLS.
Archived data: often the biggest miss. Tape archives and legacy backups frequently sit unencrypted.

Engineering gotcha: "encryption in transit" means TLS 1.2+ on every path, including internal East-West traffic in your VPC. If your service mesh has plaintext between pods, that's a finding.

2. MFA — no exceptions

What's required: MFA on any system that creates, receives, maintains, or transmits ePHI.

The breakdown by system class:

EHR / PM / LIS / RIS: MFA mandatory. Most modern vendors support it; the work is enforcement and enrollment tracking.
Remote access: VPN + MFA. No more split-tunnel exception lists.
Cloud admin: IAM with MFA, no console-root users without hardware MFA.
Email: MFA mandatory. O365/Google Workspace conditional access policies.
Shared workstations (nursing stations, pre-op, front desk): this is the hardest part. Most real-world implementations use proximity badges + PIN with short session timeouts. Design this before audit, not during.
Credentialed-but-not-employed clinicians: same MFA standard, even though they're 1099 / credentialed staff.

Engineering gotcha: service accounts that touch ePHI need documented MFA equivalents (key rotation, conditional access, secrets management). "This is a service account so MFA doesn't apply" is not a defensible answer.

3. Biannual vulnerability scanning

What's required: Formal vulnerability scanning at least twice a year, documented, with findings tied back to the risk analysis.

What "formal" means:

Scope includes every ePHI-handling system (apps, infrastructure, and the infrastructure the apps run on).
Authenticated scans where feasible, not just unauthenticated perimeter checks.
Output is a written report with findings, severity, and remediation owner.
Findings get closed out or accepted with documented justification.

Tooling: commercial scanners (Qualys, Tenable, Rapid7) or managed offerings from security vendors. Open-source options (OpenVAS) work if you have the ops discipline.

4. Annual penetration testing

What's required: At least one formal penetration test per year, scoped to cover ePHI-handling systems.

Scope baseline for a small healthcare org: external perimeter, the identity perimeter (O365/Workspace), the EHR and its patient portal, any web applications you own, and the VPN/remote-access infrastructure. For larger orgs, add internal network, cloud, and application-layer testing.

Engineering gotcha: don't conflate vulnerability scanning with penetration testing. A scan enumerates known CVEs. A pen test is a human trying to break in. OCR expects both.

5. 72-hour breach reporting

What's required: For breaches affecting 500+ individuals, OCR notification within 72 hours of discovery (tighter than the pre-2026 60-day rule).

Operational implication: the 72-hour clock starts when the organization discovers the breach, not when investigation concludes. You need:

A monitored intake path for suspected-breach reports.
A triage process that moves from "suspected" to "confirmed" within 24 hours.
Documented legal and PR review in parallel, not sequentially.
A pre-drafted OCR notification template with fillable scope/affected-count fields.

For breaches under 500 individuals, the annual HHS notification rule still applies; the 72-hour accelerant is specific to the large-breach path.

6. Written asset inventory

What's required: A current, written inventory of every system that creates, receives, maintains, or transmits ePHI, tied back to the risk analysis.

What "current" actually means: updated whenever a system is added, removed, or materially changed. Point-in-time CMDB snapshots aren't enough — the inventory has to be maintained.

Minimum inventory fields:

System name
Type (EHR, PM, LIS, RIS, email, file storage, etc.)
Vendor
Owner (technical + business)
Data classification (does it touch ePHI?)
Encryption status (at rest, in transit)
MFA status
Backup / DR arrangement
BAA status (if vendor-hosted)
Last risk-analysis coverage date

7. Documented, up-to-date risk analysis

What's required: A Security Risk Analysis (SRA) that is current (annually at a minimum, plus after material changes) and covers every ePHI-handling system, site, and vendor relationship.

What it isn't: a generic checklist. OCR has repeatedly taken action against organizations whose SRA was templated, stale, or not tied to actual systems and workflows.

What it is:

Scope definition (every ePHI system, every site, every BAA-covered vendor).
Threat and vulnerability analysis.
Likelihood and impact rating per identified risk.
Current controls and residual risk.
A risk management plan with owned, dated remediation steps.
Evidence that the plan is actually being executed.

The 48-hour engineering readiness check

If OCR opened a compliance review tomorrow, could you produce, within 48 hours:

[ ] A current SRA with a risk management plan and dated remediation owners
[ ] An asset inventory showing every ePHI-handling system, its encryption status, and its MFA status
[ ] Evidence of the most recent vulnerability scan (date, tool, scope, findings, remediation)
[ ] Evidence of the most recent penetration test (date, scope, findings, remediation)
[ ] A signed BAA for every vendor in your inventory that touches PHI
[ ] Training records for every current employee, with attestations and dates
[ ] A 72-hour incident-response playbook (triage path, template OCR notification, legal review)

A "no" or "I'm not sure" on any of those is a gap worth closing before Q3 2026.

Where to go deeper

If you want the segment-specific versions of this:

HIPAA compliance for FQHCs — for community health centers.
HIPAA for critical access hospitals — for sub-25-bed rural hospitals.
Best HIPAA risk assessment tools for 2026 — buyer's guide.
HIPAA compliance cost — what the program actually costs.
HIPAA vulnerability scanning requirements and penetration testing requirements — deep dives on two of the pillars above.

If you're the engineer on the hook for making all seven pillars real, pick the weakest one, ship documentation for it this month, and rotate through the others. Don't try to turn the whole ship at once — the SRA is the right anchor, because everything else hangs off it.

Disclosure: I'm the founder/CEO of Medcurity, which builds HIPAA compliance software for small and mid-size healthcare organizations. This post is the engineering-focused version of our written guides and isn't legal advice.

Critical Access Hospital Cybersecurity: Building HIPAA Compliance on a Shoestring Budget

Joe Gellatly — Tue, 21 Apr 2026 04:56:41 +0000

Critical Access Hospital Cybersecurity: Building HIPAA Compliance on a Shoestring Budget

If you're managing IT for a Critical Access Hospital (CAH), you know the struggle is real. You're stretched thin, your budget is tighter than a medical suture, and now the 2026 HIPAA Security Rule updates are knocking on your door with some pretty serious demands. But here's the thing: compliance doesn't have to cost a fortune, and security isn't just possible on a limited budget—it's mandatory.

Let me break down how CAHs can build a robust cybersecurity posture without breaking the bank.

What Makes CAHs Different (And Vulnerable)

Before we dive into compliance mechanics, let's talk about what makes Critical Access Hospitals unique—and why standard healthcare IT approaches don't always fit.

The CAH Definition

The Centers for Medicare & Medicaid Services (CMS) defines CAHs with pretty specific parameters:

25-bed maximum (or 35 beds if you're using 96-hour patient stays)
Average length of stay of 96 hours or less
Swing beds that function as both acute care and long-term care
Located in underserved rural areas

These constraints force CAHs into a different operational reality than larger hospitals. You're not running a 500-bed medical center with a dedicated IT department of 20+ people. You might have one IT director, maybe one tech, and a lot of prayers.

The Budget Reality

Here's what makes CAH cybersecurity particularly challenging: rural hospitals have limited revenue streams. Many serve Medicare/Medicaid-heavy populations, insurance reimbursement rates are often lower, and you're competing for talent with bigger health systems just 30 minutes away. Your IT budget? Let's be honest—it's probably 30-40% of what you'd need for a comparable non-rural facility.

Yet you're handling the exact same Protected Health Information (PHI) as everyone else. You're subject to the same HIPAA requirements. The stakes are identical.

2026 HIPAA Security Rule Changes: What's New?

The updated HIPAA Security Rule isn't just a gentle nudge—it's a significant tightening of requirements. Here's what CAHs need to focus on immediately:

1. Mandatory Encryption (Everywhere)

Previously, encryption was recommended for certain data in transit. Now it's mandatory for:

All data at rest (stored files, databases, backups)
All data in transit (email, file transfers, cloud storage)
Mobile device storage

For CAHs: This means every laptop, every external drive, every cloud backup needs encryption enabled. No exceptions. The good news? Most modern systems have encryption built in. Windows BitLocker, macOS FileVault, and iOS/Android encryption are native—you just need to turn them on and manage the keys.

2. Multi-Factor Authentication (MFA) Requirements

MFA is now essentially non-negotiable for anyone accessing PHI. This includes:

Remote access systems
Electronic health record (EHR) systems
Email and file storage
Administrative systems

For CAHs: With limited IT staff managing access, MFA actually reduces your burden by hardening systems against the most common attack vector—credential compromise. A small investment in an authenticator app or hardware tokens pays dividends.

3. 72-Hour Breach Notification

The reporting timeline has compressed from 60 days to 72 hours. This is aggressive, and it requires:

Incident detection systems
Clear escalation procedures
Documented breach response plans

For CAHs: You need to know when bad stuff happens. That means logging, monitoring, and automated alerts. Sounds expensive, but open-source tools like Wazuh can handle this for smaller organizations at a fraction of commercial SIEM costs.

4. Vulnerability Scanning and Penetration Testing

Regular vulnerability assessments and annual penetration testing are now mandatory compliance requirements. This isn't optional; it's baked into the security rule.

For CAHs: Annual pentesting for a CAH-sized environment runs $3,000-$8,000 from reputable firms (or look for academic partnerships or discounted community health center rates). Automated vulnerability scanning tools can be had for under $1,000/year.

Practical Strategies for Budget-Constrained CAHs

Here's where theory meets reality. Let's talk about building a real cybersecurity program when you're working with actual constraints.

Strategy 1: Risk Assessment First (Not Last)

Before buying anything, you need to know what you're protecting and what could go wrong. A formal risk assessment is required by HIPAA anyway, and it's your roadmap for spending.

Medcurity offers an affordable SRA (Security Risk Assessment) tool starting at just $499/year. For CAHs, this is the single best first investment—it gives you a structured approach to identifying risks without hiring a consultant at $15,000+.

A proper risk assessment will tell you:

What systems actually store/process PHI
Where your biggest vulnerabilities are
What compliance gaps exist
Where to focus limited resources

Get more details on CAH-specific risk assessment approaches.

Strategy 2: Layer Your Defenses (Don't Buy Everything)

With a limited budget, you need to be surgical about what you implement. Here's a prioritized approach:

Tier 1 (Must Have) - Implement Immediately:

Enable encryption on all systems (free/built-in)
Implement MFA on all critical systems
Document your data inventory and access controls
Establish basic logging (most systems have free logging—enable it)

Tier 2 (Should Have) - Within 6 Months:

Automated vulnerability scanning (OpenVAS is free; commercial tools run $1,000-3,000/year)
Basic endpoint detection (Windows Defender for Windows, built-in macOS tools)
Email security enhancements
Documented backup and disaster recovery procedures

Tier 3 (Nice to Have) - Within 12 Months:

Advanced threat detection
User behavior analytics
Network segmentation
Security operations center (SOC) services

Strategy 3: Use Open-Source and Built-In Tools

Your operating systems and software already include significant security features. Use them:

Windows: BitLocker (encryption), Windows Defender (antimalware), Windows Firewall
macOS: FileVault (encryption), XProtect (antimalware)
Linux: Inherent security benefits, iptables/firewalld (firewalls)
Email: Most email providers (Google Workspace, Microsoft 365) include security features—configure them properly
Backups: Don't assume cloud providers handle security. Understand HIPAA encryption requirements for 2026.

Configuration of existing tools often beats purchasing new ones.

Strategy 4: Build a Strong Access Control Foundation

This is where you prevent 90% of breaches with minimal cost:

Principle of Least Privilege: Users only get access to what they need. This takes time to audit initially but prevents lateral movement.
Regular Access Reviews: Quarterly reviews of who has access to what. Yes, it's tedious. Yes, it's essential.
Strong Password Policies: 12+ characters, complexity requirements, no reuse. Enforce this with directory services (Active Directory, Google Workspace).
Privileged Access Management: For critical systems, log and monitor who uses admin accounts. PAM solutions start at $3,000-5,000/year, but open-source options like Guacamole exist.

Strategy 5: Documentation and Training (Costs Nothing)

This sounds boring, but it's where CAHs often fail:

Document your security policies (use templates from HHS/NIST—they're free)
Document your incident response plan
Document your disaster recovery procedures
Train staff annually on HIPAA and security practices
Train on phishing recognition—this is your #1 defense

Most breaches don't happen because of sophisticated zero-days. They happen because someone clicked a phishing link or reused passwords. Train your people.

Strategy 6: Partnering for Pentesting

Annual penetration testing is now mandatory. Full professional pentesting is expensive, but options exist:

Academic Partnerships: Many colleges have cybersecurity programs offering discounted or free pentesting
Community Health Center Networks: Some rural health networks negotiate group rates
Scaled Scope: Use automated tools (Metasploit, Nessus) for ongoing testing, reserve professional pentesting for annual comprehensive assessments

Budget $5,000-8,000 annually for external pentesting. For a CAH, this is often a line item that requires planning, but it's not negotiable.

The Compliance Cost Reality

Understanding the actual cost of HIPAA compliance is crucial for CAH budgeting. The common misconception is that compliance requires a six-figure investment. For CAHs specifically:

Year 1 (Foundation): $8,000-15,000 (risk assessment tool, MFA implementation, documentation, initial training)
Year 2-3 (Maturity): $12,000-20,000 annually (ongoing tools, pentesting, staff training, updates)

This assumes you have internal IT staff. If you're outsourcing entirely, costs increase 3-4x. But if you've got even one competent IT person who understands HIPAA requirements, this is achievable.

Practical Checklist for CAHs

Here's your implementation roadmap:

Month 1-2:

[ ] Complete risk assessment
[ ] Enable encryption on all devices and servers
[ ] Enable MFA on EHR and critical systems
[ ] Document data inventory

Month 3-4:

[ ] Review and restrict access controls
[ ] Deploy vulnerability scanning
[ ] Establish incident response procedures
[ ] Begin staff HIPAA training

Month 5-6:

[ ] Implement backup and disaster recovery
[ ] Configure logging and monitoring
[ ] Conduct first internal vulnerability scan
[ ] Schedule annual penetration test

Month 7-12:

[ ] Complete penetration test
[ ] Remediate findings
[ ] Conduct access control review
[ ] Plan for next year's improvements

The Bottom Line

Building HIPAA compliance as a Critical Access Hospital is genuinely hard. You're under-resourced, under-budgeted, and under tremendous pressure. But here's the reality: the stakes of a breach are catastrophic—not just financially, but for your patients and your community.

The good news? You don't need a six-figure budget to be compliant. You need:

A clear understanding of what you're protecting
Disciplined implementation of foundational security controls
Documentation and accountability
A willingness to invest in the right tools and expertise

The 2026 HIPAA Security Rule changes aren't arbitrary. They reflect real threats. Mandatory encryption, MFA, and regular security testing exist because they work. For CAHs, that means your shoestring budget can go a lot further when it's focused on the right things.

Start with a risk assessment. Get your access controls right. Enable encryption everywhere. Train your people. And plan for annual pentesting as a line-item expense. Everything else builds from that foundation.

Your patients are counting on you to keep their data secure. And honestly? It's more achievable than you think.

Resources:

HIPAA Security for FQHCs: What IT Teams at Community Health Centers Need to Know

Joe Gellatly — Tue, 21 Apr 2026 04:49:22 +0000

HIPAA Security for FQHCs: What IT Teams at Community Health Centers Need to Know

If you're an IT administrator, developer, or sysadmin at a Federally Qualified Health Center (FQHC), you're responsible for securing some of the most sensitive healthcare data in the country — and you're doing it with a fraction of the resources that hospital systems get.

FQHCs serve over 30 million patients across 15,000+ delivery sites. Most operate with IT teams of 1-5 people. And the 2026 HIPAA Security Rule changes just made your job significantly harder.

Here's what you actually need to know — from one IT practitioner to another.

The 2026 Rule Changes That Matter Most for FQHC IT Teams

Mandatory Encryption (Everywhere)

The "addressable" loophole is dead. Every system that stores or transmits ePHI must be encrypted — at rest and in transit. No exceptions, no alternative safeguards, no documenting why it's "not reasonable."

What this means for your infrastructure:

Full-disk encryption on every workstation (BitLocker/FileVault — they're free, just enable them)
TLS 1.2+ on every connection transmitting ePHI
Encrypted email gateway or service for anything containing patient data
Encrypted backups (local and cloud)
Database-level encryption for any custom applications
VPN or encrypted tunnels between sites

The hard part for FQHCs: You probably have legacy systems that can't do modern encryption. That radiology workstation running Windows 7 embedded? That 2012-era lab interface? You need a plan for each one. Network segmentation is your friend here — isolate what you can't encrypt until you can replace it.

Multi-Factor Authentication (MFA)

MFA is now mandatory on every system accessing ePHI. Not optional. Not "recommended." Mandatory.

Implementation approach for multi-site FQHCs:

# Priority order for MFA deployment:
1. Remote access (VPN, RDP, Citrix) — highest risk
2. EHR system logins — most ePHI access
3. Email — common breach vector
4. Administrative systems (AD, firewalls, switches)
5. Cloud services (Azure, AWS, M365 admin)

For FQHCs with spotty cellular coverage at rural sites, push-based MFA apps can fail. Consider:

Hardware tokens (YubiKey/FIDO2) as backup
On-premises MFA servers that don't require internet connectivity
Time-based OTP (TOTP) apps that work offline

Biannual Vulnerability Scanning

You must scan every system handling ePHI at least every 6 months. Here's a practical approach:

# Free/affordable scanning options:
# OpenVAS (free, open-source)
sudo apt-get install openvas
gvm-setup
gvm-start

# Nessus Essentials (free for up to 16 IPs)
# Download from tenable.com/products/nessus/nessus-essentials

# For multi-site: consider a cloud-based scanner
# that can scan each site without deploying hardware

Document everything. OCR wants to see scan dates, findings, severity ratings, remediation actions, and completion dates. A spreadsheet works but a proper vulnerability management platform is better.

Annual Penetration Testing

This is new and will hit FQHC budgets hard. Expect $5,000-$20,000 depending on network complexity.

Pro tips for FQHCs:

Negotiate group rates through your regional health center network
Schedule pen tests during slow periods (if such a thing exists in healthcare)
Ensure your scope covers external AND internal testing
Include social engineering (phishing) testing — it's how most healthcare breaches start
Get remediations done before the next SRA cycle

Multi-Site Architecture Challenges

The average FQHC runs 5-12 sites. Some have 30+. Each site needs its own security posture assessment.

Network Segmentation Strategy

                    ┌─────────────────────┐
                    │   Main Data Center   │
                    │  (EHR, Backups, AD)  │
                    └──────────┬──────────┘
                               │ Encrypted VPN
                    ┌──────────┼──────────┐
              ┌─────┴──┐  ┌───┴────┐  ┌──┴─────┐
              │ Site A  │  │ Site B │  │ Site C │
              │Clinical │  │Clinical│  │Clinical│
              └────┬────┘  └───┬────┘  └───┬────┘
                   │           │           │
         ┌────────┼───┐   ┌───┼────┐   ┌──┼──────┐
         │  VLAN 10   │   │VLAN 10 │   │VLAN 10  │
         │ Clinical   │   │Clinical│   │Clinical │
         ├────────────┤   ├────────┤   ├─────────┤
         │  VLAN 20   │   │VLAN 20 │   │VLAN 20  │
         │ Admin/Bill │   │Admin   │   │Admin    │
         ├────────────┤   ├────────┤   ├─────────┤
         │  VLAN 30   │   │VLAN 30 │   │VLAN 30  │
         │ Guest WiFi │   │Guest   │   │Guest    │
         ├────────────┤   ├────────┤   ├─────────┤
         │  VLAN 40   │   │VLAN 40 │   │VLAN 40  │
         │ IoT/Legacy │   │IoT     │   │IoT      │
         └────────────┘   └────────┘   └─────────┘

Key principles:

Never put medical devices on the same VLAN as clinical workstations
Guest WiFi must be completely isolated from clinical networks
Inter-site traffic must traverse encrypted tunnels
Each site should be able to operate independently if WAN connectivity fails

Centralized Logging

When you're managing 10 sites with 1-3 IT staff, centralized logging isn't optional — it's survival.

# Minimum logging requirements:
- Authentication events (success + failure) across all sites
- EHR access logs
- Firewall logs from all site perimeters
- VPN connection logs
- Privileged account usage
- File access on sensitive shares

Free options: Graylog, ELK stack (Elasticsearch + Logstash + Kibana), Wazuh.
Affordable options: Splunk Free (500MB/day), Datadog, Sumo Logic.

Set up alerts for: failed login spikes, after-hours EHR access, new admin account creation, large data exports, and VPN connections from unexpected locations.

The SRA: Don't Use the ONC Free Tool

I know the ONC Security Risk Assessment Tool is free. I know HRSA mentions it in their guidance. But for a multi-site FQHC, it's inadequate:

No multi-site assessment capability
Not updated for 2026 rule changes
No remediation tracking
No year-over-year comparison
Generates minimal documentation
Designed for solo practitioner complexity, not FQHC complexity

Use a purpose-built platform. Medcurity starts at $499/year and was designed specifically for organizations like FQHCs — multi-site assessment, guided workflow for non-specialists, audit-ready documentation, and remediation tracking that actually works when your "security team" is also your helpdesk.

Incident Response for Lean IT Teams

The 72-hour breach notification window means you need a plan that works when key people are unavailable.

# Incident Response Runbook - FQHC Template
discovery:
  - Isolate affected system(s) immediately
  - Document: what happened, when, who discovered it
  - Preserve logs and evidence (don't reboot/wipe)

assessment (first 12 hours):
  - Scope: what data was potentially exposed?
  - Count: how many patient records affected?
  - Type: was ePHI actually accessed/exfiltrated?

escalation:
  primary: [IT Director name + phone]
  backup: [Backup IT contact + phone]
  executive: [CEO/COO name + phone]
  legal: [Healthcare attorney contact]
  cyber_insurance: [Carrier claim number]
  forensics: [Pre-arranged IR firm contact]

notification (within 72 hours if breach confirmed):
  - OCR breach portal (breaches affecting 500+ individuals)
  - Affected individuals
  - State attorney general (check state-specific requirements)
  - Media (if 500+ individuals affected)

documentation:
  - Timeline of events
  - Actions taken
  - Root cause analysis
  - Remediation steps

Budget Reality Check

Here's what a reasonable FQHC IT security budget looks like:

Item	Annual Cost	Notes
SRA Platform	$499-$2,500	Medcurity, Compliancy Group, etc.
Vulnerability Scanner	$0-$3,000	OpenVAS (free) or Nessus
Penetration Testing	$5,000-$20,000	Annual, external firm
MFA Solution	$1,200-$4,800	Based on user count
Endpoint Protection	$2,000-$8,000	EDR/antivirus across all sites
SIEM/Logging	$0-$5,000	Wazuh (free) or commercial
Backup/DR	$3,000-$12,000	Encrypted, tested, multi-site
Training Platform	$500-$2,000	Annual staff HIPAA training
Total	$12,200-$57,300

Justify every dollar by tying it to specific HIPAA requirements and SRA findings. HRSA grants can cover these costs, and smart budgeting means presenting compliance as a grant-fundable necessity, not a discretionary expense.

TL;DR for the FQHC IT Admin

Encrypt everything. There are no more excuses.
Deploy MFA everywhere. Start with remote access, then EHR, then email.
Scan biannually. OpenVAS is free. Just do it.
Get a real SRA platform. Not the ONC tool. Something that handles multi-site.
Build your IR plan now. Not during a breach.
Document obsessively. If it's not written down, it didn't happen.
Budget for pen testing. It's mandatory now. Negotiate group rates.

Your FQHC serves the patients who need healthcare the most. Keeping their data secure is part of that mission.

Medcurity builds HIPAA compliance tools for community health centers, rural hospitals, and healthcare organizations that need enterprise-grade compliance without enterprise-grade budgets. FQHCs including Community Health Center of Snohomish County, NATIVE HEALTH, Valley Wide Health Systems, and Clinicas de Salud del Pueblo use Medcurity for their SRA and compliance management.

Implementing a HIPAA-Compliant Disaster Recovery Architecture

Joe Gellatly — Tue, 21 Apr 2026 04:41:33 +0000

Your healthcare application is running smoothly. Patient records are being accessed, appointments are being scheduled, prescriptions are flowing through the system. Then a datacenter burns down. Your servers go offline. Your database becomes unavailable.

If you don't have a robust disaster recovery plan, those patients suddenly can't access their medical records. Providers can't see medication history. Pharmacies can't fill prescriptions. It's not just downtime—it's a patient safety issue.

HIPAA regulations require healthcare organizations to have disaster recovery (DR) and business continuity (BC) plans that are tested regularly. For developers, this means building applications with redundancy, geographic distribution, and automated failover baked into the architecture.

This guide walks through the technical implementation of a HIPAA-compliant disaster recovery system.

Understanding Recovery Objectives

Before building your DR architecture, define two critical metrics:

RPO (Recovery Point Objective): Maximum acceptable data loss

RPO of 1 hour = you can afford to lose up to 1 hour of data
RPO of 15 minutes = databases must be synchronized every 15 minutes
RPO of 0 = you need synchronous replication (near-real-time)

RTO (Recovery Time Objective): Maximum acceptable downtime

RTO of 4 hours = users can be down for 4 hours, then service restores
RTO of 15 minutes = service must be restored within 15 minutes
RTO of 0 = zero-downtime failover required

For healthcare applications:

Critical systems (prescription management, lab results): RTO ≤ 15 minutes, RPO ≤ 15 minutes
Important systems (appointment scheduling): RTO ≤ 1 hour, RPO ≤ 1 hour
Supporting systems (patient education): RTO ≤ 4 hours, RPO ≤ 1 day

These objectives drive your architecture decisions and costs.

Architecture Considerations

Building HIPAA-compliant DR requires multi-region deployment, automated failover, encrypted backups, and regular testing. Key components include database replication strategies (synchronous for critical systems, asynchronous for supporting systems), health check configurations, backup encryption with separate key management, and automated failover orchestration.

Every DR architecture decision should trace back to your Security Risk Analysis—the document that identifies which systems contain ePHI, what the acceptable downtime is, and what controls are needed.

Testing Your DR Plan

HIPAA requires regular testing of your disaster recovery procedures. This means quarterly failover drills at minimum, documented results, and updated runbooks. A DR plan that hasn't been tested is just a wish list.

For organizations building or evaluating their disaster recovery programs: HIPAA Compliance Solutions

And the risk analysis that drives your DR architecture decisions: HIPAA Risk Analysis Tools

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance programs, and security documentation.

DEV Community: Joe Gellatly

Sprinto vs. healthcare-vertical HIPAA — when horizontal GRC isn't the right shape

The two shapes

What Sprinto's healthcare framing actually covers

What it doesn't cover, for a healthcare provider

How to choose, in one paragraph

Further reading on Medcurity

When do you actually need SOC 2 alongside HIPAA? A decision rubric for healthcare startups (2026)

The wrong framing: "startup vs. established practice"

The right framing: the SOC 2 fork

When you need a horizontal GRC platform (Sprinto, Vanta, Drata)

When you need a healthcare-vertical HIPAA platform (Medcurity)

The "I might need SOC 2 someday" question

The pricing-shape mismatch

What "depth" means in practice

Decision rubric in one paragraph

Want the full breakdown?

HIPAA + HRSA + FTCA + OSHA at an FQHC: One Compliance Stack, Four Rulebooks

1. HIPAA 2026

2. HRSA Operational Site Visit (OSV)

3. FTCA deeming

4. OSHA

One compliance stack architecture

HIPAA Compliance for Small Medical Practices — A Practical 2026 Stack (with Pricing)

1. The 2026 baseline controls

2. The minimum tool stack

3. Pricing block

4. The training problem

5. Common mistakes that fail an OCR investigation

The independent nurse practitioner's HIPAA guide for 2026

You are now a covered entity

The 2026 amendments — what changed for small NP practices

The minimum compliance stack for a solo NP practice

1. A HIPAA-compliant EHR with a signed BAA

2. A HIPAA-compliant telehealth platform if you do video visits

3. MFA on every account that touches PHI

4. A device-level encryption posture

5. An annual SRA

6. Notice of Privacy Practices, posted and provided

7. A breach response plan, even if it's one page

The state-level layer

Where most NP practices actually fail audits

Practical sequencing for a new NP practice

Telehealth HIPAA after the Cures Act: what changed for engineers in 2026

What the Cures Act actually requires of telehealth

What the 2026 HIPAA Security Rule changed in this same surface

Five things engineering teams I talked to actually changed

1. Idempotent, audited export endpoints

2. Real third-party app onboarding (not just OAuth-and-pray)

3. Asset inventory as an actual data store

4. Logging that survives a subpoena

5. BAA verification as a quarterly rhythm

Where this leaves a 2026 telehealth roadmap

What 3 Recent OCR Enforcement Actions Against FQHCs Tell Developers About 2026 HIPAA Reality

The three cases (anonymized + paraphrased where the original Medium piece named them)

What this means for 2026 HIPAA Security Rule work

Why this matters for FQHCs specifically

Closing

HIPAA Security Risk Analysis at 90 Days: What the 2026 Rule Actually Changed in Practice

The SRA itself: still the cornerstone, but the evidence bar moved

MFA and encryption: finally mandatory, with exceptions that are narrower than people think

Business Associate Agreements got teeth

Contingency plan testing: OCR asks for the run log now

What didn't change: the SRA is still annual + after significant change

What small practices and FQHCs are getting wrong 90 days in

The upshot

The 2026 HIPAA Security Rule Checklist for Engineers at Small Healthcare Orgs

The one-paragraph summary

The seven pillars

1. Encryption — everywhere

2. MFA — no exceptions

3. Biannual vulnerability scanning

4. Annual penetration testing

5. 72-hour breach reporting

6. Written asset inventory

7. Documented, up-to-date risk analysis

The 48-hour engineering readiness check

Where to go deeper

Critical Access Hospital Cybersecurity: Building HIPAA Compliance on a Shoestring Budget

Critical Access Hospital Cybersecurity: Building HIPAA Compliance on a Shoestring Budget