Why the "Comply with Everything" Approach Is Killing Healthcare Security Teams

There's a particular kind of meeting that happens inside mid-size health systems and HealthTech vendors right now. Someone from sales comes in and says a big customer wants HITRUST. Someone from legal flags a state privacy law change. An auditor emails about HIPAA gap remediation. A prospect asks for a SOC 2 Type II report before they'll sign.

Each request is reasonable on its own yet nobody ever stops to ask whether six programs running in parallel is making the organization more secure, or just busier.

It's usually the latter, and at some point, the compliance burden itself becomes the security risk.

The Framework Stack Has Gotten Out of Hand

A typical mid-size HealthTech company today is juggling some version of this list: HIPAA/HITECH, HITRUST CSF, the HHS 405(d) Health Industry Cybersecurity Practices (HICP), the HHS Healthcare and Public Health Cybersecurity Performance Goals (HPH CPGs), SOC 2 Type II, ISO 27001, and a growing stack of state laws: California's Confidentiality of Medical Information Act, the Texas Medical Records Privacy Act, and whatever else state regulators decide to prioritize this year.

That’s six to ten frameworks that most organizations are running as separate programs.

That means separate control libraries, separate evidence folders, separate audit calendars, and separate owners. Security staff spend more time preparing for assessments than actually reducing risk.

This is what "healthcare compliance burden" looks like from the inside. It's never one massive program that breaks the team but a dozen individually manageable ones that collectively consume it.

What Parallel Programs Actually Cost

The obvious cost is time. Evidence collection for a SOC 2 audit overlaps heavily with HIPAA documentation requirements, which overlap heavily with HITRUST control evidence. Every one of those programs is asking for largely the same proof (access reviews, risk assessments, incident response records, vendor contracts, encryption configurations), just formatted differently and on different schedules.

The less obvious cost is attention. When your security team is context-switching between an ISO surveillance audit, a HITRUST readiness assessment, and a SOC 2 bridge letter, nobody has the mental bandwidth to ask what threats are actually active against the organization right now. The work of compliance crowds out the work of security.

And then there's the morale cost, which is real even if it doesn't show up in a risk register. Security engineers who joined to stop attackers and end up managing spreadsheets for auditors burn out. Ask practitioners which organizations hold up best against breaches, and a pattern comes up often enough to be worth paying attention to: security teams with actual bandwidth to do security work.

Counterintuitively, running more frameworks does not produce better security outcomes. It produces more paperwork and, often, worse ones, because nobody is looking at root threats anymore.

Why This Happens

Compliance programs don't get designed, they accumulate. A company starts with HIPAA because they handle PHI and have no choice. A large health system customer asks for HITRUST before they'll sign, so HITRUST gets stood up as a separate workstream with its own owner and its own budget. A Series B brings enterprise sales attention, and enterprise sales wants SOC 2. ISO comes from an international partnership or an acquirer's requirement. Each framework arrives in response to an external demand, gets assigned to whoever has bandwidth, and rarely gets reconciled with what already exists.

The result is organizational scar tissue. Each program has its own spreadsheet, its own evidence repository, its own muscle memory. Nobody has an incentive to consolidate, because consolidation is a project with no immediate deliverable and a lot of political risk if something breaks. So the stack grows, the team spins, and the auditors get paid.

The Unifying Insight Nobody Acts On

Here's the thing that compliance teams know intellectually but rarely act on: the majority of controls across HIPAA, HITRUST, SOC 2, ISO 27001, HICP, and the HPH CPGs are the same control described in different words. By most practitioners' estimates, the overlap is 75-80% or more. That's by design, not coincidence. HITRUST was explicitly built to incorporate HIPAA, NIST, and ISO requirements. The HPH CPGs align with NIST CSF as a primary reference. The frameworks were designed to converge though most organizations are just not taking advantage of that.

The underlying controls are functionally identical. What differs is the language, the mapping tables, and how audit artifacts get formatted.

Running six compliance programs because you have six frameworks is like writing six different resumes for six different jobs when the underlying experience is the same. The work isn't 6x. It's closer to 1x than most teams realize, if you structure it right.

This is the core insight behind healthcare security framework consolidation, and it's why organizations running a single unified control program tend to do better, on both audit outcomes and actual security posture, than organizations running parallel programs.

