Vendor risk management

Tier the service by actual impact

A scheduling vendor, claims clearinghouse, cloud host, payroll service, transcription tool, communications platform, and shredding company create different dependencies. Classify the service by data, access, clinical or operational impact, financial authority, downtime tolerance, and substitutability.

Tiering sets the review depth, approvers, contract controls, monitoring cadence, test plan, and exit work. A small vendor can be critical if it holds the only copy of a record or controls a core workflow.

Maintain one vendor register

For every vendor and relevant subservice, record:

• owner, purpose, product, environment, users, and criticality
• data created, received, maintained, transmitted, derived, and logged
• privileged access, integrations, subprocessors, hosting regions, and dependencies
• legal and contract role, insurance, licenses, attestations, and evidence dates
• availability, recovery, incident, notification, support, and change duties
• retention, return, deletion, portability, termination, and transition terms
• open findings, exceptions, remediation owners, and review triggers

Match the register to accounts, integrations, payments, contracts, and data flows. Shadow tools and expired pilots belong in scope when they still retain data or access.

Ask for evidence that fits the use

A certification or audit report can inform diligence. Read its scope, period, systems, locations, exceptions, subservice treatment, and customer responsibilities. Compare them with the service the practice will actually deploy.

Review architecture, encryption, identity, access, logging, vulnerability, development, incident, recovery, deletion, and personnel controls in proportion to risk. Validate critical workflow behavior with authorized test data. A document cannot prove that the practice configured a feature correctly.

Allocate duties in the contract

Document permitted data uses, confidentiality, security, incident notice, cooperation, availability, backups, recovery, audit evidence, changes, subprocessors, support, record access, return, deletion, transition, and termination. Preserve each party's legal duties.

If a cloud service provider creates, receives, maintains, or transmits ePHI for a covered entity or business associate, HHS cloud guidance says business-associate status can apply even when the provider lacks the decryption key. The applicable parties need a compliant BAA. A BAA does not validate security, accuracy, or fitness.

A fictional critical-vendor review

Keira's practice locks 16 critical vendors due for renewal. Thirteen have current ownership, data maps, security evidence, contract duties, incident routes, recovery tests, and exit plans: 13 of 16, or 81.3%.

One vendor has an unresolved audit exception. One cannot demonstrate export of attachments. One changed a subprocessor without completing review. All three remain escalated with dates. The ratio measures review completeness, not vendor safety or compliance.

Monitor changes and incidents

Review on a schedule and after a material change. Triggers include new data, AI features, subprocessors, hosting, ownership, authentication, integration, pricing, contract terms, control exceptions, outages, incidents, acquisitions, and end-of-life notices.

Track current evidence, open findings, failed service levels, unusual access, support trends, downtime, recovery tests, and complaints. Define which events require pause, restricted use, alternate processing, escalation, or termination.

An incident route should name contacts, hours, required content, evidence preservation, investigation support, notification duties, and separate clocks. Vendor notice never replaces the practice's own classification and response work.

Include financial and concentration risk

Operational resilience also depends on pricing, ownership, viability, insurance, and market alternatives. Record renewal dates, price-change rights, minimum commitments, termination fees, payment dependencies, and the cost of transition. Escalate a merger, financial warning, repeated support failure, or withdrawal of a core feature.

Concentration can hide across different vendor names. Several applications may rely on the same cloud region, identity provider, communications carrier, subprocessor, or integration platform. Map these shared dependencies and test a scenario in which one fails. Compare the time needed to move with the practice's supported continuity window. A contractual exit right offers little value when data cannot be exported or the replacement requires months of configuration.

Design continuity and exit early

Identify alternatives for critical functions. Keep current contact routes, export instructions, credentials, configurations, schemas, and reconciliation steps. Exercise restoration or transition where risk warrants it.

Before exit, decide which records remain available, how open care and claims continue, how accounts and integrations are disabled, which data is returned, what must be retained, and how deletion is evidenced. Check backups, logs, support systems, and subprocessors rather than accepting one broad deletion statement.

NIST SP 800-161 Rev. 1 Update 1 provides cybersecurity supply-chain risk practices across acquisition and the lifecycle. The voluntary NIST Cybersecurity Framework can organize governance and monitoring. Apply them alongside the practice's legal, clinical, payer, privacy, and contract sources.

Before renewal, record one explicit decision for each critical vendor: continue, restrict, remediate, replace, or exit. Tie it to current evidence, open findings, owner, deadline, continuity control, and the next trigger for reconsideration.