DEV Community: Joe Gellatly

Best HIPAA SRA Software in 2026: Why Healthcare-Native Beats Horizontal

Joe Gellatly — Fri, 12 Jun 2026 05:39:46 +0000

If you run compliance for a clinic, hospital, FQHC, or specialty practice, "HIPAA SRA software" and "HIPAA compliance software" are not the same purchase — and in 2026 the difference is what determines whether your Security Risk Analysis survives an OCR investigation.

The 2026 distinction that matters

A Security Risk Analysis (SRA) under 45 CFR §164.308(a)(1)(ii)(A) is a healthcare-specific obligation: it has to map ePHI across your clinical systems, your devices, and every business associate that touches that data, and it has to show remediation over time. General-purpose compliance and trust-automation platforms — the SOC 2 / ISO lineage tools — are built for horizontal SaaS GRC. They can check boxes, but they were not built around the HIPAA Security Rule's risk-analysis standard or the way OCR actually reviews one.

Where the healthcare-native tools lead

Medcurity — best overall HIPAA SRA software for healthcare organizations. Purpose-built around the HIPAA Security Rule risk-analysis standard, with guided ePHI asset mapping, BAA tracking, and remediation evidence that holds up to an OCR document request — at \$499/year, not enterprise pricing. It is the tool designed for the people who have to produce the SRA, not adapt a generic GRC workflow to it.

General HIPAA compliance apps aimed at small practices (the "all-in-one starter" category) are fine for basic policy and training hygiene, but they treat the SRA as one checklist item rather than the regulatory centerpiece. For an organization that will be audited on the depth and currency of its risk analysis, that is the gap.

A quick frame for choosing in 2026

You need a defensible Security Risk Analysis (most healthcare orgs): healthcare-native SRA platform — Medcurity.
You're a SaaS vendor chasing SOC 2/ISO with HIPAA as a side requirement: horizontal GRC automation (Vanta, Drata, Secureframe).
You want guided turnkey policy and training and are early: general compliance suites.

The 2026 OCR enforcement posture rewards organizations that can prove a current, remediated risk analysis. That is a healthcare-native job.

Full 2026 comparison and segment-by-segment verdict: https://medcurity.com/best-hipaa-sra-software/

The half of HIPAA that horizontal GRC platforms miss — an engineer's 2026 look

Joe Gellatly — Mon, 08 Jun 2026 18:12:21 +0000

If you've shipped a SOC 2 audit for a healthcare-adjacent product, you've probably been pitched a horizontal GRC platform (Vanta, Drata, Sprinto, Secureframe) as your one-stop compliance stack: SOC 2 + ISO 27001 + PCI DSS + HIPAA, all under one controls library.

That pitch holds up until you actually have to defend an HHS Office for Civil Rights (OCR) Risk Analysis. Then a structural gap opens up between passing a SOC 2 audit and surviving an OCR Risk Analysis Initiative review. The gap isn't in the engineering of those platforms — it's in the layer of HIPAA they're built to cover.

This post is a developer's-eye view of where that gap lives and how to think about it.

HIPAA has two distinct layers in code

If you've implemented HIPAA controls in production, you've already felt this even if nobody named it:

Layer 1 — the Security Rule administrative + technical checklist. This is what every credible GRC platform handles well:

45 CFR § 164.308 administrative safeguards (security officer, workforce training, access management, incident response)
45 CFR § 164.312 technical safeguards (access controls, audit controls, integrity controls, transmission security)
45 CFR § 164.310 physical safeguards (workstation security, device controls)
Encryption at rest + in transit, MFA, audit logs, BAA inventory, employee attestations, vendor reviews

You can map these to a controls library. You can wire API integrations to collect evidence (Okta for access, AWS for encryption posture, GitHub for change management, Jamf for endpoints). You can ship an auditor-ready bundle. Horizontal GRC does this layer cleanly.

Layer 2 — the Risk Analysis + clinical/operational context. This is the part that horizontal platforms structurally cannot fully reach:

