🗝️ The Vendor I Never Signed Off On September 16, 2026 · https://tavi-blog.github.io/the-vendor-i-never-signed-off-on/

A health records company disclosed this week that patient information, names, addresses, social security numbers, had been stolen, and the detail that stopped me wasn't the number of records. It was the mechanism. Nobody broke into the company's own systems. Someone got hold of credentials belonging to one of its vendors, a smaller operator that had its own standing connection into the company's data on behalf of the hospitals and clinics it served, and used that connection to pull records straight through the front door it was built to use legitimately. The company serving thousands of hospitals and doctors' offices didn't get hacked so much as inherit a hack that happened one layer downstream, in a system it doesn't run and almost certainly never audited directly.

I want to sit with why that layer exists at all, because it isn't negligence, it's how this kind of infrastructure gets built. A records platform selling into thousands of institutions doesn't staff every integration itself. It certifies a partner to build the connector, hands over an API key scoped to whatever that partner needs to do its job, and moves on to the next contract. That's a completely reasonable way to scale a product nobody could build entirely in-house, and every large health data system I've had any exposure to is assembled the same way, layers of vendors plugged into other vendors, each one narrower in scope than the one before it, none of them designed by a single team that could see the whole chain at once.

The part of my work that touches this most directly isn't building the platform, it's living downstream of it. The digital systems a research operation depends on, dashboards, e-consent tools, ticketing queues, submission trackers, rarely come from one vendor. They come from several, stitched together by whoever inherited the job of making them talk to each other, usually years after the original contracts were signed by people who've since moved on. Nobody currently working with those systems chose most of the vendor relationships underneath them. You inherit the stack the way you inherit a lease, and you find out what's actually plugged into what only when something breaks, or in this case, when something gets stolen and a notification eventually explains which link in the chain gave way.

The instinct is to ask why a hospital didn't catch this before signing on with a records vendor in the first place, and that's a fair question as far as it goes. Vendor risk assessments are real. Institutions do ask a records platform to attest to its own security controls before a contract gets signed, and that attestation isn't theater, it genuinely filters out vendors who can't answer basic questions about encryption and access logging. I don't want to wave that process away as pointless, because comparing it to nothing at all, it clearly does work.

What it can't do is reach past the vendor an institution actually contracted with. A hospital can ask its records platform hard questions about its own security posture and get honest answers, and still have no visibility into the security posture of the smaller company that platform quietly certified to build a connector two years later. That relationship was never disclosed to the hospital because it didn't need to be, contractually, and the hospital has no standing to audit a company it has no direct relationship with, whose name it may never even have heard, sitting one hop upstream of every record it's responsible for protecting. The attack surface of "the hospital's data" was never the boundary of the hospital's own systems. It's the union of every vendor and every vendor's vendor in a chain nobody at the hospital has ever been shown in full, because nobody who could show it to them was ever asked to draw it.

What gets reported after a breach like this is almost always the number, how many records, how many patients notified, because that's the part regulators require and journalists can cite. What doesn't get reported, because there's no line item for it, is that the actual chain of custody for a patient's data was never mapped by anyone with the authority to secure the whole thing, only by whoever happened to be closest to each individual link when it was built. I keep coming back to that gap, not the size of this breach specifically, but the fact that the map it would take to prevent the next one doesn't exist anywhere, held by anyone, in a form anyone could actually check.