Vendor management is where most IT outcomes are won or lost. Every cloud platform, SaaS tool, and managed service brings value, risk, and cost. Without disciplined vendor management, tool sprawl grows, audits hurt, renewals drift, and incident response slows. With disciplined vendor management, teams move faster, spend less, and prove decisions with evidence.

Why do common guides fall short? They over-index on features and ignore integration fit, telemetry, and renewal leverage. Vendor management must quantify workflow fit (SSO/SCIM, APIs, webhooks, logging), enforce measurable SLAs, and link usage to cost. That demands a method-led approach to vendor management, not ad-hoc opinions.

This article tackles the most overlooked questions in vendor management and gives practical rubrics, checklists, and decision paths. It shows how vendor management quantifies “fit” beyond feature lists, defines minimum viable evidence by risk tier, makes contracts machine-readable, and ties performance to renewals. It also explains when vendor selection can be run fast with curated shortlists and when supplier selection needs deeper proof via scripted demos and POCs.

The goal is simple: turn vendor management into a repeatable operating system. Use scenario scoring, anchored rubrics, and live telemetry so vendor management decisions survive audits and renewals. Treat vendor selection and supplier selection as evidence-first gates inside a continuous vendor management loop—from intake and due diligence to contracting, performance, risk, and offboarding.

1) How do you quantify “fit” beyond features for complex integrations?

Most failures aren’t about missing features; they’re about integration pain discovered too late. Quantifying “fit” means testing how a product behaves in your environment, not how it looks on a slide. Build an integration rubric and score vendors on live evidence, not promises. This keeps vendor management grounded and makes vendor selection defensible.

What does “fit” actually include?

• Identity and access: SSO (OIDC/SAML), SCIM for provisioning, role/permission granularity, admin boundaries, break‑glass access. Can you enforce least privilege and log admin actions?

• Data contracts: schema compatibility, mapping effort, transformation rules, PII handling, lineage. Do data types, keys, and encodings align without brittle glue code?

• Eventing and APIs: webhook reliability (retries, ordering, backoff), idempotency, API quotas, pagination, SDK quality. Are SLAs and error semantics documented and testable?

• Performance and SLOs: p95 latency, throughput limits, batch windows, concurrency, rate limiting behavior. Does it meet your peak and recovery scenarios?

• Observability: audit logs, structured events, correlation IDs, SIEM integration, traceability across hops. Can you detect, investigate, and prove what happened?

• Resilience and ops: maintenance windows, failover patterns, DR/BCP claims, backpressure handling, versioning/deprecation policy.

How to score objectively

• Define 5–8 scenarios with acceptance tests: example, “User provisioned via SCIM appears with least‑privilege role in <60s; deprovision removes tokens and admin rights within 120s; all actions audited.”

• Publish an anchored 0–5 rubric per criterion: 0 = not supported, 3 = works with workaround X, 5 = native support with evidence and guardrails.

• Require evidence: run scripted demos, targeted tests, or a mini‑POC; attach logs, screenshots, traces, and configs to each score. No evidence, no points.

Decision mechanics

• Gate non‑negotiables first (e.g., SSO, DPA, data residency). Vendors that fail gates exit early to keep vendor management efficient.

• Weight by impact and risk (e.g., identity 25%, data mapping 20%, eventing 20%, performance 15%, observability 10%, resilience 10%). Compute weighted scores and document trade‑offs.

• Run a quick sensitivity analysis: if identity or data mapping underperforms by one point, does the winner change? This prevents surprises post‑go‑live.

Artifacts to carry forward

• Integration fit matrix with criteria, weights, and scores

• Evidence pack: recordings, Postman collections, curl scripts, SIEM logs

• Gap and mitigation list with owners and timelines

Common pitfalls and fixes

• Pitfall: Feature counting instead of scenario fit. Fix: Use scenario scripts tied to acceptance tests.

• Pitfall: Subjective scoring. Fix: Anchored rubrics + independent scorers + variance notes.

• Pitfall: Demo theater. Fix: Score only live execution with your data and IdP.

• Pitfall: Ignoring non‑functional gates. Fix: Gate SSO/SCIM, DPA/residency, and logging before tallies.

Outcome

A quantified integration score turns vendor selection into proof. It reduces rework, shortens onboarding, and sets clear expectations for SLAs and observability. That’s vendor management done right—fast, fair, and built on evidence.

