The vendor management policy template, tiered by reach
Which vendors get assessed, how hard, how often, and what the contract has to say.
A vendor management policy template decides which vendors get assessed, how much assurance you collect from each, how often you look again and what the contract must say. SOC 2 tests it against CC9.2, which expects risks from vendors and business partners to be assessed and managed.1
The policy below tiers vendors by what they can reach rather than by what they cost. The questionnaire it refers to is its own template.
What an auditor checks
The register first, then a sample of vendors from it. For each vendor in the sample:
- A tier that matches its reach. A logging tool that sees request headers is not peripheral, whatever it costs.
- The assurance the tier requires. A current report, or answers in writing, collected before the vendor was used.
- A review record. Who read the report, when, and what they concluded.
- Owned user controls. The vendor report lists controls it assumes you run. Each one should have an owner at your company.
The same list appears in your own report, pointed at your customers. Complementary user entity controls explains how they work in both directions.
The full policy text
Section 2 sets the tiers. Section 6 is the four-step read of a vendor report, starting with a check that a licensed CPA firm issued it.2
[Company name]
Vendor Management Policy
- Owner
- [Security owner role]
- Approved by
- [Policy approver role]
- Effective date
- [Effective date]
- Next review
- [Next review date]
- Version
- [Version]
1. Purpose and scope
This policy supports the SOC 2 common criteria CC9.2 by establishing vendor risk management requirements.
This policy applies to all third-party vendors and subservice organizations.
2. Vendor tiers
Vendors are tiered by what they can reach, not by what they cost. The tier sets how much assurance is collected and how often the vendor is reviewed.
| Tier | What the vendor can reach | Assurance collected | Review |
|---|---|---|---|
| 1, critical | Customer data, production systems, the identity provider or source code | A current SOC 2 report or equivalent, plus the security questionnaire where the report leaves gaps | Every 12 months |
| 2, limited | Internal company data only, with no production access | The shorter security questionnaire | Every 24 months |
| 3, peripheral | No company data and no access to Company systems | A register entry only | When its reach changes |
3. Vendor risk assessment
- Vendors are assessed for risk before onboarding and again on the review schedule for their tier.
- Critical vendors provide a current SOC 2 report or equivalent assurance, reviewed every 12 months.
- Where a critical vendor has no SOC 2 report or equivalent, it completes the security questionnaire in writing, and the decision to proceed is recorded as a policy exception with its reason, its approver and a date to look again.
4. Contracts
Contracts with Tier 1 vendors include:
- A security incident notice period, stated in hours.
- Confidentiality of Company and customer data.
- Deletion or return of data when the contract ends.
- Notice before a new subprocessor handles Company data.
- The right to ask for updated assurance each year.
5. Vendor register
Every vendor is recorded in [Vendor register location] before it is used. Each entry names the service, the data it can reach, its tier, an internal owner, the assurance collected and the date of the last review.
6. Reviewing a vendor report
- Confirm the report is current, covers the service you use and was issued by a licensed CPA firm.
- Read the opinion and any exceptions, and decide whether they affect you.
- Read the complementary user entity controls and assign each one to an owner at the Company.
- Record the review with the reviewer, the date and the conclusion.
7. Ending a vendor relationship
When a vendor is retired, its access is removed, the return or deletion of Company data is confirmed in writing, and the register entry is closed with the date.
8. Roles and responsibilities
| Role | Held by | Responsibility |
|---|---|---|
| Policy approver | [Policy approver role] | Approves this policy, each new version, and any risk the Company accepts instead of meeting it. |
| Policy owner | [Security owner role] | Maintains this policy, makes sure the controls in it operate, keeps the evidence, and reviews it at least once a year. |
| Vendor owner | The employee who requests the vendor | Supplies the information for the assessment and the register, and tells the policy owner when the vendor reach changes. |
| All personnel | Everyone in scope | Follow this policy and report a suspected breach of it to the [Security owner role]. |
9. Evidence and records
The records below show that this policy operates. Each is dated, kept for at least [Evidence retention period], and stored where an auditor can be given it.
| Record | What it shows | Where it is kept |
|---|---|---|
| Approved policy | This document, signed by the approver, with its version history. | [Documentation system] |
| Vendor register | List of vendors and their risk ratings. | [Documentation system] |
| Vendor SOC 2 reports | Audit reports for critical vendors. | [Evidence storage location] |
| Vendor review notes | Who reviewed each report or questionnaire, when, and what they concluded. | [Evidence storage location] |
10. Exceptions and enforcement
A deviation from this policy needs a written exception approved by the [Security owner role] before it begins. Each exception records the rule not met, the business reason, the compensating control and an expiry date no more than 12 months away. Exceptions are reviewed at each annual review.
A breach of this policy is handled under the Company disciplinary process and may lead to action up to and including termination of employment or contract. A breach that exposes customer data is also handled as a security incident.
11. Review and approval
The [Security owner role] reviews this policy at least once a year and after any significant change to the business, the systems in scope or the risks they face. The [Policy approver role] approves each version. Personnel are told of material changes and acknowledge the current version.
| Version | Date | Summary of change | Approved by |
|---|---|---|---|
| [Version] | [Effective date] | First version. | [Policy approver role] |
Sign-off. Name, signature and date for: Policy approver.
12. Fields to complete
Replace every bracketed field in this document with your own detail, then delete this section.
| Field | What to enter |
|---|---|
| [Company name] | Your legal company name. |
| [Effective date] | The date the approver signs this version. |
| [Version] | Start at 1.0 and increase it each time the document changes. |
| [Security owner role] | The role that runs the security program day to day, for example Chief Technology Officer. |
| [Policy approver role] | The officer who approves policies and accepted risks, for example Chief Executive Officer. |
| [Evidence storage location] | The shared folder or system where evidence is kept. |
| [Documentation system] | Where policies and procedures are published, for example the company wiki. |
| [Vendor register location] | Where the vendor register is kept. |
| [Evidence retention period] | How long audit evidence is kept, for example three years. |
| [Next review date] | The date this version must be reviewed by, at most 12 months after the effective date. |
How to adapt it in an afternoon
- List every vendor. Start from the card statement and the single sign-on app list, then tier each one.
- Collect reports for Tier 1. Ask each vendor for its current report and record the period it covers.
- Send the questionnaire where needed. The vendor security questionnaire is the 24 questions, as a spreadsheet.
- Check your contracts. Look for breach notice in hours, deletion on exit and subprocessor notice, and note any contract that lacks them.
- Approve it and write the first review notes. One dated note per Tier 1 vendor before the audit period opens.
What produces a finding
A critical vendor with no review in the period. A report on file whose period ended long before yours began, with no bridge letter. A vendor in production that is missing from the register altogether. How to verify a SOC 2 report is the read order for the report itself, and the SOC 2 policy list shows where this policy sits under the information security policy.
Polara G.R.C. onboarding is $2,000 one time. It writes the thirteen policies in its pack, which cover vendor management, from your intake answers, with your systems, owners and review dates named, for you to review and approve. No template passes an audit on its own, this one included. An independent licensed U.S. CPA firm tests whether the policy operated.
Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Questions
Does SOC 2 require a vendor management policy?
Which vendors need a SOC 2 report?
What if a critical vendor has no SOC 2 report?
How often must vendors be reviewed?
Is a vendor management policy template enough for SOC 2?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Onboarding is $2,000 one time, then SOC 2 Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.