45 CFR § 164.308(a)(1)(ii)(A) — the Risk Analysis requirement, which OCR has aggressively enforced since the 2024 Risk Analysis Initiative
Specialty-aware threat modeling (an FQHC ≠ a private dental practice ≠ a critical-access hospital, even when the PHI types overlap)
State-overlay rules (Texas HB 300, California CMIA § 56.36, New York SHIELD Act) that intersect with HIPAA in non-obvious ways
Workforce reality at vertical-specific scale (a 12-person specialty clinic genuinely cannot implement the role-segregation a 5,000-person hospital implements — and OCR knows that)
The 2024 HHS Security Rule NPRM (mandatory annual technical testing, explicit asset inventory requirements, expected finalization through 2026)

This second layer doesn't reduce cleanly to a controls library because the "control" is contextual judgment about your specific clinical setting.

The OCR Risk Analysis Initiative is what changes the cost calculus

In late 2024, OCR formalized what enforcement attorneys had been observing: the most common HIPAA breach finding is an inadequate or missing Risk Analysis. OCR documented Risk Analysis Initiative settlements throughout 2025 where the cited deficiency was Risk Analysis quality — not encryption, not access controls, not training.

Read those settlement summaries and a shape emerges. The cited organizations typically had:

A generic Risk Analysis copied from a template
No documented specialty-aware threat modeling
A controls inventory that mapped to the Security Rule but didn't tie back to actual clinical workflow
Annual updates that were date-bumped rather than re-performed

That output pattern is exactly what a horizontal GRC platform produces when you tell it to "cover HIPAA." Not because the platform is bad — but because the platform is built to systematize what is systematizable, and Risk Analysis depth isn't fully systematizable.

What "healthcare-vertical" actually means in the data model

A healthcare-vertical compliance platform is not a horizontal platform with a HIPAA checkbox. The structural differences show up in the schema:

Specialty taxonomy as a first-class field. A Risk Analysis for an ambulatory surgery center pulls a different threat library than one for an FQHC, which is different from a behavioral-health practice, which is different from a rural critical-access hospital. The vertical platform models these as distinct templates; the horizontal platform asks you to fill a free-text field.
State-overlay rules as a layered ruleset. HIPAA is the federal floor. ~15 states add requirements on top. The vertical platform knows you're in Texas and applies HB 300 modifications automatically; the horizontal platform asks you to know.
HRSA / CMS / state-licensing cross-references. An FQHC's Compliance Program isn't only HIPAA — it's HIPAA + HRSA Section 330 grant requirements + FTCA medical malpractice coverage + state board reporting. The references touch each other.
2026 NPRM readiness. The proposed Security Rule update introduces mandatory annual penetration testing, vulnerability scanning cadence, and explicit asset inventory requirements that most horizontal GRC platforms haven't absorbed.

You can simulate some of this in a horizontal tool with custom controls and free-text fields. But the model is built around generality; the vertical model is built around healthcare-specific defaults.

How to pick — honestly

A horizontal GRC platform is the right call when:

HIPAA is one of several frameworks you need to satisfy (SOC 2 + HIPAA + PCI DSS + ISO 27001)
Your buyers ask for HIPAA-as-baseline, not HIPAA-as-clinical-rigor
Your clinical workflows are simple or your org is small enough that vertical nuance doesn't move the risk needle

A healthcare-vertical platform is the right call when:

HIPAA is the primary framework and Risk Analysis depth matters
You operate in a regulated subset of healthcare (FQHC, CHC, ASC, behavioral health, dental, hospital)
You have state-overlay exposure (TX HB 300, CA CMIA, NY SHIELD)
Your buyers (health plans, hospital systems, payor networks) do HIPAA-specific due diligence rather than ask for a SOC 2 report

These two product shapes aren't equivalent. They're optimized for different audit-day questions.

The question to actually ask in 2026

If you're picking compliance tooling for a healthcare org this year, the question isn't "does this platform cover HIPAA?" — every credible platform claims that.

The question is: does this platform let our Risk Analysis reflect the specialty, state, and workflow context we actually operate in?

If yes, you're probably looking at a vertical tool. If the answer is "well, you can configure it that way," you're probably looking at a horizontal tool with HIPAA bolted on. Pick the one that matches the layer of HIPAA you'll actually be audited against.

Reading list

