Vendor and Third-Party Risk Management Policy template (SOC 2)

Requires vendors to be inventoried, tiered by the data and services they touch, assessed before onboarding, bound by contract, reviewed annually and offboarded cleanly.

Policy P16 of 22 · Owner: Security Owner · 3 criteria in the crosswalk · Apache-2.0

What this policy is for

The Vendor and Third-Party Risk Management Policy is one of the 22 governance policies in the Policyseed set. It is owned by the Security Owner, approved by the executive you name in the intake, and reviewed on the cadence you choose. Like every policy in the set it has nine numbered sections: purpose, scope, roles, policy statements, procedures, exceptions, enforcement, review cadence and a revision history table. Sections 4 and 5 carry the substance; those are the sections the Audit Kit rewrites for your named tools.

SOC 2 criteria this policy addresses

The Policyseed crosswalk maps 3 criteria to this policy. Each row names the section an auditor would read for that criterion; the criterion pages explain what it asks in plain words and list evidence examples.

CriterionWhat it coversWhere in this policy
CC2.3External communicationSection 4 (Policy Statements)
CC3.2Identifying and analyzing risksSection 5 (Procedures)
CC9.2Vendor and business partner riskSection 4 (Policy Statements), Section 5 (Procedures)

Evidence auditors typically ask for

A policy is tested against artifacts. These are examples from the crosswalk for the criteria above, written for a small SaaS company; the Audit Kit ships the full list as an evidence checklist with an owner per row.

  • Public security page or trust page URL and a dated screenshot
  • Published privacy notice with the date it was last updated
  • Customer incident notification template from the Incident Response Policy procedures
  • Contract or DPA clause stating customer breach notification timelines
  • Completed annual risk register with likelihood, impact, treatment and owner columns
  • Vendor risk assessment records for critical vendors (SOC 2 report review notes or security questionnaire)
  • Meeting notes or ticket showing leadership approval of the risk treatment plan
  • Vendor inventory with data access level, criticality tier and review date for each vendor

Full text: the Vendor and Third-Party Risk Management Policy rendered for Northwind Cloud Inc

Below is the complete template as the generator renders it for Northwind Cloud Inc, a fictional 11-50-person remote company running Northwind on AWS, Vercel, GitHub and Okta. Every name, tool and date comes from that sample intake; your answers replace them. Section headings carry anchors so the criterion pages can link straight to the section they cite.

Sample document

Northwind Cloud Inc Vendor and Third-Party Risk Management Policy

1. Purpose

Northwind Cloud Inc depends on vendors to host Northwind, run the business and serve customers, and each one can put the confidentiality, integrity or availability of Northwind Cloud Inc data and services at risk. This policy ensures that every vendor is known, its risk understood before it is trusted with data or access, its contract holds it to the standard Northwind Cloud Inc holds itself to, and the relationship is reviewed and ended in a controlled way.

2. Scope

This policy applies to every external organisation that stores, processes or transmits Northwind Cloud Inc data, provides infrastructure or software on which Northwind depends, has access to Northwind Cloud Inc systems or premises, or serves customers on Northwind Cloud Inc's behalf: cloud providers (AWS and Vercel), delivery tooling (GitHub, GitHub Actions), identity providers (Okta), vendors such as Supabase, Stripe, Datadog and Slack, contractors and consultants, and free or trial services adopted by individuals. It binds everyone who selects, approves, administers or uses vendor services. Vendors are tiered at onboarding; the tier sets the depth of due diligence, contract requirements and review cadence.

TierCriteriaExamplesDue diligenceReview
Tier 1 - CriticalStores or processes customer data or PII data, or is a dependency of a Tier 1 system under the Business Continuity and Disaster Recovery PolicyAWS and Vercel, GitHub, Okta, and those of Supabase, Stripe, Datadog and Slack that meet the criteriaSOC 2 Type II report or ISO 27001 certificate reviewed, security questionnaire where gaps remain, data flow documented, contract security terms, continuity and exit planAnnually, and on any incident or material change
Tier 2 - ImportantInternal confidential data or personnel personal data, or access to internal systems, but no customer dataTicketing, HR and payroll, finance, collaboration tools, monitoringAssurance report or completed questionnaire, contract security terms, single sign-on where supportedAnnually
Tier 3 - LowNo access to confidential data or systemsDesign tools without customer data, marketing services, office suppliersTier confirmed by the Security Owner; standard termsEvery two years or on change of use

