Vendor Risk Management Policy

vendor-risk.md·SOC 2 · CC9.2

Generate a Third-Party / Vendor Risk Management Policy with risk tiering, due-diligence steps, and ongoing monitoring — the evidence for CC9.2.

Generate this policy Browse all policies

What's in the policy

Governs how third parties are assessed, onboarded, and monitored for security risk.

✓Vendor risk tiering and criticality

✓Due diligence and security review before onboarding

✓Contractual security and privacy requirements

✓Ongoing monitoring and reassessment

✓Vendor inventory / register

✓Offboarding and access termination

Mapped toSOC 2 (CC9.2)ISO 27001 (A.5.19–A.5.22)GDPR

What the document actually says

These are the standing requirements every generated copy of the document is written from — the clause text itself, not a description of it. The document you receive is drafted on top of them: it expands on them and fills the current-state detail from your intake, and the generator is instructed to keep them, to state them fully, and never to claim a certification or invent a fact you did not supply.

How vendors get sorted into a tier

Vendors are tiered by the sensitivity of the data they handle and their criticality to operations: | Tier | Criteria | Diligence | | --- | --- | --- | | High | Processes customer/personal data or is critical to service | Security review + DPA + annual re-review | | Medium | Access to internal/confidential data | Security questionnaire at onboarding | | Low | No sensitive data access | Basic review |

SOC 2 CC9.2 · ISO 27001 A.5.19 — three tiers keyed to what a vendor can reach, not the size of the contract, and each tier carries its own diligence step instead of one generic review applied to everyone.

What has to happen before a vendor gets access

- High- and medium-tier vendors are risk-assessed before onboarding, including review of their security posture (e.g., SOC 2 report, ISO 27001 certificate, or a completed security questionnaire). - A Data Processing Agreement (DPA) and appropriate confidentiality terms are executed with any vendor that processes personal or customer data. - Vendor access to company systems and data is limited to what is necessary and is provisioned and reviewed under the Access Control Policy.

SOC 2 CC9.2 · ISO 27001 A.5.20 — diligence happens before access is granted, a signed DPA is required for any vendor that touches personal or customer data, and the access itself is scoped to what's necessary and provisioned under the Access Control Policy rather than left open-ended.

What keeps the register honest after onboarding

- A current inventory of vendors and subprocessors is maintained, including the data each handles and its tier. - High-tier vendors are re-reviewed at least annually and upon any material change (e.g., a security incident on their side). … - Vendors are offboarded when no longer used: access is revoked and data return/deletion is confirmed.

SOC 2 CC9.2 · ISO 27001 A.5.19, A.5.22 — the register carries a tier per vendor, a high tier is re-checked on a clock rather than once, and losing a vendor means confirming access is gone and data actually came back or was deleted.

AWS, Stripe, and a support-ticket tool

Filled in for a real stack

Placeholder

Resolved

High: AWS, which hosts the production database and every customer record, and Stripe, which processes card payments — each gets a security review, a signed DPA, and an annual re-review. Medium: the support-ticket tool, which sees customer messages but never card or credential data — a security questionnaire at onboarding, no DPA required.

What the auditor asks for alongside it

A current inventory of vendors and subprocessors, each one tagged with its tier.

Your vendor register, read against the tiering table in Section 3. High tier is anything that processes customer or personal data or is critical to service; medium tier is access to internal data; low tier is everything else — the criteria a reviewer checks your register against, not just whether a list exists.

Which vendors sit outside your trust boundary, and what a breach of one would actually touch.

The system architecture and data-flow diagram, generated from the same vendor names you give at intake. Each one is drawn as its own box inside a Third-Party Subprocessors group, outside the hosting trust boundary — so the register and the picture of your attack surface come from one list, not two.

Evidence a high-tier vendor was actually re-reviewed on the clock the policy sets, not just onboarded once.

Your renewal or re-assessment record for that vendor, dated within the last year. The policy sets the trigger — annual, or immediately after a security incident on the vendor's side — and the record is what a reviewer samples against it.

The answer your own customers get when they ask whether vendors are assessed before onboarding.

The drafted questionnaire response to that question, grounded in this policy: vendors that process customer data are risk-assessed before onboarding and reviewed periodically. It notes a current vendor inventory only when your intake actually lists one — the wording is fixed by the policy, not by what you enter.

Where these documents go stale

A vendor list drifts faster than almost anything else in the pack, because a new vendor rarely arrives through a review. A team signs up for a SaaS tool with a company card, connects it to a data source, and it is live before anyone assigns it a tier. A vendor already on the list can drift within it too: an analytics tool that used to see aggregate counts starts ingesting a raw export, and its tier is now wrong even though nothing about the vendor changed. The annual re-review clock depends on someone actually running it, and a high-tier renewal that slipped last quarter is not flagged by anything automatic. Offboarding fails just as quietly — a subscription lapses instead of being formally revoked, and nobody confirms the access or the data actually left. Re-validate by walking every connected tool against the register, not only the ones someone remembers signing up for.

From intake to enterprise-ready in three moves

Tell us about your stack

Answer a short intake — cloud, data types, tools. No agents to install.

We generate a tailored draft

Not a blank template: a document written for your environment and pre-mapped to controls.

Review, edit, and share

Export it or attach it straight to an enterprise security review or questionnaire.

Vendor Risk Management Policy, answered

What is a vendor risk management policy?

A vendor risk management policy sets out how third parties that touch your systems or data get assessed before you use them, contracted with, and checked again over time. It sorts vendors into tiers by what each one can reach, so a payments processor and an internal project-management tool are held to different standards instead of the same one.

How does vendor tiering work?

Vendors are placed into a tier by the sensitivity of what they handle and how critical they are to the business. High tier — anything processing customer or personal data, or critical to the service — gets a full security review, a signed Data Processing Agreement, and annual re-review; lower tiers get a lighter check scaled to what they reach.

Does SOC 2 require a vendor management policy?

Yes, in substance. CC9.2 is the third-party and vendor-risk criterion, and an auditor asks for the written policy plus a current register showing which vendors were assessed, at what tier, and when each was last reviewed. A policy with no maintained register behind it is a routine finding.

What counts as due diligence before onboarding a vendor?

For a high- or medium-tier vendor, it means reviewing their security posture before granting access — a SOC 2 report, an ISO 27001 certificate, or a completed security questionnaire — and executing a Data Processing Agreement with any vendor that will process personal or customer data. Low-tier vendors get a lighter, proportionate check instead.

How often do vendors get reviewed after onboarding?

High-tier vendors are re-reviewed at least annually, and again immediately after any material change, such as a security incident on the vendor's side. The policy also requires an up-to-date inventory tagged by tier, so a reviewer can see which vendors are actually due rather than assuming all of them are current.

How is this different from the AI Vendor Review Policy?

This document covers the general vendor program: tiering by data sensitivity, diligence at onboarding, and the annual re-review cadence. Training-data use, retention limits, and which subprocessors a model provider itself relies on are AI-specific terms, and those live in the AI Vendor Review Policy instead, so the two do not repeat each other.

How does Pentest Today generate the policy?

Answer a short intake about your stack and we generate a tailored draft — not a blank template — pre-mapped to the controls your framework requires. You review, edit, and export it.

Can I edit the generated policy?

Yes. Every document is a starting draft you can edit, brand, and export. It's written to be review-ready but stays fully under your control.

Free · no account

Start your Pentest

Our agent swarm and human experts test your endpoints and deliver an audit, fast.

Start your Pentest How it works

Generate your full security policy pack.

Get the vendor risk management policy plus everything else an enterprise security review asks for — generated from your real environment.

Get started Browse all policies