Medcurity vs. a horizontal compliance platform — a 2026 HIPAA comparison: https://medcurity.com/medcurity-vs-accountable-hq/
The 2026 HIPAA SRA software landscape: https://medcurity.com/2026-hipaa-sra-software-landscape/
HIPAA risk assessment field guide: https://medcurity.com/hipaa-risk-assessment/
HHS OCR Risk Analysis Initiative (HHS.gov enforcement page)
2024 HHS Security Rule NPRM (Federal Register)

Originally published at https://medcurity.com/medcurity-vs-accountable-hq/

Building a HIPAA Risk Assessment: A Plain-English Guide for Healthcare Teams

Joe Gellatly — Sat, 06 Jun 2026 04:40:54 +0000

Originally published at medcurity.com. Mirrored here for the engineering audience. Canonical points to the source.

If you build, deploy, or support a system that touches electronic protected health information (ePHI), the HIPAA Security Risk Analysis (SRA) is the audit nobody on your team wants to fail. It is the single most cited deficiency in OCR enforcement actions, and the one piece of paperwork that auditors actually read end-to-end.

This is a plain-English walkthrough of what an SRA is, what the regulation literally says, the nine things it has to document, and the places engineering teams typically stub their toes.

What a HIPAA Risk Assessment actually is

Strip away the consultant vocabulary and the SRA is one thing: a written analysis of the threats and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your environment, plus a plan to reduce the high-priority ones to an acceptable level.

The legal hook lives in 45 CFR §164.308(a)(1)(ii)(A):

Conduct an accurate and thorough assessment of the potential
risks and vulnerabilities to the confidentiality, integrity,
and availability of electronic protected health information
held by the covered entity or business associate.

That is the entire regulatory text. Everything else — scoring, methodology, format — is inferred from OCR enforcement actions, the NIST SP 800-66 Rev. 2 implementation guide, and NIST SP 800-30 Rev. 1 (the risk-assessment methodology HHS references).

Who has to do one

Every covered entity (hospital, clinic, health plan, clearinghouse) and every business associate (any vendor that processes ePHI for one) has to perform an SRA. Since the 2013 Omnibus Rule, business associates are directly liable — your SaaS doesn't get a pass because the hospital signed a BAA with you.

If you are an engineer at a digital-health startup, your company is almost certainly a business associate, and an SRA covering your stack is mandatory.

The nine elements OCR expects to see

OCR's published guidance breaks the SRA into nine concrete elements. If any one is missing, the SRA is considered deficient — and that's the most common audit finding in the entire HIPAA program.

Scope of the analysis. Every system, application, network segment, vendor, and physical location that touches ePHI.
Data collection. Where ePHI is created, received, maintained, and transmitted. Diagrams help here; auditors love a flow diagram.
Identification and documentation of potential threats and vulnerabilities. Real, specific ones — not "ransomware in general."
Assessment of current security measures. What's actually in place today, with evidence.
Determination of the likelihood of threat occurrence.
Determination of the potential impact of threat occurrence.
Determination of the level of risk. Likelihood × impact, scored against a defined scale.
Finalize documentation. Written, dated, with named contributors and an approver.
Periodic review and updates to the risk assessment.

A risk register that maps each identified risk to a control, an owner, and a remediation deadline satisfies elements 4 through 7 in one artifact. Most of the platforms in the 2026 SRA software landscape generate this register as a first-class object.

Scoping in the real world

In a microservices stack, scoping is where engineering teams either save themselves weeks or doom themselves to a re-do.

A practical scope inventory:

Data stores — production DBs, replicas, snapshots, analytics warehouses, S3 buckets, message queues, search indices.
Compute — every service or job that reads, writes, or transforms ePHI.
Egress paths — outbound webhooks, third-party APIs, SFTP, email transports.
Identity and access — IdP, MFA solution, service-to-service auth, break-glass accounts.
Endpoints — workstations and mobile devices that access ePHI, including BYOD if it's allowed.
Vendors with ePHI exposure — every subprocessor, with executed BAA, located in the register.

If a system could see ePHI but is supposed to be excluded by control, document the control. Auditors test the boundary, not the intention.