3. Roles and Responsibilities

  • Executive Management approves this policy, approves Tier 1 vendor relationships and any acceptance of residual vendor risk, signs vendor contracts, and reviews the vendor risk summary at least annually.
  • Security Owner (Dana Whitfield, CTO) owns this policy and the vendor inventory, assigns tiers, performs or coordinates due diligence, sets required contract terms with counsel, runs the annual review, and coordinates response to vendor incidents.
  • Engineering identifies technical dependencies and data flows to each vendor, configures integrations with least privilege, monitors vendor status and security advisories, and maintains fallback or exit plans for Tier 1 dependencies.
  • People Operations manages contractor and consultant agreements, ensures confidentiality terms and security training obligations exist for individuals with system access, and includes vendor account removal in offboarding.
  • All Personnel obtain approval before adopting a vendor service or connecting one to Northwind Cloud Inc data or accounts, use vendors only for their approved purpose, and report suspected vendor security issues to security@northwindcloud.example.

4. Policy Statements

  • 4.1 Northwind Cloud Inc maintains a vendor inventory recording, for every vendor, the business owner, service provided, data shared and its classification, systems accessed, tier, contract and renewal date, last review date and outcome, and assurance evidence held, and reviews it for completeness at least annually.
  • 4.2 No vendor receives Northwind Cloud Inc data, system access or a connection to Northwind Cloud Inc accounts until it is in the inventory, tiered by the Security Owner and cleared through the due diligence for its tier. Free, trial and personal-account services follow the same rule.
  • 4.3 For Tier 1 vendors, the Security Owner reviews an independent assurance report covering the service used, records exceptions and the complementary user entity controls Northwind Cloud Inc must operate, and documents the data flow and sub-processors.
  • 4.4 Contracts with Tier 1 and Tier 2 vendors include confidentiality obligations, security controls appropriate to the data, notification of incidents affecting Northwind Cloud Inc data within 72 hours of the vendor becoming aware, restrictions on sub-processors, return or deletion of data on termination, and a right to assurance evidence.
  • 4.5 Vendors processing personal data on Northwind Cloud Inc's behalf sign a data processing agreement meeting the GDPR, UK GDPR and applicable US state privacy laws, including sub-processor approval, assistance with data subject requests and transfer safeguards. The Security Owner confirms regulatory terms before signature.
  • 4.6 Vendor access to Northwind Cloud Inc systems follows the Access Control Policy: least privilege, single sign-on through Okta where supported, multi-factor authentication, logging, time limits on support access, and removal within one business day of the engagement ending.
  • 4.7 API keys, tokens and service accounts issued to vendors are unique per vendor, scoped to minimum permissions, stored in the secrets manager, rotated at least annually and on suspected exposure, and inventoried with the vendor record.
  • 4.8 Every Tier 1 and Tier 2 vendor is reviewed at least annually to confirm the service, data and tier are still accurate, obtain the current assurance report, check incidents and material changes, confirm contract terms, and decide whether the relationship continues, changes or ends.
  • 4.9 Northwind Cloud Inc monitors critical vendors between reviews through status pages, security advisories and published sub-processor changes, and treats any vendor breach notification as an incident under the Incident Response Policy.
  • 4.10 Tier 1 vendors on which Northwind depends have a documented continuity assessment and exit plan covering how Northwind Cloud Inc would withstand a prolonged outage or end the relationship, including data retrieval and migration time, and reliance on a single vendor for a critical function is recorded in the risk register.
  • 4.11 When a vendor relationship ends, Northwind Cloud Inc revokes all access and credentials, retrieves needed data, obtains written confirmation of deletion within the contractual period and updates the inventory; contractors and consultants are offboarded like personnel.
  • 4.12 Personnel may not connect third-party applications, browser extensions or artificial-intelligence services to Northwind Cloud Inc accounts, or paste confidential or customer data into them, unless the service is an approved vendor whose tier permits that data; Engineering reviews OAuth grants quarterly and revokes unapproved ones.
  • 4.13 Residual risk from a vendor that cannot meet its tier's requirements is recorded in the risk register and accepted in writing, with an expiry date and compensating measures, by Executive Management for Tier 1 and the Security Owner for Tier 2 and Tier 3.