2) What’s the minimum viable evidence for due diligence by risk tier?

Due diligence fails in two predictable ways: endless questionnaires that stall projects, and rubber stamps that miss real risk. The fix is a tiered, minimum viable evidence (MVE) pack that scales with impact. Decide the tier first, request only what you will review, and set expiries so evidence stays fresh. This keeps vendor management efficient and makes vendor selection defensible.

Start by defining simple tiers tied to data sensitivity, production access, and business impact. Low-tier vendors touch no PII and have no production access. Medium-tier tools have limited PII or indirect access. High-tier systems handle customer data or sit on core workflows. Critical platforms have broad access, sensitive data, or uptime dependencies. With tiers in place, you can right-size what you ask for and how deeply you validate it.

For low tier, public security pages or trust centers, a basic architecture overview, a DPA acceptance, and a residency statement are often enough. Confirm support SLAs and uptime disclosures, and run a lightweight financial check. Medium tier steps up: recent SOC 2 Type I/II or ISO 27001, a pen test summary, vulnerability management policy, signed DPA with a subprocessor list, retention/deletion commitments, incident response and DR/BCP summaries, and a basic financial health attestation with two references.

High tier requires recent SOC 2 Type II (plus scope recency), ISO with Statement of Applicability, pen test report with remediation status, live proofs of SSO/SCIM and audit logs, a DPA with SCCs where applicable, a data flow diagram, data segregation controls, detailed DR/BCP tested within 12 months, uptime history, and a capacity plan. Financially, seek audited statements or equivalent assurance and concentration risk disclosures. Critical tier adds depth: a SOC 2 Type II with a bridge letter, an independent pen test aligned to your scope, encryption and key management specifics, secure SDLC evidence, restricted support access, regulator-facing privacy documentation if relevant, dedicated residency controls, breach simulation outcomes, architectural resilience reviews, failover test evidence, SRE runbooks, on-call coverage, and measured performance SLOs wired to your monitoring. For edge cases, consider escrow or step-in rights.

Right-size the review by reusing evidence from trust portals and validating freshness. Anything older than 12 months for high/critical should be refreshed; for low/medium, accept longer windows. Don’t rely on paper for non-negotiables—run live proofs for identity (SSO/SCIM), least-privilege roles, and audit logging. Set clear triggers for reassessment: new subprocessors, breach disclosures, major version changes, funding shocks or layoffs, and data residency shifts. Tie expiries to tier—low (24 months), medium (18), high (12), critical (6–12 with interim attestations).

Summarize outcomes in a one-page risk brief: the tier, key findings, exceptions, compensating controls, and expiry dates. Assign owners and remediation deadlines to each exception and block scope expansion until material risks are cleared. Carry the evidence index and exception log into contracting and onboarding so obligations and controls map to reality.

A few pitfalls to avoid: asking for everything from everyone, treating due diligence as a one-time comfort letter, trusting paper claims for identity and logging, and leaving exceptions unowned. A tiered MVE approach fixes these by aligning effort to impact, adding triggers and expiry, requiring live proofs where it matters, and enforcing ownership. The result is faster vendor selection, less review fatigue, and vendor management attention aimed at risks that actually matter.

3) How do you model vendor unit economics that survive audits?

Most teams negotiate price without proving value. Unit economics fixes that by tying spend to measurable usage and outcomes. The goal is simple: express cost per active user, feature, transaction, or workload hour—and reconcile it with telemetry and invoices. Done well, this anchors vendor management in facts and turns vendor selection into a financial decision, not a vibe.

Start with a clear denominator. What unit best represents value for this tool—active users per month, API calls, GB processed, incidents resolved, seats actively used, or projects delivered? Pick one to three units that map to outcomes and can be measured from reliable systems. Then wire data sources you control: IdP/SSO and SCIM for active accounts, product analytics for feature use, ITSM for ticket volumes and MTTR, cloud monitoring for throughput and latency, and AP/ERP for invoices and credits. Avoid manual counts; auditors will challenge them.

Map SKUs to usage. For each SKU or tier, document what is included, how overages are priced, and whether bundling hides material costs. Translate license counts into active usage by role: how many admins, power users, and casual users actually use the features that justify the SKU? Reconcile monthly: seats billed vs. seats active, features paid vs. features used, and any shelfware. Record deltas and reasons—enablement gap, bad provisioning hygiene, or genuine over-licensing.

