Vendor Risk Review Checklist for Critical Vendors

Not every vendor deserves the same level of review.

A low-risk office supplier is not the same as a cloud provider.
A marketing tool is not the same as an identity platform.
A one-time contractor is not the same as a managed service provider.
A vendor with no data access is not the same as a vendor processing customer data.
A non-critical service provider is not the same as a vendor supporting a customer-facing product, payment process, AI system, cyber control, or critical business service.

That is why vendor risk reviews should be risk-based.

But many third-party risk programs still struggle with critical vendors.

The vendor was approved, but the contract is missing key terms.
The cyber review was completed, but evidence is expired.
The privacy review was done, but the data processing scope changed.
The business owner says the vendor is important, but criticality was never documented.
The vendor supports a critical service, but resilience evidence is missing.
The vendor uses AI, but no AI governance review happened.
An issue is open, but renewal is moving forward.
A risk was accepted, but the expiration date passed.
The dashboard says the vendor is approved, but no one can explain the conditions.

That is not vendor governance.

That is hidden dependency risk.

A critical vendor risk review should help teams answer:

• Why is this vendor critical?

• Who owns the relationship?

• What service does the vendor provide?

• What data, systems, assets, services, or customers are affected?

• What contract obligations apply?

• What cyber, privacy, AI, resilience, compliance, and financial risks exist?

• What evidence supports the review?

• What issues remain open?

• What risks are accepted?

• What decision is needed before approval, renewal, expansion, or escalation?

This checklist gives third-party risk, procurement, legal, cyber, privacy, resilience, AI governance, compliance, and business owners a practical way to review critical vendors in a Connected GRC program.

The goal is not to slow every vendor decision.

The goal is to make sure critical vendor decisions are visible, evidenced, owned, and defensible.

What is a critical vendor?

A critical vendor is a third party whose failure, disruption, security weakness, compliance gap, data issue, contract issue, or operational failure could materially affect important business services, customers, regulated activities, sensitive data, financial reporting, operational resilience, cyber risk, AI governance, or executive commitments.

A vendor may be critical because it:

• supports a critical business service

• processes customer, employee, financial, or sensitive data

• has privileged or production system access

• provides cloud, identity, payment, security, data, AI, or infrastructure services

• supports financial reporting or SOX-relevant processes

• supports regulated business activity

• is difficult to replace

• creates concentration risk

• is part of incident response, resilience, or recovery capability

• creates customer assurance, regulatory, or contractual exposure

Criticality is not the same as spend.

A low-cost vendor may be critical if it processes sensitive data or supports a critical service.

A high-spend vendor may be low risk if it has no operational, data, cyber, or regulatory exposure.

Criticality should be based on business impact.

Not only contract value.

Why critical vendor reviews matter

Critical vendor reviews matter because third-party risk is not only a procurement issue.

It can affect:

• cyber risk

• privacy risk

• operational resilience

• regulatory readiness

• customer trust

• legal obligations

• financial reporting

• AI governance

• business continuity

• incident response

• board reporting

• executive risk appetite

NIST CSF 2.0 makes cybersecurity supply-chain risk more explicit through the Govern function, and NIST describes C-SCRM as covering risk across ICT and OT product and service supply chains throughout the system life cycle. For financial entities in the EU, DORA has applied since January 17, 2025, and includes ICT third-party risk management as one of its key areas.

The practical point is simple:

Critical vendors should be reviewed as business dependencies, not just third-party records.

That means vendor reviews need to connect to contracts, data, cyber controls, privacy assessments, resilience plans, incidents, issues, evidence, renewals, risk acceptance, dashboards, and decisions.

How to use this checklist

Use this checklist before:

• approving a critical vendor

• renewing a critical vendor

• expanding vendor scope

• approving vendor access to new data

• approving vendor access to new systems

• accepting vendor risk

• escalating vendor issues

• responding to a vendor incident

• reviewing critical vendor concentration

• preparing executive or board reporting

For each item, mark:

• Green: complete and acceptable

• Yellow: incomplete, pending, or acceptable with conditions

• Red: missing, unacceptable, overdue, or requiring escalation

For any yellow or red item, assign:

• owner

• action

• due date

• evidence required

• decision needed

• escalation path

The checklist should not become a static questionnaire.

It should feed vendor issues, remediation plans, risk acceptances, dashboards, and renewal decisions.

Critical Vendor Risk Review Checklist

Section 1: Vendor identity and ownership

