What do healthcare organisations get wrong about third party security reviews?

A common mistake is treating vendor review as a one time onboarding exercise instead of an ongoing control. Healthcare organisations also tend to rely on trust without asking for evidence of security measures, incident response capability, and audit reports. The article’s guidance points to continuous evaluation, especially after ownership changes, because risk changes when a vendor’s control environment changes.

Why Third-Party Reviews Fail When They Become a Checklist

Healthcare organisations often confuse a vendor security review with proof of security. A questionnaire, a shared policy packet, or a single SOC 2 report can reduce uncertainty, but none of them proves how the supplier operates on the specific systems and data you care about. The useful question is whether the review changes your understanding of real exposure, not whether a file was collected.

That distinction matters because third-party risk is not static. A vendor can look acceptable at onboarding and become materially different after an acquisition, a tooling change, a cloud migration, or a new subcontractor relationship. The review process has to follow those changes, especially where the supplier can touch patient data, clinical workflows, or integrated platforms.

Healthcare teams also overestimate trust signals. A polished assurance package does not replace evidence about incident response maturity, auditability, access boundaries, logging, and offboarding discipline. The stronger the operational dependency, the more the review needs to test whether the vendor can detect, contain, and explain a compromise in time to matter.

For a broader view of how suppliers, contractors, and B2B identities should be governed over time, Third-Party, B2B and Contractor Access Guide is a useful companion because it frames access review as an ongoing governance activity, not a one-time gate.

What Good Third-Party Security Review Actually Measures

A serious review measures control effectiveness, not just control existence. That means asking whether the vendor can show current evidence for who can access your data, how access is granted and revoked, how exceptions are approved, and how quickly privileged access is removed when a relationship ends. In healthcare, those are operational questions because integration paths often outlast the original procurement decision.

Ownership changes deserve particular attention. If a vendor is acquired, changes hosting, swaps core subprocessors, or reuses credentials across environments, the original review can age out quickly. The right control is continuous reassessment tied to material change events, with defined triggers for renewed due diligence and temporary escalation when evidence is incomplete.

Security review should also examine whether the supplier can prove segmentation between customers, environments, and support functions. In practice, many failures arise when a third party has legitimate access for support but insufficient separation between production and non-production, or between one customer’s data and another’s. Those are review findings because they predict blast radius, not just policy quality.

For teams building a stronger assurance baseline, OWASP Non-Human Identity Top 10 is directly relevant where the supplier uses machine credentials, OAuth grants, or service integrations, because it highlights the same failure modes that turn a vendor relationship into an exposure path.

If the concern is broader SaaS-to-SaaS and token-driven exposure, SaaS-to-SaaS and OAuth App Governance Guide maps the practical controls around consent, scope review, token revocation, and integration governance that should be part of the supplier review cycle.

What Healthcare Teams Commonly Miss in the Review Process

One common miss is accepting a report without testing whether it covers the actual service being procured. Another is treating an organisation-wide certification as proof that every product, environment, and support function is equally well controlled. A third is ignoring subcontractors, where the real exposure often sits outside the named vendor.

Healthcare organisations also underweight incident response. It is not enough to ask whether a vendor has a plan; the review should ask how quickly the vendor can identify affected tenants, preserve evidence, notify affected customers, and support containment. Those details determine whether the supplier is merely compliant on paper or operationally useful during a live event.

Finally, too many reviews focus on onboarding and forget access drift. A vendor that starts with narrow access can accumulate broader privileges, stale tokens, or overlapping support permissions over time. The review should therefore be paired with periodic entitlement checks and a clean offboarding path so the control remains effective after the initial approval.

For organisations that want a mechanism-level reminder of how token theft and integration abuse create downstream exposure, Salesloft OAuth token breach and Klue OAuth Supply Chain Breach are concrete examples of why a third-party review must track credential and integration risk, not only document status.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 sets the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
SOC 2 (AICPA)	CC9.2 — Risk Mitigation	Third-party reviews often rely on external assurance and vendor risk evidence.
Recommendation — Require current vendor evidence and re-evaluate assurance when the service or ownership changes.
ISO/IEC 27001:2022	A.5.19 — Information security in supplier relationships	Directly governs supplier security expectations and ongoing oversight.
	A.5.20 — Addressing information security within supplier agreements	Contracts must set security duties, evidence, and incident obligations for vendors.
	A.5.21 — Managing information security in the ICT supply chain	Healthcare vendor reviews must account for subcontractors and supply-chain change.
Recommendation — Define supplier security requirements and review them throughout the relationship. Write security, audit, and incident response obligations into supplier agreements. Assess subcontractors and supply-chain changes before renewing trust in a supplier.
CIS Controls v8	CIS-15 — Service Provider Management	Covers third-party oversight, assurance, and ongoing supplier monitoring.
Recommendation — Track provider risk continuously and validate security evidence on a recurring basis.

Practitioner Guidance

What to verify: Ask for current evidence that matches the exact service in scope, including incident response capability, audit logs, access revocation process, and any subcontractor chain that can reach your data. If the evidence is generic, dated, or unrelated to the procured service, treat the review as incomplete rather than reassuring.

Decision rule: If a vendor can access patient data, clinical workflows, or production integrations, move from annual review to change-triggered review, with immediate reassessment after acquisition, architecture change, or major incident. If the vendor cannot produce timely evidence, restrict access until the gap is closed.

What practitioners underestimate: The biggest risk is often not initial onboarding failure, but review decay. A supplier that was acceptable at signature can become a higher-risk dependency through token sprawl, new support paths, or ownership change, so the review must be treated as an active control with an owner, cadence, and escalation path.

Practitioner takeaway: In healthcare, third-party review is only useful when it is tied to live evidence and material change, because the real control is the ability to detect when a supplier’s risk has changed and act before that change affects patient data or operations.