Build a simple model. For each month, calculate:

• Cost per active user = total license/consumption cost ÷ active users.

• Cost per feature user = cost attributed to the feature ÷ users who used it meaningfully.

• Cost per transaction/API call/job = variable cost ÷ observed units.

Add a sensitivity view for expected growth, seasonality, and known changes (new region, data retention policy). Include credits, true-ups, CPI caps, and ramp schedules so totals match invoices.

Benchmark and set targets. Use internal comparables across teams and external benchmarks where credible. Establish a price band and a target cost per unit that supports ROI. At renewal, compare actuals to the band and script negotiation levers—term length, SKU rationalization, feature downgrades, usage commitments, and removal of shelfware.

Make it audit-ready. Keep assumptions, data sources, and reconciliation notes in the model. Link back to the vendor selection decision: the promised adoption curve, expected savings, and performance targets. If reality diverges, explain why and adjust the plan or the contract. This transparency protects decisions and strengthens leverage.

Common failure modes are predictable: counting licensed users instead of active users, ignoring feature-level adoption, relying on manual spreadsheets, and skipping reconciliation. Fix them by automating data pulls, right-sizing SKUs quarterly, and publishing a simple dashboard. When unit economics are visible, vendor management becomes a continuous calibration loop, and vendor selection aligns to outcomes that leadership can trust.

4) How do you make contract terms machine-readable end to end?

Missed notice periods, vague SLAs, and unclaimed credits usually trace back to unstructured contracts. Making terms machine-readable turns contract text into actionable data. The aim is to extract critical fields, store them in a structured model, and wire alerts and workflows so nothing gets missed. This elevates vendor management from document hunting to operational control—and makes vendor selection assumptions enforceable.

Start with a contract data model. Create fields for renewal date, autorenew status, notice period (days and delivery method), term start/end, pricing schedules, ramp tables, CPI caps, SKU entitlements, and true-up mechanics. Add SLA metrics, credit formulas, reporting cadence, maintenance windows, support tiers, and escalation paths. Include data handling clauses (DPA reference, residency, subprocessors, breach notice SLA, audit rights, exit assistance, and data deletion/return requirements). Track amendment lineage so changes overwrite the right fields.

Extract and verify. Use a combination of clause libraries, playbooked fallbacks, and human review to capture values. Even with AI extraction, legal sign-off is non-negotiable for high/critical vendors. Store source snippets alongside each field so auditors can trace a value back to the paragraph that created it. Sample new entries for quality; bad metadata is worse than none.

Operationalize with alerts and workflows. Drive calendar alerts for notice periods at 120/90/60/30 days. Trigger renewal workflows that assemble usage, performance, risk deltas, and price benchmarks. Tie SLA metrics to monitoring so credits are auto-calculated and claimed within the window. Set obligation reminders for reports, audits, security attestations, and roadmap commitments. When a subprocessor list changes or a breach occurs, route to risk review automatically.

Keep price and entitlements aligned with reality. Map SKUs and tiers to directory groups and feature flags. Reconcile invoices to entitlements monthly so shelfware is visible, and feed deltas into renewal targets. When usage shifts, update the model; stale entitlement data undermines negotiations.

Close the loop with evidence. Log who captured each field, when it was verified, and what changed with each amendment. Attach proof of notice sent, credits claimed, and audits completed. This turns contracts into an auditable system, not a filing cabinet.

Avoid common traps: burying renewal windows in unchecked PDFs, treating SLAs as marketing text, failing to map SKUs to actual usage, and ignoring amendment drift. With a machine-readable contract, vendor management can enforce what vendor selection intended, measurable service, predictable costs, and no surprises at renewal.

5) What’s the fastest defensible path when you can’t run a full RFP?

Deadlines don’t pause for procurement. When a full RFP isn’t practical, you still need a process that is fast, fair, and auditable. The goal is to compress vendor selection without sacrificing evidence. Do this by narrowing the field early, testing real workflows, and documenting decisions with artifacts leadership and auditors will accept.