1. Is the vendor record complete?

A critical vendor record should include:

• legal vendor name

• common business name

• parent company, where relevant

• subsidiaries or related entities

• vendor status

• service category

• business unit using the vendor

• vendor owner

• contract owner

• risk tier

• criticality

• renewal date

• review status

A vendor cannot be governed if the record is incomplete.

Healthy answer: The vendor record is complete, current, and linked to owners, contract, service, and risk tier.

Warning sign: The vendor is widely used, but ownership, contract, and criticality are unclear.

2. Is there a named business owner?

Every critical vendor needs a business owner.

The business owner should understand:

• why the vendor is used

• what service the vendor provides

• which business processes depend on the vendor

• whether the vendor is replaceable

• what would happen if the vendor failed

• which users, customers, or services would be affected

The business owner should not assume procurement, legal, cyber, or third-party risk owns the vendor relationship.

Healthy answer: A named business owner is accountable for the relationship and business impact.

Warning sign: The vendor is owned by “Procurement,” “IT,” or “the business” without a named accountable owner.

3. Is there a contract owner?

The contract owner should know:

• current contract status

• renewal date

• notice period

• termination rights

• key obligations

• service levels

• data processing terms

• security obligations

• incident notification clauses

• business continuity obligations

• audit rights

• subcontractor or fourth-party terms

• AI or data-use terms, where relevant

Contract ownership matters because many vendor risk controls depend on contract language.

Healthy answer: Contract owner, renewal date, and key contract obligations are linked to the vendor record.

Warning sign: Vendor risk review is complete, but the contract is not linked or renewal terms are unknown.

4. Is criticality documented and justified?

Criticality should be documented with rationale.

Ask:

• Does the vendor support a critical service?

• Does the vendor process sensitive data?

• Does the vendor have system access?

• Does the vendor support regulated activity?

• Does the vendor support financial reporting?

• Would vendor failure disrupt customers or operations?

• Is the vendor difficult to replace?

• Does the vendor create concentration risk?

Healthy answer: Criticality is assigned with documented rationale and review date.

Warning sign: Vendor is labeled “critical” or “high risk” without explanation.

5. Is the vendor relationship current?

Before reviewing risk, confirm the vendor relationship is current.

Check:

• active or inactive status

• services currently provided

• business units using the vendor

• geographic scope

• product or service changes

• new data access

• new system access

• contract changes

• renewal or termination status

Vendor risk changes when the relationship changes.

Healthy answer: The vendor record reflects current service scope and usage.

Warning sign: The review is based on last year’s vendor scope.

Section 2: Service, dependency, and business impact

6. Is the service provided clearly documented?

The vendor record should explain what the vendor actually does.

Examples:

• cloud infrastructure

• identity management

• payment processing

• data processing

• customer support platform

• HR platform

• managed security service

• AI model provider

• business continuity provider

• financial reporting system

• marketing automation

• legal or compliance service

A vague vendor description makes risk review harder.

Healthy answer: The service is described in operational terms.

Warning sign: The vendor description only says “software,” “consulting,” or “platform.”

7. Is the vendor linked to business processes or services?

Critical vendor risk is easier to understand when the vendor is linked to:

• business process

• product

• customer-facing service

• internal service

• critical service

• legal entity

• geography

• business unit

• data flow

• system or asset

Operational resilience depends on understanding these links.

Healthy answer: The vendor is linked to the services and processes it supports.

Warning sign: The vendor is reviewed in isolation from business impact.

8. Is operational impact assessed?

Ask what would happen if the vendor failed.

Consider:

• service outage

• data loss

• customer impact

• employee impact

• financial reporting disruption

• regulatory breach

• missed SLA

• business continuity impact

• reputational impact

• manual workaround availability

• recovery time

Healthy answer: Operational impact is assessed and linked to resilience or continuity planning.

Warning sign: The vendor is marked critical, but no impact analysis exists.

9. Is concentration risk considered?

A vendor may be critical because many processes depend on it.

Ask:

• How many business units use this vendor?

• How many critical services depend on it?

• Are there alternatives?

• Are multiple vendors dependent on the same provider?

• Does the vendor depend on a common cloud, data, AI, or infrastructure provider?

• Would a single failure create broad impact?

Healthy answer: Concentration risk is assessed for critical vendors and key provider categories.

Warning sign: Vendor risk is reviewed one vendor at a time, with no dependency view.

10. Are fourth parties or subcontractors identified?