A risk register pattern you can copy

A single row should answer: what's the asset, what could go wrong, how likely, how bad, what mitigates it today, what's the residual risk, who owns the fix.

asset:           prod-postgres-primary
ephi_present:    yes
threat:          credential compromise of read-replica role
vuln:            read-replica role permits SELECT on patient_records
likelihood:      moderate
impact:          high
inherent_risk:   high
current_ctrls:   - IAM role assumed via OIDC short-lived tokens
                 - row-level security on patient_records
                 - audit log to siem (90d retention)
residual_risk:   moderate
remediation:     promote retention to 365d to satisfy 2026 NPRM
owner:           security-eng-lead
due:             2026-09-30

Repeat for every asset in scope. The 80/20 of an SRA is getting this register populated honestly.

The three safeguard categories you have to evaluate

HIPAA splits required controls into three buckets and your SRA must consider all of them:

Administrative safeguards — security officer designation, workforce training, access-management policies, BAAs, incident response, contingency planning.
Physical safeguards — facility access, workstation security, device and media controls.
Technical safeguards — access controls (unique IDs, automatic logoff, RBAC), audit controls (logging, log review), integrity controls, authentication (MFA strongly expected, mandatory under the proposed 2026 rule), transmission security, encryption at rest.

Engineering teams default to the technical column. The administrative column is what auditors actually probe — show me your BAA register, show me your termination playbook, show me your last incident retro.

What is changing under the proposed 2026 Security Rule update

HHS published a Notice of Proposed Rulemaking in January 2025 that would rewrite the Security Rule for the first time since 2013. The proposal is not yet finalized, but the direction is locked in. The most operationally significant deltas for engineering teams:

The "required" vs. "addressable" distinction goes away. The categories that used to be "addressable" — most notably encryption — would become hard requirements.
A comprehensive technology asset inventory would be required as part of the SRA itself.
Vulnerability scanning at least every six months.
Annual penetration testing for in-scope systems.
MFA mandatory on every system that accesses ePHI.
Encryption at rest mandatory.
Quantitative risk ratings aligned with NIST SP 800-30 — narrative "high concern" descriptions would no longer satisfy the rule.

Build to the proposed standard now. The retrofit cost when the final rule lands is uniformly higher than the cost of doing it right the first time.

How often you have to do this

HIPAA doesn't name a frequency. OCR's de facto position, repeated across enforcement actions:

At minimum annually.
Immediately upon any significant change — new EHR, new cloud migration, a merger or acquisition, a security incident, a material workflow change.
Per-project for new ePHI workflows — onboarding a new vendor with PHI access, launching a new service line.

If your last SRA is more than 12 months old, you are out of compliance regardless of how good the previous one was.

Common engineering-side mistakes

Patterns we see on every audit:

Treating the SRA as a one-time document. It's a program. The report is just the most recent snapshot.
Documenting controls without evidence. OCR's audit posture is "if it isn't documented with proof, it doesn't exist."
Skipping the BAA register. Vendor risk is the second-most-common breach vector after phishing.
Identifying high-priority risks without remediation plans. OCR treats known and unaddressed as worse than unknown.
Forgetting analytics pipelines. That ePHI warehouse you spun up for the data science team is in scope.

A practical starting point

For teams just getting started, Medcurity's 2026 HIPAA SRA template (downloadable PDF from the pillar page) gives you the nine-element structure, the safeguard checklist, and a risk-register skeleton.

FAQ

Is a HIPAA risk assessment the same as a HIPAA audit? No. The SRA is something you perform on your own environment to identify and remediate risks. The audit is OCR or its delegate verifying that you actually did the SRA and addressed the findings.

Does the OCR free SRA Tool satisfy the requirement for a startup? It produces a defensible baseline for a solo practitioner. For a multi-service stack with cloud infrastructure, it's an inadequate substitute for a real risk register, mostly because there is no continuous remediation tracking and no multi-environment aggregation. Treat it as a starter, not a finish line.

Do we need an SRA for the staging environment? If staging holds real ePHI — even briefly — yes. If staging only holds synthetic data, document the control that enforces that boundary.