Start by framing the problem tightly. Define outcomes, constraints, data sensitivity, and integration boundaries in a one-page brief. Publish must-haves up front—identity (SSO/SCIM), core APIs, data residency, baseline SLAs—so noncompliant vendors are cut immediately. Then build a curated shortlist of three to six credible options using analyst research, internal catalogs, and peer references. Document why each vendor is in or out to prevent bias accusations later.

Replace a long RFP with a two-week “RFP‑lite.” In week one, send scenario scripts and sample data to vendors and schedule scripted demos. Score only what is executed live using anchored 0–5 rubrics tied to acceptance tests. Capture evidence—recordings, logs, configs—so the vendor selection decision rests on proof. In parallel, run lean due diligence scaled to risk: SOC 2/ISO and DPA checks, subprocessor list review, incident history glance, and a quick financial health screen.

In week two, consolidate scores into a use-case matrix with weights that reflect business impact and risk. Add a thin TCO model: map SKUs to active user assumptions, include ramps and caps, and set a benchmark price band. If one high-risk assumption remains (e.g., a tricky integration or auth behavior), run a time‑boxed micro‑POC with production-like auth and logging to validate it. Close with a one-page decision memo: scores, trade-offs, residual risks with owners and expiry, and a 30/60/90-day plan.

Keep controls that reduce bias: independent scoring before consensus, variance notes explaining large deltas, and “score only what you see.” Gate non‑negotiables early so you don’t waste time on attractive but noncompliant options. Make security and privacy part of the flow, not an afterthought, proof of SSO/SCIM and audit logs should be demonstrated in the demo or micro‑POC.

This compressed path won’t replace deep evaluations for strategic platforms, but it is defensible for tactical or time‑sensitive buys. It produces the artifacts vendor management needs—scores, evidence, risk log, and a TCO band—so onboarding and renewals inherit a clean record. Fast doesn’t have to mean flimsy when vendor selection is method-led.

6) How do you validate security claims without drowning in questionnaires?

Most vendors sound secure on paper. The challenge is proving security where it matters—identity, data handling, and operational controls—without turning due diligence into a months-long slog. The goal is targeted validation that combines document review, live proofs, and trigger-based follow-ups. This keeps vendor management efficient and keeps vendor selection defensible.

Start with document triage, not document hoarding. For moderate and higher-risk tools, review recent SOC 2 Type II or ISO 27001 (with Statement of Applicability), a signed DPA, a current subprocessor list, and summaries of incident response and DR/BCP tests. Confirm dates and scope; bridge letters matter. For low-risk tools, a trust center and DPA acceptance may suffice. The point is to right-size the ask and verify freshness.

Move quickly to live proofs for non-negotiables. Require an SSO walkthrough using your IdP, including SCIM provisioning and deprovisioning with least-privilege roles. Ask for an audit logging demo: admin actions, data exports, and permission changes should be captured with timestamps and user IDs, and logs should flow to your SIEM or be exportable. Validate encryption in transit (TLS config) and at rest (KMS or vendor-managed keys) with concrete details, not just marketing statements. If the product processes events, test webhook retries, signing, and idempotency to ensure integrity.

Use a micro‑POC when paper can’t prove behavior. In one to three days, run a production-like path: authenticate via your IdP, exercise key APIs, generate audit events, and pull logs. Mask or synthesize data to limit exposure. This targeted test often reveals more truth than a 300-line questionnaire and gives vendor selection real evidence to rely on.

Track exceptions with owners and expiry dates. If SCIM role mapping isn’t granular enough, define a compensating control (e.g., periodic access review) and set a fix-by date. If the subprocessor list is incomplete, require notification SLAs and pause scope expansion until resolved. Reassess on triggers: new subprocessors, breach disclosures, significant product version changes, or leadership/ownership shifts.

Avoid common traps: treating security as a paper exercise, accepting “supports SSO” without proving SCIM and auditability, ignoring subprocessor drift, and letting exceptions age without action. With targeted validation—documents for coverage, live proofs for behavior, and a micro‑POC for edge risks—security diligence becomes fast and credible. That’s how vendor management keeps risk in check while vendor selection stays on schedule.

7) How do you detect and manage fourth‑party (subprocessor) risk in practice?

Third‑party risk often hides one layer deeper—in the vendor’s vendors. Detecting and managing subprocessor risk means discovering who those fourth parties are, monitoring changes, and enforcing controls through contracts and operations. Do it well, and vendor management gains real visibility; skip it, and vendor selection can miss critical exposure.