Critical vendors often rely on their own vendors.

Ask:

• Does the vendor use subcontractors?

• Does the vendor rely on cloud or AI providers?

• Are subprocessors listed?

• Are critical subcontractors disclosed?

• Are notification obligations defined?

• Are fourth-party risks monitored?

• Are subcontractor changes reviewed?

Healthy answer: Material subcontractors and fourth-party dependencies are documented.

Warning sign: The vendor outsources critical services, but the organization has no visibility.

Section 3: Contract and legal risk

11. Is the current contract linked and reviewed?

The review should link to the current contract.

Check:

• contract effective date

• renewal date

• termination rights

• notice period

• service description

• pricing and scope

• amendments

• data processing addendum

• security addendum

• AI addendum, where relevant

• business continuity terms

Healthy answer: The current contract and relevant amendments are linked.

Warning sign: Review relies on an outdated contract or unsigned amendment.

12. Are security and privacy obligations documented?

Critical vendor contracts should address risk-relevant obligations.

Examples:

• security standards

• incident notification

• audit rights

• data protection

• data location

• data retention

• subprocessors

• breach notification

• encryption

• access control

• business continuity

• termination assistance

• return or destruction of data

Healthy answer: Key contract obligations are extracted or linked to the vendor risk record.

Warning sign: Legal terms exist but are not connected to vendor risk monitoring.

13. Are service levels and remedies clear?

For critical vendors, service levels matter.

Check:

• uptime commitments

• recovery commitments

• support response times

• incident response times

• reporting obligations

• service credits

• escalation paths

• termination rights

• remedies for repeated failure

Healthy answer: Service levels are documented and monitored where relevant.

Warning sign: The business depends on the vendor, but service-level commitments are unclear.

14. Are audit and assurance rights sufficient?

For critical vendors, the organization may need assurance access.

Check:

• audit rights

• right to request evidence

• right to review SOC reports or certifications

• regulatory cooperation

• right to assess subcontractors, where needed

• right to receive incident and control information

• customer or regulator access considerations

Healthy answer: Audit and assurance rights support the vendor’s risk level.

Warning sign: The vendor is critical, but the organization has limited ability to obtain assurance.

15. Are contract exceptions tracked?

Contract exceptions should be visible.

Examples:

• missing incident notification clause

• limited audit rights

• missing data deletion terms

• weak subcontractor terms

• missing service continuity terms

• vendor refuses security addendum

• AI data-use terms unresolved

Healthy answer: Contract exceptions are tracked as vendor issues, exceptions, or risk acceptances.

Warning sign: Legal exceptions are documented in contract notes but not in the vendor risk workflow.

Section 4: Cyber and information security risk

16. Is the vendor cyber review complete?

Critical vendor cyber review should include:

• security questionnaire

• SOC report or equivalent evidence

• ISO or other certification, where relevant

• penetration test summary, where appropriate

• vulnerability management process

• access control process

• encryption practices

• incident response process

• logging and monitoring

• cloud security posture, where relevant

• security exceptions

• open cyber issues

NIST CSF 2.0’s supply-chain risk emphasis makes this type of review especially important for vendors that support ICT, OT, cyber controls, or critical business services.

Healthy answer: Cyber review is complete, current, and linked to evidence and issues.

Warning sign: Cyber review is marked complete, but evidence is expired or issues are not dispositioned.

17. Does the vendor have system access?

System access increases risk.

Document:

• production access

• admin access

• remote access

• API access

• cloud access

• network access

• privileged access

• service accounts

• support access

• access review process

Healthy answer: Vendor system access is documented and reviewed.

Warning sign: Vendor has production or privileged access but no access review evidence.

18. Is vendor evidence current?

Evidence may include:

• SOC 2 report

• ISO certificate

• SIG or questionnaire

• penetration test summary

• security whitepaper

• vulnerability management evidence

• incident response evidence

• business continuity test evidence

• cyber insurance certificate, where relevant

Check:

• report period

• expiration date

• scope

• exceptions

• complementary user entity controls

• bridge letter, where needed

• reviewer acceptance

Healthy answer: Vendor evidence is current, reviewed, accepted, and linked to vendor controls.

Warning sign: Evidence exists but is expired, out of scope, or not reviewed.

19. Are vendor cyber issues tracked to remediation?

Cyber issues may include:

• expired evidence

• unresolved SOC exceptions

• weak access controls

• missing encryption

• inadequate incident notification

• delayed vulnerability remediation

