Vendor-Side Cyber Risk Quantification for BAA Attestation

Healthcare software companies live inside a difficult trust relationship. They may not run the hospital, but their products can sit directly in revenue cycle, telehealth, imaging, clinical workflow, identity, data exchange, or medical-device operations. The hospital therefore needs more than a contractual assurance that the vendor will safeguard protected information. It needs a reason to believe the vendor's operating controls remain effective over time.

The conventional answer has been the annual security questionnaire. The vendor describes its policies, architecture, controls, certifications, penetration tests, backup practices, access rules, and incident process. Sophisticated healthcare organizations then ask follow-up questions, request documents, and repeat the exercise at renewal. The process is expensive because both sides know the limitation: the response is a point-in-time statement assembled by the party being evaluated.

The weakness is not that questionnaires are useless. Contracts and diligence still matter. The weakness is that a questionnaire cannot continuously answer whether a required control is present now, whether a material vulnerability appeared after the assessment, whether privileged access drifted, whether evidence went stale, or whether a remediation claim was actually verified.

HHS requires covered entities and business associates to establish written business associate arrangements where applicable and requires business associates to safeguard electronic protected health information and report security incidents. That legal structure creates obligations, but it does not by itself create continuous technical evidence. The credibility gap sits between what the contract requires and what the vendor can prove about its current operating state.

Continuous vendor-side quantification starts by defining the vendor as the bounded system being measured. The assets may be cloud workloads, identities, application services, build pipelines, endpoints, databases, network paths, and customer-facing infrastructure rather than a hospital endpoint fleet. The measurement discipline does not depend on the asset class being a laptop.

The vendor needs four things. First, current state collection: which controls and exposures are actually present. Second, authority-aware action: what the vendor is allowed to change and under whose approval. Third, re-observation after intervention: whether the resulting state changed as intended. Fourth, evidence continuity: a retained record that lets the vendor and the customer distinguish a fresh observation from an old claim.

The architecture should separate raw source evidence from the conclusions drawn from it. Identity evidence may come from Entra or Google. Vulnerability evidence may come from scanners, cloud providers, software inventory, or external testing. Endpoint and server state may come from an agent or management platform. Cloud control state may come from native APIs. The point is not to force every signal into one vendor's proprietary taxonomy. The point is to reconcile unlike signals into a common statement about current operating state.

A mature implementation also preserves tenant and customer boundaries. A healthcare software vendor may serve hundreds of hospitals. The proof it gives one customer should not expose another customer's data, and the customer's right to inspect evidence should not become administrative authority over the vendor's environment. Continuous attestation is useful precisely because it can disclose the state required for trust without disclosing the entire operating system behind it.

The Ford Model applies the same directional law to the vendor environment: risk compresses when Enforcement plus Proof Continuity exceeds Decay plus Adversarial Pressure. The observables change with the system; the math does not.

For a SaaS vendor, Enforcement may include MFA coverage, privileged-access policy, endpoint and workload control state, patch execution, deployment policy, secure configuration, and successful remediation. Proof Continuity may include fresh attestations, evidence completeness, signed receipts, and continuous verification of required controls.

Decay may include stale service accounts, configuration drift, orphaned cloud resources, expired secrets, privilege creep, unsupported software, or evidence gaps. Adversarial Pressure may include known-exploited vulnerabilities, attacker campaigns against the vendor's technology stack, exposed services, and threat activity affecting the sector or product class.

A vendor does not become credible because it has a high score. It becomes more credible when it can show which state variables changed, why the direction changed, how long the favorable state has held, and what evidence supports the claim. That is materially different from attaching a questionnaire response from nine months ago to a sales email.

The Ford Model also prevents a common mistake: treating the absence of a detected incident as evidence that risk is low. A vendor can sit in an Expansion Regime without having been breached yet. If proof is stale, internal decay is rising, and adversarial pressure has increased, the risk direction can be unfavorable before an incident produces a headline.

A hospital does not need a firehose of the vendor's internal telemetry. It needs a compact, reproducible evidence package tied to the controls and risks that matter in the relationship. That package should state the measurement window, the systems in scope, the current control state, material exceptions, unresolved exposure, remediation evidence, proof freshness, and the direction of modeled risk.

The hospital should be able to distinguish observed, verified, and unknown state. If a control cannot be verified, the attestation should say so. If an exception is accepted, it should be explicit. If a remediation has been performed but not re-observed, it should not be represented as verified closure.

The package should also be durable enough to support renewal, audit, incident response, and insurance. A hospital that accepted a vendor based on current evidence should be able to look back later and determine what was known at the time, what changed, and what the vendor proved after a material event.

This changes the sales conversation for the vendor. Security no longer arrives only as a defensive appendix to a questionnaire. The vendor can present continuously measured evidence as part of its commercial credibility: not 'trust our answers,' but 'here is the current state, the exceptions, the proof window, and the history of verified change.'

The point of using public breach cases is not to claim that a measurement system would have predicted the exact event. It is to ask what continuously measured vendor evidence could have made visible before and during the incident.

UnitedHealth Group disclosed that on February 21, 2024 it identified a threat actor with access to some Change Healthcare systems. The company isolated impacted systems, and the resulting disruption affected pharmacy, claims, and payment services across the health system. HHS later described the event as unprecedented in magnitude and opened investigations focused on the breach and HIPAA compliance. A hospital relying on Change Healthcare did not merely need an annual answer about security policy; it needed current evidence about service availability, identity and access state, containment, restoration, and the return to trustworthy operation.

Continuous vendor evidence would not have made the attack impossible. It could have provided customers with a defined before-state, a timestamped change in service and control state, a record of containment, and fresh proof of restoration. That record would improve the customer's ability to assess operational exposure, determine whether compensating controls were necessary, and understand when trust in the vendor service had been restored.

MOVEit illustrates a different problem. Progress reported receiving a customer call about unusual activity on May 28, 2023, discovering a zero-day vulnerability, notifying customers and taking down MOVEit Cloud on May 30, and releasing patches on May 31. CISA reported that the CL0P group had begun exploiting CVE-2023-34362 in May and added the vulnerability to the Known Exploited Vulnerabilities Catalog on June 2.

A customer questionnaire completed months earlier could not reflect that change in adversarial pressure. Continuous evidence could. A vendor-side attestation could show which versions were present, which internet-facing instances were affected, when mitigation or patching occurred, whether vulnerable state remained observable, and whether proof continuity survived the emergency change. The value is not clairvoyance. The value is a short interval between reality changing and the customer being able to verify what that change means.

For healthcare vendors, this is the commercial point. Hospital customers increasingly carry third-party risk into patient safety, revenue, regulatory, and insurance decisions. A vendor that can continuously demonstrate its own state is not merely answering a questionnaire faster. It is solving a credibility problem that static attestation cannot solve.