When a healthcare practice’s compliance work and its IT work come from different vendors, accountability disappears in the middle

WhatsApp Channel Join Now
Audit Log Review and Management Explained | StrongDM

A practice hires a compliance firm to run its HIPAA risk assessment and a separate IT provider to manage its network. This is a common setup, and on paper it looks reasonable: a specialist for compliance, a specialist for infrastructure, each doing what they’re best at.

The problem shows up when the compliance firm’s assessment turns up a finding that requires a technical fix. The compliance firm identifies the gap, documents it, and hands over a report. Implementing the fix isn’t their job. It’s the IT provider’s. And the IT provider is now being asked to act on a finding they didn’t generate, may not have full context on, and weren’t in the room when it was defined.

The finding crosses a boundary nobody designed for

A risk assessment finding, insufficient audit logging on the EHR, for instance, isn’t self-executing. Someone has to interpret what the finding actually requires, choose a technical approach, implement it, and confirm the implementation satisfies what the compliance firm meant when they wrote it down.

When the same organization does both the identifying and the fixing, that interpretation happens internally, informally, without anyone having to translate the finding for an outside party. When two separate vendors are involved, that translation becomes a formal handoff; a report gets sent from one company to another, and the receiving company has to work out what it actually means in practice.

Handoffs are where specificity gets lost. A compliance firm writes “insufficient audit logging” because that’s the vocabulary of a risk assessment. An IT provider reads that and has to decide what logging configuration satisfies it, whether their existing tools can produce it, and how confident they are that their interpretation matches what the compliance firm intended. If those two things don’t quite line up, nobody notices until the next assessment cycle, when the same finding shows up again, or until an actual incident reveals the gap.

Nobody owns the finding once it’s been handed off

Once the finding crosses that boundary, responsibility for it becomes genuinely ambiguous, not because either vendor is being negligent, but because the finding no longer belongs cleanly to either side.

  • The compliance firm can reasonably say they did their job: they identified the risk and documented it.
  • The IT provider can reasonably say the finding wasn’t specific enough to act on, or wasn’t formally part of their scope of work.
  • The practice, caught in the middle, doesn’t have the technical or compliance expertise to independently verify which explanation is accurate.

Each party’s position holds up on its own. That’s what makes this different from a simple case of one vendor dropping the ball. Nobody is lying about their role. The structure itself creates a gap where a finding can sit unresolved while everyone involved believes they’ve done what they were responsible for.

This is a common pattern in HIPAA enforcement history: investigations following a breach often turn up a risk assessment that correctly identified the vulnerability that was later exploited. The assessment wasn’t the failure. What happened between the assessment and the incident, the part where the finding was supposed to get closed, was.

Why a fragmented structure hides this until it’s too late

A single, accountable vendor handling both identification and remediation has an obvious incentive to close findings: nothing else in their process happens until this part does, because it’s the same team that has to answer for the outcome either way. That incentive dissolves when a finding crosses a company boundary, because each vendor is measured on their own deliverable, not on whether the practice’s actual risk went down.

A compliance firm’s contract is typically fulfilled when the assessment report is delivered. An IT provider’s contract is typically fulfilled when the tickets in their queue are closed. Neither of those success measures directly tracks whether a specific finding got resolved. A finding can sit open for months without violating either vendor’s terms, because closing it was never explicitly whose job it was.

The practice doesn’t see this gap in real time. It sees two vendors, each producing evidence of activity, a completed assessment on one side, a stream of resolved tickets on the other, and reasonably assumes the combination adds up to being covered.

What accountability actually requires here

Fixing this doesn’t necessarily mean consolidating every vendor into one contract, though that’s one way to close the gap. What it requires, at minimum, is making the handoff explicit instead of assumed.

  • Every finding needs a named owner on the technical side, not just a compliance-side author.
  • That owner needs a defined date to report back, closed, in progress, or blocked, rather than the finding disappearing into a general queue.
  • Someone, whether that’s the practice itself or one of the vendors under an expanded scope, needs to track findings across the full cycle from identification to resolution, not just within each vendor’s own piece of it.

This is precisely the gap that well-structured managed IT services for healthcare are supposed to close when a practice’s compliance and technical work sit under the same accountable roof: not because a single vendor is inherently more competent than two specialists, but because a single vendor can’t hand a finding across a boundary and lose track of it the way two separate companies can.

The report was never the finish line

A practice with a completed risk assessment and a responsive IT provider can still have unresolved findings sitting in the gap between them, and neither vendor’s paperwork will show it. The report says the risk was identified. The ticket queue says requests get handled. What neither one shows is whether this specific finding, the one that matters, ever actually got closed by someone who was accountable for closing it.

Similar Posts