Start with discovery, not assumptions. Pull the current subprocessor list from the vendor’s trust center, DPA annexes, and security documentation. Cross‑check against API documentation and public disclosures to catch embedded services (analytics SDKs, email gateways, payment providers, CDN/DNS, cloud regions). For infrastructure‑heavy tools, ask directly about cloud accounts, regions, and managed services in scope.

Wire ongoing monitoring. Require contractual notification for subprocessor additions or material changes with defined lead times. Subscribe to change feeds or trust portal alerts if available. Track related news and breach disclosures on the named entities. Set internal triggers: any new subprocessor handling regulated data, expanding geography, or touching auth/keys should kick off a targeted reassessment.

Enforce controls through the contract. Bake in rights to approve or object to new subprocessors for high‑risk data, mandate minimum security standards aligned to your policies, and require timely breach notifications. For data residency, specify geographic restrictions and data localization requirements. Where feasible, require audit rights or independent assurance for critical fourth parties.

Operationalize guardrails. Map which subprocessors touch which data sets and workflows. Limit data shared to the minimum required; tokenize or hash identifiers where possible. Validate encryption, key management practices, and log flows for subprocessor paths during onboarding or a micro‑POC. If a new subprocessor is introduced mid‑contract, pause scope expansion until controls are verified.

Define a response playbook. When a subprocessor changes or has an incident, decide quickly: increase monitoring, add compensating controls, restrict certain features, or migrate away. Document decisions, owners, and timelines, and carry the record into renewal discussions. Repeated issues with a critical fourth party are a valid reason to resize, renegotiate, or replace the upstream vendor.

Avoid common pitfalls: treating the subprocessor list as static, ignoring embedded services discovered in APIs, letting objection windows lapse unnoticed, and failing to connect subprocessor risk to operational controls. With disciplined discovery, monitoring, and contractual hooks, fourth‑party oversight becomes a normal part of vendor management—and vendor selection no longer stops at the first boundary.

8) What’s the right way to tie performance to renewals without gaming?

Renewals should reflect reality, not anecdotes. The right approach is to assemble a renewal packet that blends usage, performance, risk, and price benchmarks, then make the decision visible and repeatable. Done well, this makes vendor management objective and turns vendor selection assumptions into leverage.

Start with a renewal packet, not an opinion. Pull 12 months of usage (active users, feature adoption, API/throughput), reliability (uptime, MTTR, incident count and severity), and value metrics tied to the business case (time saved, tickets deflected, pipeline influenced, cost avoided). Add unit economics—cost per active user or per transaction—and reconcile invoices to entitlements so shelfware is explicit. Include SLA attainment and any service credits earned or waived.

Layer in risk and compliance. Are attestations current? Did subprocessors change? Any unresolved exceptions or recent incidents? Capture the risk delta since last renewal and the remediation status. This prevents “security surprises” from surfacing after the contract locks in.

Anchor price benchmarks and options. Establish a target price band using internal comparables and credible external benchmarks. Model options: resize SKUs, downgrade tiers, shift to usage-based pricing, extend term for better rates, or consolidate overlapping tools. For each option, they show an impact on cost and outcomes so decision-makers can trade intelligently.

Run a 90/60/30 rhythm. At 90 days, validate outcomes and explore alternatives; at 60, script negotiation levers and align SLAs to observed metrics; at 30, finalize terms or issue non-renewal. Make “notify/no autorenew” the default until a decision is signed. This cadence stops last-minute renewals that lock in bad terms.

Prevent gaming on both sides. Use telemetry you control (IdP, product analytics, ITSM, monitoring) to measure adoption and reliability, not vendor-provided dashboards alone. Define health scores with anchored thresholds and freeze the scoring rubric one quarter before renewal. Document any waived credits with rationale to avoid silent givebacks that weaken leverage.

Close with an auditable decision. Produce a one-page memo: keep/resize/replace, rationale grounded in the packet, contract deltas, and a 30/60/90-day action plan. Attach the packet and approvals to the record. When performance, risk, and price live in one view, renewals become a fair reflection of value, and vendor management turns into a continuous improvement loop.

9) How do you prevent tool sprawl without blocking teams?

Tool sprawl happens when intake is ad hoc and visibility is poor. Preventing it requires a lightweight intake that routes by risk, checks the catalog first, and forces a fast “use existing vs. net‑new” decision—without slowing legitimate needs. The aim is to keep innovation moving while vendor management maintains control of cost, risk, and overlap.