5. Procedures

  • 5.1 Request and intake. The requester states the business purpose, data to be shared, systems to be accessed, expected users and cost, and any existing alternative in the inventory; the Security Owner assigns a provisional tier within five business days and lists the due diligence required.
  • 5.2 Due diligence. For Tier 1 vendors, the Security Owner obtains the current SOC 2 Type II report or ISO 27001 certificate, reviews scope, opinion, exceptions and complementary user entity controls, sends the Northwind Cloud Inc questionnaire where gaps remain and documents the data flow with Engineering; Tier 2 vendors need an assurance report or completed questionnaire. Findings and the final tier are recorded.
  • 5.3 Contracting. The Security Owner confirms that the contract or accepted terms include the requirements in 4.4 and, where applicable, 4.5; gaps are negotiated or accepted under 4.13. Executive Management signs Tier 1 contracts; business owners may accept standard terms for Tier 3.
  • 5.4 Onboarding. Engineering provisions the integration through single sign-on in Okta where supported, issues scoped credentials from the secrets manager, records them in the vendor record and confirms logging of vendor access to Northwind Cloud Inc systems; the business owner confirms that only approved data is shared.
  • 5.5 Annual review. The Security Owner reviews every Tier 1 and Tier 2 vendor within twelve months of its last review, obtaining the updated assurance report, checking incident history and sub-processor changes, re-confirming tier and data with the business owner, recording outcomes and actions, and summarising for Executive Management the vendors whose risk has increased.
  • 5.6 Continuity and exit planning. For each Tier 1 technical dependency, including AWS and Vercel and those of Supabase, Stripe, Datadog and Slack that qualify, Engineering documents the fallback or migration approach, data export method and estimated switching time, and reviews it at the annual review and the disaster recovery test.
  • 5.7 Vendor incidents. On a vendor-reported or discovered incident, the Security Owner opens an incident under the Incident Response Policy, determines the affected Northwind Cloud Inc data and services, obtains the vendor's findings and remediation, rotates shared credentials, decides with Executive Management on customer notification and records the incident for the next review.
  • 5.8 Offboarding. When a contract ends or a service is replaced, Engineering removes single sign-on assignments, integrations, OAuth grants and credentials within one business day, the business owner retrieves needed data, the Security Owner files the deletion confirmation and the inventory entry is closed with the date.
  • 5.9 Inventory upkeep. Each quarter the Security Owner reconciles the inventory against vendor payments, the single sign-on application list and OAuth grants found by Engineering, adds vendors found outside the process and has the responsible person complete intake or stop use.

6. Exceptions

Exceptions require written approval from the Security Owner, or from Executive Management for a Tier 1 vendor, a compensating control or accepted risk in the risk register, and an expiry date no more than 12 months away, and are reviewed at each annual policy review. No exception permits sharing customer data with a vendor that has not signed confidentiality and incident notification terms.

7. Enforcement

Adopting a vendor or connecting a service to Northwind Cloud Inc data or accounts without approval, sharing data beyond a vendor's approved tier, issuing unscoped or shared credentials, or failing to remove vendor access at the end of an engagement is a violation of this policy and may result in disciplinary action up to and including termination of employment or contract. Vendors that breach contractual security obligations face the remedies in their contract, including suspension and termination.

8. Review Cadence

The Security Owner reviews this policy on a annual basis and after any vendor incident affecting Northwind Cloud Inc data, changes to applicable privacy or sector regulation, and the addition of a Tier 1 vendor of a kind not previously used. Each review is approved by Priya Natarajan, CEO and recorded in Section 9.

9. Revision History

VersionDateDescriptionApproved by
1.02026-09-02Initial releasePriya Natarajan, CEO

Frequently asked questions

Who should own the Vendor and Third-Party Risk Management Policy?
In the Policyseed template the Security Owner owns the Vendor and Third-Party Risk Management Policy: they maintain the text, run the procedures in section 5 and hold the evidence those procedures produce. The approver you name in the intake signs it, and section 8 sets the review cadence you choose (annual, semi-annual or quarterly).
Which SOC 2 criteria does the Vendor and Third-Party Risk Management Policy address?
3 criteria in the Policyseed crosswalk: CC2.3 (External communication), CC3.2 (Identifying and analyzing risks) and CC9.2 (Vendor and business partner risk). Each mapping points at a numbered section of this policy, and the Audit Kit exports the same mapping as an Excel crosswalk with an evidence checklist.
Is the Vendor and Third-Party Risk Management Policy template free to use?
Yes. The template is Apache-2.0 licensed and the generator renders it in your browser with your company, stack and owner names filled in; nothing is stored server-side. The Audit Kit ($39 one-time) rewrites sections 4 and 5 for your named tools with Claude and adds Word documents, the crosswalk spreadsheet, acknowledgment forms and a review calendar. Refunds are available within 14 days on request. Policyseed provides governance policy templates, not legal advice; the CPA firm performs the examination.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.