DEV Community

Joe Gellatly
Joe Gellatly

Posted on • Originally published at medcurity.com

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

#hipaa #healthcare #security #compliance

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

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

Top comments (0)