How to build a vendor management policy that actually gets enforced

The 2025 Drift and Gainsight OAuth breaches showed how fast a third party’s problem becomes yours. Both vendors almost certainly held SOC 2 reports and answered plenty of security questionnaires, and it did not matter: the connections their customers had authorized became the path in. 

The Gainsight breach post-mortem even documented improvements made afterward. If you were a customer, the uncomfortable question was simpler than any questionnaire could capture: did you even know which vendors held live access to your environment?

That question is why vendor management belongs on the desk of every GRC manager, security manager, CTO, and founder running third-party relationships under a compliance framework. 

This guide covers how to build a vendor management policy, tier vendors by risk, make enforcement real, and satisfy the auditors who sample your work.

What is a vendor management policy?

A vendor management policy (VMP) is the governing document that defines how your organization selects, assesses, monitors, and exits third-party vendors across the full relationship lifecycle. It sets the rules that determine how much scrutiny a vendor gets, what documentation you require, and what happens when a vendor falls short.

The distinction that matters: the VMP is the governing document, not the operational activity. The policy says what you will do and why. It does not implement controls itself. A vendor risk assessment is the operational activity that the policy requires, the actual work of evaluating a specific vendor against your criteria. Conflating the two is how teams end up with a beautiful policy document and no evidence that anyone followed it.

Vendor risk management obligations are baked into most major frameworks: SOC 2 CC9.2, ISO 27001 Annex A.15 (ISO 27001:2013; the 2022 revision maps the same requirements across A.5.19–A.5.23), and HIPAA Business Associate Agreements all require documented vendor oversight. The VMP is also narrower than third-party risk management (TPRM) as a whole. TPRM is the program; the policy is the document that gives that program its authority.

Why organizations need a vendor management policy

A vendor management policy is what turns “we should probably check our vendors” into a repeatable, auditable process. Five outcomes make that process worth building.

1. Legal and regulatory compliance

HIPAA, GDPR, and SOC 2 each impose vendor obligations, and regulators do not distinguish between your mistake and your vendor’s. HIPAA requires a signed Business Associate Agreement with any vendor that touches protected health information. GDPR requires a data processing agreement with every processor. SOC 2 CC9.2 requires documented vendor oversight. 

Miss any of these, and non-compliance can fall on both parties. (Note: there is no such thing as being “HIPAA certified” or “GDPR certified.” These are laws you comply with, not credentials you earn.)

2. Protecting sensitive data and tracing sub-processors

When you outsource part of your operations, customer and company data flows to vendors, and often to their sub-processors in turn. GDPR specifically requires you to identify and document those sub-processors. A VMP forces this visibility at onboarding instead of after an incident. See our guide on sub-processor risk for how to trace data flows through a vendor’s downstream dependencies.

3. Visibility into your vendor network

The worst-case scenario is learning you used a breached vendor only after the breach, because no one had documented the relationship. A security team that did not know its own company used SolarWinds in 2020 discovered it the hard way: the gap in visibility, not the breach itself, was the organizational failure. Knowing who your vendors are, and which ones hold access to what, is worse to lack than an immature assessment process.

4. Minimizing breach costs

Vendors are a common source of breaches, and a documented policy reduces both the likelihood and the blast radius. Right-sizing assessment depth to vendor risk means your effort lands where the exposure actually is.

5. Audit compliance

SOC 2, ISO 27001 Annex A.15, and HIPAA each treat vendor oversight as an auditable control. Auditors sample vendor assessments. An absent or unfollowed policy is an audit finding, not a footnote. For SMB and mid-market teams, this compliance mandate is usually the first real trigger to formalize vendor management at all.

How to classify vendors by risk tier before writing your policy

Not all vendors pose equal risk, and a policy that treats a payroll processor the same as a swag vendor wastes effort in one place and misses exposure in the other. Before you write a single policy line, decide how risk level will drive assessment depth, monitoring frequency, and contractual requirements. Vendor tiering usually starts with one question: what kind of data will this vendor access, collect, store, or transmit?