Start with a five-question intake that any requester can complete in minutes: What outcome is needed? How many users and which teams? What data types and sensitivity levels are involved? What integrations are required (SSO, APIs, data pipelines)? What is the timeline and budget band? These answers drive routing: low-risk requests can auto-approve against an approved catalog; higher-risk requests go to security, legal, finance, and architecture for a quick review.

Make the catalog earn its keep. Maintain an up-to-date list of approved tools with owners, supported use cases, integration footprints, and license availability. When requests come in, auto-suggest existing options and show the trade-offs. If a net‑new tool is requested, require the requester to document why existing options fail—preferably with scenario examples. This transparent comparison curbs knee-jerk purchases and surfaces real gaps.

Use a simple decision tree: if an approved tool meets the top scenarios with acceptable effort, route to expansion with clear costs and timelines. If not, allow a time‑boxed evaluation using curated shortlists and scripted demos to validate the gap. Either path should produce a short decision memo so vendor selection remains visible and repeatable.

Close the loop operationally. When a net‑new tool is approved, assign an accountable owner, register entitlements and cost centers, and set a review date. Run quarterly usage audits to find shelfware and overlapping features across tools in the same category. Schedule consolidation sprints where two or more tools meaningfully overlap, and convert savings into budget for higher‑value initiatives.

Avoid common traps: a bloated intake form that nobody completes, a stale catalog that recommends dead tools, and approvals that take weeks. Keep intake short, catalog current, and approvals time‑boxed (e.g., 5 business days for low/medium risk). With this design, teams get what they need quickly, while vendor management contains sprawl and preserves leverage at renewal.

10) How do you run vendor offboarding with zero residual risk?

Exits fail when access lingers, data persists, or obligations get lost. Zero‑residual‑risk offboarding treats termination as a controlled project with proof at every step. The objective is simple: revoke access, recover or delete data, unwind dependencies, close financials, and document evidence—so nothing comes back to bite you after the contract ends.

Start with a dated termination plan aligned to notice requirements. Confirm the effective end date, final service window, and exit assistance terms. Identify system owners, environments, and integrations in scope. Freeze scope changes and new user provisioning immediately to prevent drift. If the exit is partial (one product of a suite), isolate entitlements and endpoints to avoid collateral damage.

Tear down access methodically. Remove SSO apps and SCIM provisioning, revoke API keys and personal access tokens, disable admin roles, and close vendor support portals. Validate removal via IdP logs and the vendor’s own audit trails. For service‑to‑service links, rotate secrets in dependent systems and verify failed authentication attempts to ensure nothing still connects in the background.

Handle data with care and proof. Decide on export, migration, or deletion per data class. For exports, capture data dictionaries, formats, and checksums; verify completeness against record counts. For deletions, require signed deletion or return certificates that specify scope, backups, and any legal holds. If the vendor uses subprocessors, confirm downstream deletion as well. Keep evidence in your system of record with timestamps and sign‑offs.

Unwind integrations and dependencies. Disable webhooks, scheduled jobs, outbound connectors, and IP allowlists. Remove DNS entries, OAuth apps, and firewall rules. Update runbooks, CMDB entries, and architecture diagrams. If you’re transitioning to a replacement system, run parallel validation until parity is proven on critical paths, then cut over with a rollback plan.

Close financials and obligations. Reconcile final invoices, apply earned service credits, and collect any prepaid balances or deposits. Ensure notice compliance is documented (method, date, recipient). Track return of leased hardware or escrow materials if applicable. Where contracts require exit assistance, log hours delivered and outcomes achieved to avoid disputes.

Document everything. Produce an offboarding packet: termination notice proof, access teardown logs, export/deletion certs, dependency cleanup list, final financial reconciliation, and a short lessons‑learned. Feed those lessons back into intake criteria, vendor selection assumptions, and contract templates (especially exit and data clauses).

Common failure modes are predictable: leaving SSO apps or tokens active, accepting generic deletion statements without scope, forgetting embedded webhooks, and losing track of renewal dates mid‑transition. A disciplined, evidence‑first offboarding playbook prevents all four. It’s the last mile of vendor management—and the difference between a clean exit and lingering exposure.