What A Unified Model Actually Looks Like

The mechanics are not complicated, even if the transition takes work.

You build one control library. One, covering everything. Each control in that library is tagged with the framework references it satisfies. To take a concrete example: an access enforcement control (NIST AC-3) maps to HIPAA §164.312(a)(1), HITRUST Control Category 01.b, SOC 2 CC6.3, and ISO 27001:2013 A.9.4.1. The control is the control. The framework tags are just metadata.

You collect evidence once per control, per period. An access review completed in October covers your HIPAA documentation requirement, your HITRUST evidence request, your SOC 2 population, and your ISO audit simultaneously. The auditor for each framework gets a view into the same evidence base, filtered for what they need.

You prioritize based on threat, not checklist. This is where HICP and the HPH CPGs earn their place. Use them as threat-led prioritization tools rather than more compliance programs to run in parallel. The HICP publication maps its ten practices to different org-size implementation tiers, so a small HealthTech vendor doesn't need to treat a large health system's implementation requirements as the baseline. The HPH CPGs (released by HHS in January 2024) go further, explicitly designating "essential" goals: the baseline behaviors that cover the most common attack vectors against healthcare organizations. Build your control program around those threat scenarios first, then map the compliance coverage as a byproduct.

The key distinction between this model and what most organizations do: here, the control is primary and the framework is a reporting view. In most organizations, it's the reverse.

The Operating Model Shift

The goal is to get from "compliance team chases evidence" to "security program produces compliance as a byproduct."

In the first model, compliance is a quarterly fire drill. Someone from the compliance team emails department heads asking for screenshots and configurations. The security team drops what they're doing to pull logs. The auditor finds gaps. The team remediates the gaps just for the audit. Nothing fundamentally changes.

In the second model, controls are continuously operated. Access reviews run on a schedule that's part of normal IT operations, not triggered by audit season. Risk assessments are a standing process, not a one-time document. Incident response gets tested because the security team tests it, not because HITRUST requires evidence of a tabletop. When the auditor arrives, for any framework, the evidence is already there and already organized.

The compliance team's job changes too. Instead of chasing evidence, they're maintaining the mapping tables, managing auditor relationships, and flagging when a new regulation requires a new control or an update to an existing one. They're running a program, not panicking.

Where to Start

NIST CSF and HITRUST CSF are both reasonable choices for healthcare organizations. NIST CSF is broader and maps cleanly to almost everything, including both HICP and the HPH CPGs. HITRUST is more prescriptive and carries direct audit credibility with health system procurement teams. If your primary pain point is customer audits, HITRUST as a backbone probably makes more sense. If your primary pain point is internal program coherence, NIST CSF is more flexible.

From there, the steps are sequential. Take one of your existing framework control sets (HITRUST's r2 control categories work well for this) and use it as the master list. For each control, document what evidence already exists across your current programs and identify the gaps. Then tag each control with every framework reference it satisfies. A single access review policy should carry references to HIPAA §164.312(a)(1), HITRUST 01.b, SOC 2 CC6.3, and ISO 27001 A.9.4.1 before it's filed. The tagging work is tedious the first time and near-automatic after that.

The mapping work takes time upfront. It saves multiples of that time over every subsequent audit cycle.

One more thing: stop running parallel audits where you can avoid it. The AICPA and HITRUST have a formal joint reporting product, the SOC 2 + HITRUST combined assessment, which lets a single audit engagement produce both a HITRUST certification and a SOC 2 Type II attestation from one shared evidence base. It's a real, structured pathway with formal support from both organizations. If you're paying for both separately, that's worth a conversation with your auditor.

The Closing Argument

Compliance maximalism is a strategy tax. The organizations winning on healthcare security right now are not the ones with the longest list of frameworks. They're the ones genuinely reducing breach rates, building security teams that stay, and clearing audits without drama. They're running one coherent program and presenting it through whatever lens a given stakeholder needs to see.

‍

The "more frameworks equals more security" narrative benefits consulting firms and certification bodies. It does not benefit health system security teams. It turns compliance into an arms race where the prize is more paperwork.

You don't get more secure by adding frameworks. You get more secure by actually operating controls, consistently and against the threats that matter. The frameworks are just a way to describe that work to people outside the organization.