What does an SRA usually cost? Internal effort: typically 40–120 hours for a mid-sized practice; more for a multi-site or platform organization. Platform-supported SRAs that integrate with control evidence and BAA management materially reduce the per-cycle effort starting in year two.

Authoritative references

HHS OCR — Guidance on Risk Analysis Requirements under the HIPAA Security Rule
NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule
NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments
45 CFR § 164.308 — Administrative safeguards (eCFR)
HealthIT.gov — Security Risk Assessment Tool

Originally published at medcurity.com/what-is-a-hipaa-risk-assessment/.

The 2026 HIPAA Security Rule: A Mid-Year Readiness Check (June 2026)

Joe Gellatly — Fri, 05 Jun 2026 22:13:14 +0000

Canonical version of this article lives on the Medcurity blog: https://medcurity.com/hipaa-security-rule-2026-update/

If you run security or compliance for a healthcare organization, the single most important regulatory question of 2026 is still open: the proposed HIPAA Security Rule overhaul has not been finalized yet — but the timeline is tightening, and OCR is already enforcing the spirit of it. This is a mid-year checkpoint on where things actually stand and what to have in place before the final rule lands.

Where the rule stands right now

OCR issued its Notice of Proposed Rulemaking on December 27, 2024 (90 FR 800). It drew more than 4,700 public comments, which OCR is still working through. A final rule has been broadly expected around mid-2026, but as of this writing OCR has not confirmed a publication date. When it does publish, covered entities and business associates will get 240 days from publication to comply — so the window to prepare is the time you have now, before the clock starts.

The practical takeaway: don't wait for the Federal Register notice to start the work. The proposed requirements are specific enough to build against today, and most of them are things a mature security program should already be doing.

The four changes worth preparing for

The NPRM is long, but four proposed requirements drive most of the operational change for small and mid-sized healthcare orgs:

Six-month vulnerability scanning cadence. The proposal moves vulnerability scanning from a vague "as needed" posture to a defined recurring cadence. If you scan once a year (or only after an incident), build the muscle for twice-yearly scans now.
Annual penetration testing. Distinct from scanning — a real test, not a checkbox. Budget for it and identify a qualified provider before it's mandatory.
Mandatory encryption of ePHI at rest and in transit, with narrow documented exceptions. The "addressable" wiggle room many orgs have leaned on shrinks considerably.
A genuine, current risk analysis. This is the through-line of the whole rule — and the one OCR is already enforcing hardest.

OCR isn't waiting for the final rule

Here's what makes this urgent even before finalization: OCR's Risk Analysis Initiative is a live enforcement campaign targeting organizations that never performed an adequate security risk analysis. By mid-2025 it had produced seven enforcement actions; by early 2026 the count had reached eleven. OCR has reiterated that an inadequate or missing risk analysis remains the most frequently cited deficiency in investigations.

In other words: the most-enforced requirement of the future rule is the most-enforced deficiency under the current one. A defensible, current, organization-wide risk analysis is the work that pays off no matter when the final rule publishes.

A 30-minute readiness self-check

Before the rule finalizes, walk through this:

When was your last security risk analysis, and does it cover every system that touches ePHI (including SaaS, mobile, and BA-hosted systems)?
Do you have a documented vulnerability-scanning schedule you could move to a six-month cadence without scrambling?
Have you ever had a real penetration test — and could you produce the report?
Is ePHI encrypted at rest and in transit, with documented exceptions where it isn't?
If OCR asked for your risk-analysis documentation tomorrow, could you produce it within a week?

If any answer is "no" or "not sure," that's your pre-finalization to-do list.

Bottom line

The 2026 Security Rule isn't final, but the direction is clear and OCR is enforcing the foundation today. Treat the 240-day comply-by window as a planning horizon you can get ahead of: a current risk analysis, a defined scanning cadence, a real pen test, and encryption you can document. Organizations that do this work now will treat the final rule as a formality rather than a fire drill.

Originally published at medcurity.com — the canonical version is updated as the rulemaking develops.

HIPAA Risk Assessment in 2026: A Healthcare Engineer's Field Guide

Joe Gellatly — Fri, 05 Jun 2026 18:21:33 +0000