• weak subcontractor management

• missing logging

• missing business continuity evidence

Each issue should have:

• owner

• severity

• due date

• remediation plan

• evidence required

• validation status

• renewal impact

• risk acceptance, if applicable

Healthy answer: Cyber issues are tracked and connected to remediation and renewal decisions.

Warning sign: Cyber concerns are noted in a review but not tracked as issues.

20. Has vendor incident history been reviewed?

Critical vendor review should include incident history.

Ask:

• Has the vendor reported incidents?

• Did incidents affect your organization?

• Were customers, data, services, or systems affected?

• Was root cause documented?

• Was remediation completed?

• Did incidents reveal control weakness?

• Did the incident change vendor risk tier?

• Did it affect renewal or contract terms?

Healthy answer: Vendor incidents are linked to risk assessment, issues, and renewal decisions.

Warning sign: Vendor incidents are tracked separately from the vendor risk record.

Section 5: Privacy, data, and AI risk

21. What data does the vendor access or process?

Document data exposure.

Examples:

• customer data

• employee data

• financial data

• confidential business data

• regulated data

• sensitive personal data

• authentication data

• logs

• AI prompts and outputs

• training data

• metadata

Healthy answer: Data categories, sensitivity, and data owners are documented.

Warning sign: Vendor is approved without clear data classification.

22. Is privacy review complete?

Privacy review should cover:

• processing purpose

• data categories

• data subjects

• lawful or contractual basis, where relevant

• transfer mechanism, where relevant

• data retention

• deletion

• subprocessors

• privacy incidents

• DPIA or PIA, where required

• data processing terms

• privacy issues

Healthy answer: Privacy review is complete and linked to vendor, contract, data, and issues.

Warning sign: Privacy review is done in a separate document with no link to vendor approval.

23. Does the vendor use AI or provide AI-enabled functionality?

AI vendor risk should be identified.

Ask:

• Does the vendor provide AI-enabled features?

• Does the vendor use your data for AI processing?

• Does the vendor use data for training?

• Are prompts or outputs retained?

• Are model providers or subprocessors involved?

• Are AI outputs used in customer, employee, or regulated decisions?

• Is AI use covered in contract terms?

• Is AI governance review required?

Healthy answer: AI functionality, data use, contract terms, and governance review are documented.

Warning sign: AI features are enabled without AI governance, legal, privacy, or cyber review.

24. Are data retention and deletion obligations clear?

For critical vendors, data lifecycle matters.

Check:

• data retention period

• deletion requirements

• return of data

• backup retention

• deletion certification

• termination assistance

• subprocessors’ deletion obligations

• evidence of deletion, where required

Healthy answer: Retention and deletion obligations are documented and monitored.

Warning sign: Vendor processes sensitive data, but deletion and retention terms are unclear.

25. Are cross-border or jurisdictional risks reviewed?

Some vendors create geographic or jurisdictional risk.

Review:

• data location

• vendor location

• subprocessor location

• cross-border transfer requirements

• regulatory restrictions

• customer commitments

• government access risk, where relevant

• local law considerations

Healthy answer: Jurisdictional risk is reviewed where relevant and linked to legal or privacy approval.

Warning sign: Vendor geography or data transfer risk is unknown.

Section 6: Resilience and continuity

26. Does the vendor support a critical service?

If yes, resilience review should be stronger.

Ask:

• Which critical service depends on the vendor?

• What business process is affected?

• What recovery objective applies?

• What alternative exists?

• What manual workaround exists?

• What would happen if the vendor failed?

Healthy answer: Critical service dependency is documented and linked to resilience records.

Warning sign: Vendor is critical to operations, but not linked to business continuity or resilience planning.

27. Is vendor business continuity evidence current?

Evidence may include:

• business continuity plan summary

• disaster recovery test

• incident response plan

• resilience certification

• recovery test results

• backup and recovery evidence

• service continuity commitments

• crisis communication process

Healthy answer: Resilience evidence is current, reviewed, and aligned to criticality.

Warning sign: Vendor is critical, but continuity evidence is missing or expired.

28. Are recovery expectations defined in the contract?

For critical vendors, contract terms should support resilience expectations.

Check:

• recovery time objective

• recovery point objective

• service continuity commitments

• incident communication

• escalation contacts

• testing rights

• reporting commitments

• termination or exit support

Healthy answer: Recovery expectations are documented and contractually supported where appropriate.

Warning sign: Business depends on vendor recovery, but contract terms are vague.

