Vendor risk management policy template: ten sections you can copy and adapt

A vendor risk management policy is a short document with a big job: it tells everyone in the company what must happen before a third party is trusted with data, systems or critical services, and it tells an auditor what standard to test you against. Most templates online are either a page of generalities or forty pages written for a bank. This one is sized for a small or mid-sized US business and written to be copied.

Each section below gives policy text you can paste into your own document, followed by a short note on how to adapt it. Replace the words in bold with your own values. Keep the policy to what must happen and who owns it; put the how-to detail in procedures the policy references.

1. Purpose

This policy establishes how the Company identifies, assesses, manages and monitors the risks that arise from relying on third parties. Its aim is to ensure that vendors with access to Company data, systems or facilities, or on whom critical operations depend, are assessed before engagement and kept under review in proportion to the risk they present.

Adapting it: if a customer contract or regulation drove the policy (a SOC 2 report, HIPAA business associates, GLBA service providers), name it here in one sentence. It explains to readers why the rules exist.

2. Scope

This policy applies to all vendors, suppliers, contractors, service providers and cloud services that process, store or access Company or customer data, connect to Company systems, or provide services whose failure would materially affect operations. It applies to all employees who select, contract with or manage such vendors. Purchases below $X with no data or system access are out of scope unless a Vendor Owner requests an assessment.

Adapting it: include free tools and browser extensions explicitly. They are the vendors that most often slip past procurement because nobody signs a purchase order.

3. Roles and responsibilities

Adapting it: in a company of thirty, one person may hold three of these roles. That is fine, but the Executive Approver should not be the same person who ran the assessment, so there is a second pair of eyes on the riskiest decisions.

4. Vendor risk tiering

Every in-scope vendor is assigned a risk tier before engagement, based on (a) the most sensitive data or system access it will have, (b) the operational impact of its failure, and (c) how hard it would be to replace. Tiers are Critical, High, Medium and Low. The tier and the reasoning for it are recorded in the vendor register and re-evaluated at every review and whenever the vendor’s access or role changes.

Adapting it: define the tier criteria in an appendix rather than the body, so you can refine them without re-approving the whole policy. The three-question method in Vendor risk tiering: how to classify third parties and set a review cadence works as that appendix almost as written.

5. Due diligence by tier

No vendor may receive Company data or system access, and no contract may be signed, until due diligence for its tier is complete and the result is recorded. Minimum requirements are:

Adapting it: say what happens with the findings, not only what is collected. Add a line such as “Findings rated high must be remediated, accepted under Section 9, or the vendor rejected.” For the questions themselves, see Vendor risk assessment questionnaire: what to ask, and how to score the answers; for US identity, tax and sanctions checks, US vendor onboarding: W-9, SAM.gov, OFAC, insurance and bank verification.

6. Contract requirements

Contracts with Critical and High vendors must include, at minimum: confidentiality obligations; security requirements appropriate to the data involved; breach notification within 72 hours of discovery; a right to request security evidence or audit reports; restrictions on subcontracting and notice of new subprocessors; data return and deletion on termination; and, where personal data is processed, data processing terms that meet applicable law. Deviations require an exception under Section 9.

Adapting it: large SaaS vendors will not negotiate their paper. That is acceptable if you read their standard terms, confirm they cover the list, and record where each item lives. Missing items become an exception, not a silent gap.

7. Monitoring and reassessment

Vendors are reassessed on the following cadence: Critical annually; High every 12 to 18 months; Medium every 24 to 36 months; Low on material change only. A review is also triggered by a security incident at the vendor, a change of ownership, a new data type or integration, expiry of the evidence the last assessment relied on, or repeated service failures. The Policy Owner reports overdue reviews to leadership each quarter.

Adapting it: set the next due date when each review closes and store it in the register. A cadence that depends on someone remembering is the one that slips.

8. Offboarding

When a vendor relationship ends, the Vendor Owner ensures that all access (accounts, API keys, integrations, VPN and physical access) is revoked; Company data is returned or deleted, with written confirmation of deletion obtained for Critical and High vendors; and the vendor register is updated with the end date. Records of the relationship are retained for N years.

Adapting it: the forgotten API key is the classic finding. Tie offboarding to the same ticket or checklist your IT team uses for employee departures.

9. Exceptions

Where a requirement of this policy cannot be met, the Vendor Owner submits a written exception stating the requirement, the reason, compensating controls and a proposed expiry date not exceeding 12 months. Exceptions for Critical vendors require Executive Approver sign-off. All exceptions are recorded in the vendor register and reviewed before expiry.

Adapting it: an exception process is not a weakness. Auditors expect some; what they flag is an exception with no owner, no expiry or no record.

10. Policy review and approval

This policy is reviewed at least annually by the Policy Owner and approved by the Executive Approver. Changes are communicated to all Vendor Owners. Version, approval date and approver are recorded below.

Adapting it: add a small version table at the end of the document (version, date, author, approver, summary of change). It is the first thing an auditor looks at.

Where auditors look

SOC 2. Criterion CC9.2 covers assessing and managing risks from vendors and business partners. In a Type II audit, the auditor reads the policy to learn your defined process, then samples vendors from the register and checks that each one was tiered, assessed and reviewed as the policy says, across the whole audit period. If your policy promises annual reviews of Critical vendors, a Critical vendor last reviewed eighteen months ago is an exception in the report. More in SOC 2 vendor management: what auditors expect from your third-party programme.

ISO/IEC 27001:2022. Annex A 5.19 expects defined processes for supplier risk, 5.20 security requirements in supplier agreements, 5.21 the ICT supply chain, 5.22 monitoring and managing change in supplier services, and 5.23 the acquisition, use and exit of cloud services. Sections 4 to 8 of this template map to those controls. The auditor will also check that the policy was approved by management and communicated, and will sample supplier records. See ISO 27001 supplier relationships: meeting Annex A 5.19–5.23 with evidence.

In both cases the lesson is the same: write only what you will actually do. A modest policy followed consistently passes; an ambitious one followed half the time produces findings.

Before you publish it

• Every bold placeholder replaced with a real value or name.
• Tier criteria appendix attached and consistent with Section 5.
• Contract minimums confirmed with whoever signs contracts.
• Vendor register exists with tier, owner, last review and next due date for each vendor.
• Approval recorded with a date and an approver name.
• Policy shared with every Vendor Owner, and that fact recorded.

The policy is only as good as the records behind it. VendorVett keeps the vendor register, the assessment for each tier and a dated audit trail of every decision, which is the evidence an auditor asks for once they have read the policy. For the wider program this policy governs, see Third-party risk management for small businesses: a programme without a GRC team and Vendor due diligence: a practical guide for small and mid-sized businesses.