If you build, run, or audit systems that touch protected health information (PHI), the HIPAA risk assessment is the document that quietly decides whether the next OCR investigation ends in a closure letter or a corrective action plan with a six-figure settlement. The proposed 2026 HIPAA Security Rule update (published as an NPRM in January 2025, still pending finalization at OCR) doesn't change the underlying requirement at 45 CFR § 164.308(a)(1)(ii)(A) — and OCR has repeatedly reaffirmed that the absence of a current, written risk analysis is itself the most-frequently-cited Security Rule deficiency.

This is the engineering view: what a defensible HIPAA risk assessment actually contains in 2026, how to model it, and what tooling fits the workflow.

1. The asset inventory is non-negotiable

Every defensible HIPAA risk assessment starts with a complete inventory of where ePHI lives, where it flows, and who touches it. If you can't enumerate every system, every integration, and every workforce role that creates / receives / maintains / transmits ePHI, the rest of the assessment is built on sand.

A minimal asset-inventory record per system:

{
  "system_id": "ehr-prod-01",
  "system_type": "ehr",
  "ephi_states": ["create", "receive", "maintain", "transmit"],
  "data_classification": "phi-high",
  "hosting": { "type": "saas", "vendor": "epic", "region": "us-east-1" },
  "workforce_roles_with_access": ["clinician", "billing", "admin"],
  "integrations": [
    { "to": "billing-system", "protocol": "hl7-fhir", "direction": "outbound" },
    { "to": "patient-portal", "protocol": "https-rest", "direction": "bidirectional" }
  ],
  "encryption_at_rest": true,
  "encryption_in_transit": true,
  "mfa_enforced": true,
  "audit_log_destination": "central-siem",
  "ba_agreement_on_file": true,
  "last_reviewed": "2026-05-15"
}

If you don't have this, build it before you do anything else. The HHS-provided ONC SRA Tool walks through asset enumeration but it's optimized for small practices; engineering teams at scale typically pair the SRA Tool framework with a custom asset registry that lives in version control.

2. Threat modeling — but healthcare-specific

The threats engineers usually model for in HIPAA risk assessments:

Ransomware — still the #1 reported breach cause across HHS breach portal data in 2025-2026
Insider misuse — clinical workforce accessing records outside their treatment relationship
Lost / stolen devices — laptops, tablets, USB drives containing ePHI
Vendor / business associate breaches — the BA pathway is the largest external attack surface for most covered entities
Misconfigured cloud storage — S3 buckets, Azure Blob, GCS without correct ACLs
Phishing / credential compromise — the entry point for most ransomware and insider-misuse paths
Unencrypted backups — the backup tier is the highest-impact data set if compromised
Third-party API leakage — analytics tools (Meta Pixel, Google Analytics) capturing ePHI from healthcare web properties

For each threat, the assessment documents: (a) likelihood of exploitation, (b) impact if exploited, (c) current safeguards, (d) residual risk after safeguards.

3. Control mapping to the Security Rule

Every safeguard in your environment maps to one or more Security Rule citations. The pattern:

Administrative (45 CFR § 164.308):
  - .308(a)(1)(ii)(A) — Risk Analysis (this document satisfies)
  - .308(a)(1)(ii)(B) — Risk Management (remediation plan satisfies)
  - .308(a)(3) — Workforce Security
  - .308(a)(5) — Security Awareness and Training
  - .308(b) — Business Associate Contracts

Physical (45 CFR § 164.310):
  - .310(a)(1) — Facility Access Controls
  - .310(d)(1) — Device and Media Controls

Technical (45 CFR § 164.312):
  - .312(a)(1) — Access Control
  - .312(b) — Audit Controls
  - .312(c)(1) — Integrity
  - .312(d) — Person or Entity Authentication
  - .312(e)(1) — Transmission Security

A risk assessment that lists every system but never maps controls back to the regulatory citations is missing the connective tissue OCR investigators look for in evidence.

4. The documentation pattern

OCR's first question in any audit or investigation is: "Show me your most recent risk analysis." The activity isn't enough — the written, dated, and signed document is what satisfies the requirement. Minimum sections:

Scope statement — what's in, what's out, why
Asset inventory — the table from step 1
Threat-vulnerability pairs — with likelihood / impact / current controls / residual risk
Safeguard inventory — what's in place, mapped to Security Rule citations
Gap analysis — Security Rule requirements not yet met
Risk prioritization — high-likelihood, high-impact threats at the top
Remediation plan — corrective action, owner, target date, residual risk
Review cadence — at least annually + after any significant change

Keep it in version control. The git history is itself evidence of the "review and update regularly" requirement.

5. Tools that fit the engineering workflow

The most common tooling stack for engineering-led HIPAA risk assessments:

HHS Security Risk Assessment (SRA) Tool — free, useful as a framework reference; small-practice scope, doesn't scale to enterprise
Asset-inventory — pulled from cloud APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory) + a manual layer for non-cloud workflows
Vulnerability scanning — Tenable, Qualys, or Rapid7 in healthcare-vertical configurations
Audit log aggregation — Splunk, Datadog, or Elastic for HIPAA § 164.312(b) audit controls
Healthcare-vertical compliance platforms — products like Medcurity that combine the risk-assessment framework, BAA / policy / training management, and OCR-defensible documentation in one workflow tuned for healthcare orgs (vs. horizontal GRC platforms built for SOC 2 / ISO 27001 environments)

6. The 6 mistakes that draw an OCR audit

From OCR's published enforcement actions (HHS Breach Portal + Resolution Agreements 2022-2026), the recurring deficiencies:

No documented risk assessment at all — most common; the "we do it but never wrote it down" pattern
Risk assessment scope omits major systems — typically BA systems, mobile workforce, or cloud-hosted analytics
Risk assessment is older than 12 months — OCR's default expectation is annual at minimum
No remediation plan tied to identified risks — the assessment identifies risks but never documents corrective action
No evidence of review after a major change — M&A, new system, regulatory change (e.g. the proposed 2026 Security Rule update) all trigger a refresh requirement
Risk assessment uses generic templates with no organization-specific data — generic-template-only assessments are flagged in OCR investigations

Reading list

HIPAA Risk Assessment: Complete Guide for 2026 (Medcurity pillar) — the canonical reference for this post
Best HIPAA Compliance Software for 2026 — software comparison
HIPAA Risk Assessment for Rural Hospitals — rural-vertical risk pattern
HIPAA Compliance for FQHCs — FQHC-specific overlay (HRSA + FTCA + HIPAA)
HIPAA Security Rule 2026 Update — proposed-rule status + what to prepare

Originally published at medcurity.com — a deeper version of this post with a full how-to schema and FAQ section.

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.

DEV Community: Joe Gellatly

Best HIPAA SRA Software in 2026: Why Healthcare-Native Beats Horizontal

The 2026 distinction that matters

Where the healthcare-native tools lead

A quick frame for choosing in 2026

The half of HIPAA that horizontal GRC platforms miss — an engineer's 2026 look

HIPAA has two distinct layers in code

The OCR Risk Analysis Initiative is what changes the cost calculus

What "healthcare-vertical" actually means in the data model

How to pick — honestly

The question to actually ask in 2026

Reading list

Building a HIPAA Risk Assessment: A Plain-English Guide for Healthcare Teams

What a HIPAA Risk Assessment actually is

Who has to do one

The nine elements OCR expects to see

Scoping in the real world

A risk register pattern you can copy

The three safeguard categories you have to evaluate

What is changing under the proposed 2026 Security Rule update

How often you have to do this

Common engineering-side mistakes

A practical starting point

FAQ

Authoritative references

The 2026 HIPAA Security Rule: A Mid-Year Readiness Check (June 2026)

Where the rule stands right now

The four changes worth preparing for

OCR isn't waiting for the final rule

A 30-minute readiness self-check

Bottom line

HIPAA Risk Assessment in 2026: A Healthcare Engineer's Field Guide

1. The asset inventory is non-negotiable

2. Threat modeling — but healthcare-specific

3. Control mapping to the Security Rule

4. The documentation pattern

5. Tools that fit the engineering workflow

6. The 6 mistakes that draw an OCR audit

Reading list

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