Codify these tier criteria inside the policy itself. Tiering left to individual judgment at onboarding is exactly what auditors catch, because it produces inconsistent decisions that cannot be defended after the fact. When the criteria live in the policy, the tier assignment becomes repeatable and reviewable.

For the long tail of vendors that never reach tier 1 or tier 2, handle them at a group level rather than one by one. A line such as "productivity tools with no customer data access: annual self-attestation is sufficient" covers a whole category without draining your team's finite time on vendors that process nothing sensitive.

One dimension most vendor inventories miss: SaaS tools employees connect through OAuth. When someone logs into a new app with their company's Google or Microsoft account, that app may gain read or write access to corporate data, regardless of whether procurement ever approved it. 

These connections can become de facto sub-processors. Your VMP should include a process for reviewing newly discovered OAuth-connected tools, or you are tiering only the vendors you happen to know about. 

The difference between critical and high-risk vendors matters most here, where a low-profile tool with broad scopes can carry outsized risk. Getting tiering right is the foundation of proactive third-party risk management.

What should be included in a vendor management policy

A complete VMP has nine components. Think of the list below as a template structure you can build against: each row of the summary table names what the component must specify and which frameworks care about it.

Purpose and scope

State the risk-reduction goals, which vendors the policy covers, and what data is in scope. This is the section that tells a reader whether a given vendor even falls under the policy.

Roles and responsibilities

Name roles, not people. The policy should survive the next reorganization without a rewrite. Define who owns the policy, who manages vendor relationships, and who reviews assessments, by title.

Vendor risk classification

Define the tiers and the criteria that assign a vendor to each, as covered in the tiering section above. This is where the policy earns its consistency.

Due diligence requirements

Specify assessment depth by tier and the documentation each tier must produce: SOC 2 report, ISO certificate, BAA, DPA. High-risk vendors provide a full package; low-risk vendors provide an intake form.

Ongoing monitoring

Set review frequency by tier and require tracking of certificate expiry. A SOC 2 report that lapsed nine months ago is not evidence of anything current.

Incident notification

Specify the contractual SLA for a vendor to notify you of a breach. Under GDPR Art. 28(3)(f), processors must notify controllers without undue delay after becoming aware of a breach; Art. 33 then governs your own 72-hour obligation to the supervisory authority. HIPAA's Breach Notification Rule imposes its own timelines. Put these in the contract, not in a hope.

Sub-processor disclosure

Require advance notice of material sub-processor changes with a right to object. Most SaaS vendors will accept this; the ones who push back are telling you something worth knowing.

Offboarding

Specify data return or destruction, access revocation, and certification of destruction. See the dedicated offboarding section below.

Enforcement

Define graduated consequences and who has authority to invoke each level. Most policies never get this specific. That is the problem.

Enforcement is where most policies quietly fail. A policy that lists "contract termination" as the only consequence has no graduated response. Real enforcement looks like a ladder: a 30-day remediation window, then enhanced monitoring, then access suspension, then termination. Name the role with authority to invoke each level by title. 

See the sub-processor and DPA obligations guide for disclosure language and the SOC 2 trust services criteria for how CC9.2 frames vendor oversight.

How to create an effective vendor management policy

Now that you know what belongs in the policy, here is how to build one your team will actually run. Five steps take you from a blank page to a policy that holds up under audit.

1. Inventory every vendor relationship first

Before you write a single policy line, build a complete vendor list. Not knowing who your vendors are is worse than having an immature assessment process, because you cannot manage or respond to what you have not documented. Include sub-processors, the cloud-hosted SaaS that processes your data, and shadow IT surfaced through OAuth logs. 

This is unglamorous work, and it is the foundation on which everything else sits. Our guide to systematically measure and manage vendor risk covers how to build and maintain this inventory.

2. Assemble a cross-functional team with defined accountabilities

IT and security own technical assessments, Legal owns contracts, DPAs and BAAs, Procurement owns vendor selection, and Compliance owns framework mapping. 

In lean teams, one person covers multiple roles. The policy still needs to name which role owns which accountability, not which person. In early-stage companies, the CTO or a senior engineering leader is usually the natural first owner, since they understand how data actually flows through the stack.

3. Define your risk tolerance and tier criteria