29. Is exit or substitution planning documented?

Critical vendors should have some exit thinking.

Ask:

• Can the vendor be replaced?

• How long would replacement take?

• Is data export possible?

• Is transition support defined?

• Is there an alternate provider?

• Is there an internal workaround?

• Are exit obligations in the contract?

• Has exit risk been assessed?

Healthy answer: Exit or substitution risk is documented for critical vendors.

Warning sign: Vendor is critical and hard to replace, but no exit plan exists.

30. Has vendor resilience been tested or reviewed recently?

For critical vendors, review should not be one-time.

Ask:

• When was continuity evidence last reviewed?

• Were test results acceptable?

• Were issues identified?

• Were issues remediated?

• Did any incidents occur since last review?

• Has the vendor changed infrastructure or subcontractors?

Healthy answer: Resilience review is current and tied to monitoring cadence.

Warning sign: Resilience evidence was reviewed once during onboarding and never updated.

Section 7: Issues, exceptions, and risk acceptance

31. Are open vendor issues visible?

Critical vendor issues should be visible before approval or renewal.

Issue types may include:

• cyber evidence missing

• privacy review incomplete

• contract exception

• resilience evidence expired

• AI terms unresolved

• unresolved incident

• failed SLA

• missing subprocessor details

• overdue remediation

• risk acceptance expired

Healthy answer: Open vendor issues are linked to approval, renewal, dashboards, and decisions.

Warning sign: Vendor approval moves forward while issues remain hidden in email.

32. Are issue owners and due dates assigned?

Each vendor issue should have:

• owner

• severity

• root cause

• remediation plan

• due date

• evidence required

• validation method

• renewal impact

• escalation rule

Healthy answer: Issues are actionable and tracked to closure.

Warning sign: Issues are listed but not owned.

33. Are exceptions documented and time-bound?

Vendor exceptions may include:

• missing SOC report

• contract clause exception

• privacy review pending

• cyber review pending

• resilience evidence unavailable

• AI terms unresolved

• onboarding before full review

Exceptions should include:

• reason

• approver

• conditions

• expiration

• compensating controls

• evidence

• monitoring

• renewal rule

Healthy answer: Exceptions are approved, time-bound, evidenced, and monitored.

Warning sign: Exceptions are approved informally and never revisited.

34. Is risk acceptance required?

Risk acceptance may be needed when:

• open issues remain before approval

• missing evidence cannot be obtained

• contract terms remain weak

• vendor cannot remediate before renewal

• residual cyber, privacy, AI, or resilience risk remains

• business wants to proceed despite risk

Risk acceptance should include:

• residual risk

• business rationale

• approver

• evidence

• conditions

• expiration or review date

• monitoring requirement

Healthy answer: Residual risk is formally accepted when needed.

Warning sign: The business proceeds because the vendor is needed, but risk acceptance is not documented.

35. Are repeat vendor issues identified?

Repeat issues may indicate systemic risk.

Examples:

• vendor repeatedly misses evidence deadlines

• recurring SLA failures

• repeated security findings

• repeated incidents

• repeated privacy issues

• recurring contract exceptions

• repeated renewal delays

Healthy answer: Repeat issues are tracked and escalated.

Warning sign: Each vendor issue is treated as isolated.

Section 8: Approval, renewal, and escalation

36. Is the approval decision documented?

Approval should include:

• approver

• date

• decision

• conditions

• evidence reviewed

• issues considered

• risk acceptance, if applicable

• next review date

Possible outcomes:

• approved

• approved with conditions

• rejected

• pending more evidence

• escalated

• risk accepted

• renewal blocked

• offboarding required

Healthy answer: Approval decision is documented and linked to evidence.

Warning sign: Approval is given in a meeting or email but not recorded in the system of record.

37. Are approval conditions tracked?

Conditional approval should create follow-up.

Examples:

• vendor must provide SOC report by a date

• contract clause must be amended

• privacy issue must be remediated

• access must be limited

• AI feature must remain disabled

• business continuity evidence must be submitted

• renewal cannot proceed until issue closes

Healthy answer: Approval conditions become tracked actions or issues.

Warning sign: Conditions are stated but not monitored.

38. Is renewal risk reviewed before the renewal date?

Critical vendor review should happen before renewal pressure.

Check:

• renewal date

• notice period

• open issues

• expired evidence

• contract exceptions

• incidents

• business owner approval

• legal review

• cyber review

• privacy review

• resilience review