This is a leadership decision, not a security team decision. Someone with authority has to decide what risk level triggers what response before the policy can be written. 

Cross-reference the tiering criteria you set earlier, and get sign-off from a named accountable leader so the thresholds are defensible.

4. Draft the policy using the nine-component structure

Build against the components covered above. Specify the review and approval process too: who signs off and how often the policy is reviewed. At minimum, review annually or after a material vendor incident. A policy no one has looked at in three years is a liability dressed as a control.

5. Pilot with your highest-risk vendors before full rollout

Test the questionnaires, monitoring workflows, and enforcement language against your five to ten most critical vendors before scaling to the full portfolio. You will find gaps in the process while the stakes are contained, not while you are trying to onboard fifty vendors at once.

An auditor sampling vendor evidence from a spreadsheet gets a reconstruction of what happened, not a live audit trail. Centralize from the start. A vendor risk management platform reduces the manual lift, the real barrier for lean teams, and creates the audit trail as you go.

How to use your vendor management policy to assess new vendors

Tier determines documentation. Low-risk vendors complete an intake form; high-risk vendors produce a full evidence package. Match the depth of the assessment to what the vendor can actually expose.

Concretely, by tier:

• High-risk vendors: SOC 2 Type II report (within 12 months), ISO 27001 certificate if applicable, a signed BAA for HIPAA-scoped vendors, a signed DPA for GDPR-scoped vendors, a completed security questionnaire, and cyber insurance evidence.

• Medium-risk vendors: a completed security questionnaire and basic security policies.

• Low-risk vendors: an intake form acknowledgment.

Here is the distinction auditors check, and most teams miss: security questionnaires are an input to risk assessment, not the risk assessment itself. Sending a questionnaire and filing the response is not the same as reading the response and making a decision. If a question is answered, that means an input was provided so you can assess a risk. You still have to apply judgment to the answer, because vendors have every incentive to show their best side.

There is also a floor below which you cannot accurately assess risk, and a ceiling above which you are just creating busy work. Right-size the questionnaire to the vendor’s tier rather than sending everyone your longest template.

When a high-risk vendor refuses to provide documentation, treat that as a disqualifying signal. If the business still needs the vendor, document the risk-acceptance decision with named executive approval rather than quietly onboarding and moving on. And execute BAAs (HIPAA) and DPAs (GDPR) before the vendor begins processing data, not after.

What auditors actually check in your vendor management policy

Having a vendor management policy is not the same as having evidence that anyone follows it. Auditors distinguish sharply between the two, and the better ones dig for the second.

SOC 2 (CC9.2)

Auditors want to see that you have identified your service providers, documented requirements in contracts, and monitored compliance. They will sample vendor assessments and look for the completed questionnaire, the response review, and any follow-up communication with the vendor about findings. A green dashboard with no underlying assessment activity does not satisfy CC9.2.

ISO 27001 (Annex A.15)

The certification body audit is less about spot-checking individual vendor files and more about whether your supplier security policy exists, governs something real, and has generated review records over time. They want to see the system working, not just the policy sitting in a folder.

HIPAA

BAAs must be executed with every Business Associate. An OCR investigation will ask for a complete BAA inventory, and a single missing BAA is a finding, not a rounding error.

Auditors are moving past “did you send questionnaires” toward “did you act on the responses.” The number of vendors assessed per quarter is not the same as demonstrated risk reduction. Program the policy to require documented decisions, not just documented activity. For framework details, see the SOC 2 trust services criteria explained, ISO 27001 compliance, HIPAA compliance requirements, and the GDPR compliance guide.

Vendor offboarding: What your policy must specify

Most policies define onboarding in detail and treat offboarding as a bullet point. That gap creates audit findings and data-retention violations. An undocumented vendor exit means data may sit with a vendor you no longer have a relationship with, and access may persist long after the contract ends.

Specify four steps:

1. Revoke all logical access on a defined timeline

API connections, OAuth tokens, SSO integrations, and system credentials all need to be cut. The policy should name who is responsible and set the SLA, for example, within 24 hours of contract termination.

2. Require written certification of data return or destruction

This belongs in the contract before the relationship ends, not negotiated on the way out. Specify the format and the timeline.

3. Run a final compliance assessment for high-risk vendors

A close-out review confirms no outstanding security findings remain open before the relationship formally ends.

4. Document the close

Record the offboarding date, confirmation that all access has been revoked, and the data destruction certificate (where applicable). Maintain these records, along with the user access review and vendor management system entry, as the audit trail.

Pay particular attention to OAuth. SaaS vendors connected through OAuth can retain data access through long-lived tokens even after a contract ends, because the token outlives the commercial relationship if no one explicitly revokes it. The policy should require OAuth revocation at the scope level as part of every offboarding. For the broader people-and-process view, see offboarding and risk prevention.

Continuous vendor monitoring vs. point-in-time assessments: What to specify in your policy

Your policy should specify monitoring frequency by tier. Writing "continuous" without defining what that means operationally is how monitoring requirements become unenforceable. 

For most small and mid-market organizations, continuous means automating the review cadence so it happens reliably at defined intervals. At one end of the spectrum sits real-time scanning of vendor posture, the domain of dedicated TPRM platforms and external attack-surface tools; at the other, annual questionnaire renewal. Most compliance programs sit closer to the periodic end, and that is a defensible place to be.

For compliance-driven programs, "continuous" almost never means real-time. It means the quarterly, semi-annual, or annual review actually happens, automated so it does not depend on someone remembering.

Some events should trigger an out-of-cycle assessment regardless of tier: a vendor reports a security incident, a vendor is acquired, a vendor’s compliance certification expires, a public breach is reported, or the vendor materially changes its services or data-access scope.

Who gets the call when a vendor reports a breach? 

The policy should name that person by role and specify how the internal escalation works. Connect this to your third-party incident response plan.

Monitoring is only worth the effort if it drives a decision. The litmus test for any monitoring activity is simple: will this change something you do? If the answer is no, you are collecting data for its own sake. The policy must connect monitoring outputs to defined actions, or continuous compliance monitoring becomes a checkbox instead of a control. For the full program view, see our vendor risk management guide.

Best practices to improve vendor management

These practical tips not only improve but also simplify vendor risk management.

1. Build a contingency plan for critical vendors

 Treat this as a business continuity requirement tied to your tier-1 vendors. The policy should require a documented fallback or substitution plan for the vendors whose failure would stop your business. 

2. Assign a named relationship owner per vendor

This is a role, not necessarily a headcount. A named owner who holds monitoring and escalation responsibility is auditable and survives turnover.

3. Right-size policy complexity to enforcement capacity 

A vendor management policy that demands more than your team can execute is technically complete and practically useless. Overengineered requirements create busy work without making anyone more secure. Right-size requirements to enforcement capacity, or you have written a liability, not a control.

4. Apply tiered standards consistently within each tier

 Proportionate treatment applied uniformly inside a tier is the standard. Identical treatment across all tiers is the mistake. Tier-1 vendors get tier-1 scrutiny, every time.

5. Treat the annual review date as a floor, not the full schedule

An acquisition, a public breach disclosure, or a new regulatory requirement should trigger a review whether or not the annual date has arrived.

6. Treat questionnaire responses as inputs, not outputs

A completed questionnaire is not a completed risk assessment. The policy should require a documented review and a risk decision for each assessment. See the challenges with security questionnaire automation for where this breaks down at scale.

7. Build security requirements into contracts from day one

 Breach-notification SLAs, the right to audit, and data return on termination belong in the contract before signature. Retrofitting these terms into an existing relationship is far harder. The right-to-audit clause in particular is exercised rarely enough that its real value is the leverage it gives you during due diligence, not the on-site visit itself. For the wider view, see vendor risk management best practices.

Bringing it together

A vendor management policy is only as good as the evidence that it is being followed. The part lean teams consistently underestimate is the ongoing maintenance: certificate expiry tracking, monitoring cadence, and audit-ready documentation that does not require a scramble to reconstruct. 

Scrut's vendor risk management platform handles that layer so the audit trail builds alongside the program, not in a panic before the auditor arrives.