• risk acceptance status

Healthy answer: Renewal review starts early enough to act.

Warning sign: Renewal is discovered too late to address open risk.

39. Is escalation needed?

Escalation may be needed when:

• critical vendor has high-risk open issue

• renewal deadline is near

• evidence is expired

• contract terms are unacceptable

• vendor incident affects operations

• privacy or cyber risk is outside appetite

• critical service dependency is unresolved

• business wants to proceed despite risk

Escalation may go to:

• vendor owner

• executive sponsor

• third-party risk committee

• operating committee

• legal

• CISO

• privacy officer

• resilience owner

• board or board committee, where appropriate

Healthy answer: Escalation criteria are defined and used.

Warning sign: Vendor risk escalates only after an incident or audit finding.

40. Is dashboard status updated?

After review, update:

• vendor risk status

• evidence status

• issue status

• approval status

• renewal status

• risk acceptance status

• contract exception status

• critical service dependency

• executive dashboard

• board reporting item, where relevant

Healthy answer: Dashboards reflect the latest vendor risk decision.

Warning sign: Vendor risk status in the dashboard does not match actual conditions.

Summary Critical Vendor Risk Review Checklist

Use this table before approval, renewal, or escalation.

Critical vendor review outcomes

A critical vendor review should produce one of these outcomes.

The outcome should be documented.

It should not live only in meeting notes.

Vendor risk dashboard metrics

A critical vendor dashboard should show:

A vendor dashboard should not only show review completion.

It should show risk and decisions.

How Connected GRC improves critical vendor reviews

Connected GRC improves critical vendor reviews by linking:

• vendor

• business owner

• contract

• data

• service

• criticality

• cyber review

• privacy review

• resilience review

• AI review

• evidence

• incidents

• issues

• remediation

• risk acceptance

• approval decision

• renewal

• dashboard

SmartSuite’s Third-Party Risk Management page describes connected vendor onboarding, assessments, issues, remediation, linked vendors, risks, controls, evidence, and dashboards. That is the structure critical vendor reviews need.

In a disconnected model, teams ask:

“Did procurement approve the vendor?”

In a connected model, teams ask:

“Is the vendor acceptable given the service it supports, the data it processes, the systems it accesses, the contract terms, the evidence reviewed, the issues open, the risks accepted, and the decision needed before renewal?”

That is a better question.

Common critical vendor review mistakes

Mistake 1: Treating criticality as the same as spend

Vendor criticality should be based on business impact, data, systems, services, resilience, and regulatory exposure.

Mistake 2: Reviewing vendors only at onboarding

Critical vendors need ongoing monitoring and renewal review.

Mistake 3: Ignoring contract terms

Cyber, privacy, resilience, incident, and audit expectations often depend on contract language.

Mistake 4: Accepting expired evidence

Expired or out-of-scope evidence may not support current vendor risk.

Mistake 5: Letting renewals proceed with hidden issues

Open issues should be visible before renewal decisions.

Mistake 6: Ignoring AI functionality

Vendors may introduce AI features that change data, legal, privacy, cyber, and monitoring risk.

Mistake 7: Approving exceptions without expiration

Vendor exceptions should be time-bound and monitored.

Mistake 8: Not linking vendors to critical services

Without service linkage, vendor risk may be under-prioritized.

A practical test for one critical vendor

Pick one critical vendor.

Ask whether your GRC model can quickly show:

• business owner

• contract owner

• service provided

• criticality rationale

• contract

• renewal date

• data accessed

• system access

• critical service dependency

• cyber evidence

• privacy review

• AI review, if relevant

• resilience evidence

• open issues

• incidents

• contract exceptions

• risk acceptance

• approval conditions

• renewal decision

• dashboard status

If answering those questions requires procurement files, legal notes, cyber spreadsheets, privacy assessments, shared folders, and emails, critical vendor risk is not connected enough.

That is common.

It is also the opportunity.

Final thought

Critical vendor risk is business risk.

It is not just procurement risk.
It is not just contract risk.
It is not just cyber risk.
It is not just privacy risk.
It is not just operational resilience risk.

It is all of those things connected.

A strong critical vendor review helps the organization understand who owns the vendor, what service the vendor provides, what data and systems are involved, what contract terms apply, what evidence supports the review, what issues remain open, what risks are accepted, and what decision is needed before approval or renewal.

That is the purpose of this checklist.

Not to slow down every vendor.

To make critical vendor decisions trustworthy.