Third-Party Risk Management Policy: Guide + Free Template (2026)

Your enterprise customer’s security questionnaire arrives. Question 14: “Do you have a formal third party risk management policy?” You pause. There’s a spreadsheet somewhere, and maybe a doc someone wrote two years ago. But a formal, approved, maintained policy?

That’s the moment most startups realise the gap.

A third party risk management policy (also called a TPRM policy or vendor risk management policy) is the document that defines how your company identifies, assesses, and manages security and compliance risks from external vendors, contractors, cloud providers, and service providers. It sets out who is responsible for vendor oversight, what due diligence is required before onboarding a vendor, what contract terms are mandatory, how often you reassess existing vendors, and what happens when something goes wrong.

Every modern company has third parties. Most have too many to manage informally. The policy is what makes that management systematic, auditable, and defensible.

Several frameworks require it explicitly:

• SOC 2: CC9.2 requires identification, assessment, and ongoing monitoring of vendor risks
• ISO 27001 (2022): Controls A.5.19 through A.5.23 require security requirements in supplier contracts, defined responsibilities, monitoring, and ICT supply chain management
• NIST SP 800-161: The dedicated supply chain risk management standard
• GDPR: Article 28 requires signed Data Processing Agreements with all processors handling personal data on your behalf

By the end of this, you will know exactly what to put in your TPRM policy, how to write it without overcomplicating it, and what auditors will want to see.

Here’s what I’ll cover:

• What a third party risk management policy is and who owns it
• Who needs one, and what the real answer to “do we qualify?” is
• What to include, with a complete evidence checklist
• A free inline template you can adapt and use today
• How to roll it out in practice
• How it maps to SOC 2, ISO 27001, NIST, and GDPR
• What auditors actually look for in the records
• Common mistakes that catch companies out in audits

What Is a Third Party Risk Management Policy?

A third party risk management policy is a formal document that governs how your organisation manages risk introduced by vendors, suppliers, contractors, and other third parties.

But let me be specific about what that means in practice, because “vendor risk” can sound abstract until you are staring at a security incident that started through a vendor you trusted.

Your company uses external tools and services: a cloud hosting provider, a payment processor, an identity platform, an HR system, a CRM. Each of those vendors has access to your systems or your data, or both. If any of them is breached, misconfigures something, or goes out of business without warning, that is a risk your company carries.

The policy defines the rules for managing that risk: which vendors need to be formally assessed, what due diligence is required before you onboard them, what security and data handling terms must be in their contracts, how often you revisit the relationship, and what happens when a vendor has an incident.

It is not the same as a TPRM programme (the processes, tools, and workflows). The policy is the document that governs those processes. Think of it as the rulebook.

It is also different from a general risk management policy, which covers all organisational risk. TPRM policies specifically address risks that originate outside your direct control, through parties you have a commercial relationship with.

Who owns a third party risk management policy?

At most companies, ownership sits with the CISO, Head of Security, or CTO. At early-stage startups, it is often whoever is the designated security owner, even if that is a fractional CISO or an engineering lead with security responsibilities.

The owner is responsible for maintaining the policy, driving the vendor assessment process, and ensuring records are kept. The approver is a different role: typically the CEO, COO, or a board-level sign-off, depending on your governance structure.

Who does this policy apply to?

The policy applies to any team that procures, onboards, or manages third-party relationships: engineering, procurement, legal, finance, and operations. Basically, anyone with the authority to bring a new vendor into your stack.

Why Third-Party Vendors Are Your Biggest Compliance Blind Spot

Your payment processor is breached. Their systems are compromised. Your customer payment data, which flows through their platform, is exposed. You find out three days later through a news alert. Not from them.

You did not have a breach notification clause in your contract. You did not have a signed Data Processing Agreement. You had not assessed them for security posture in two years. And now you are explaining to your enterprise customers why their data was involved in a breach at a vendor they have never heard of.

That is the third-party risk story. And it plays out more than it should, because most companies treat vendor security as an afterthought.

There are three risk categories a third party risk management policy helps you address.

Security risk is the most obvious. Supply chain attacks, breaches through subprocessors, insecure API integrations: your vendor’s weak posture becomes your exposure. If a vendor with access to your production environment is compromised, your data is compromised. The policy forces you to assess that risk before it materialises.

Compliance risk is less obvious but equally real. SOC 2 CC9.2 and ISO 27001 A.5.19 through A.5.23 both require documented evidence of third-party oversight. Without a policy, you do not just have a process gap. You have a control gap. Auditors will find it, and they will ask for evidence you do not have.

Operational risk is the one people forget. Vendor failures, unexpected shutdowns, service degradation: if a critical vendor disappears or breaks, what happens to your operations? The policy forces you to think about this before it becomes a crisis.

This policy does not eliminate these risks. It gives you a systematic, documented, defensible approach to managing them.

Who Needs a Third Party Risk Management Policy?

If your company uses any external software, cloud services, or contractors, you need some version of this policy. The question is how formal and detailed that version needs to be.

In practice, a documented, approved policy becomes a hard requirement in a few specific situations.

You’re pursuing SOC 2 or ISO 27001. Both frameworks require evidence of vendor oversight. Not having a policy is not just a gap. It is a failed control.

You sell to enterprise customers. Large customers regularly send security questionnaires before signing. Somewhere in that questionnaire is a question about your vendor risk programme. Not having a formal TPRM policy is often a deal-blocker.

You process personal data from EU residents. GDPR Article 28 requires signed Data Processing Agreements with every processor handling that data. This policy is the governance structure that makes sure those DPAs are in place.

Early-stage startups selling to enterprise

I have seen 10-person companies with 20 SaaS tools, two contractors, and no documented vendor oversight. That is the default state. It holds up fine until an enterprise prospect sends a questionnaire or an auditor shows up.

At that point, having never thought about vendor risk systematically becomes a problem that takes weeks to fix. The policy is not bureaucracy. It is the thing that lets you say, with evidence: “Here is how we manage this.”

Companies in healthcare, finance, and government tech

These sectors have explicit requirements on top of the general framework requirements. Healthcare vendors need Business Associate Agreements with subprocessors. Fintechs need vendor risk programmes aligned to their banking partners’ standards. Government contractors may need supply chain risk management aligned to NIST SP 800-161.

A third party risk management policy is often a prerequisite to doing business in these sectors, not a nice-to-have.

What Your Third Party Risk Management Policy Should Cover

A vendor gets onboarded to your production database. Nobody in security knew. The approval came from engineering. Six months later, their contract ends, but nobody revokes their access. A year after that, you’re in an audit, and an auditor asks who has access to your production environment.

That story is avoidable with the right policy structure. Here is what a complete third party risk management policy needs to cover.

Vendor classification and risk tiering

Not every vendor is equal. A company that hosts your production database carries fundamentally different risk to a supplier that ships office stationery. Tiering is how you allocate your oversight effort proportionally.

A standard four-tier system looks like this:

• Critical: Vendors with direct access to production systems or sensitive customer data. Cloud hosting, payment processors, identity platforms.
• High: Vendors with internal system access but no direct customer data exposure. HR platforms, internal tooling vendors.
• Medium: Limited internal access, no sensitive data. Productivity tools, communication platforms.
• Low: No system or data access at all. Physical goods suppliers, non-integrated services.

The tier a vendor falls into determines what due diligence you require and how often you reassess them.

Due diligence and pre-onboarding assessment

Before a Critical or High vendor can be onboarded, you need documented evidence of their security posture.

For Critical vendors, the standard checklist includes: a current SOC 2 Type II report (or ISO 27001 certificate), a completed security questionnaire, evidence of encryption in transit and at rest, recent penetration test results, and a signed Data Processing Agreement if they handle personal data.

High vendors get a lighter version: SOC 2 or equivalent, a questionnaire, and a DPA where relevant. Medium vendors complete a self-assessment. Low vendors require no formal assessment.

The point of tiering is not to give some vendors a free pass. It is to make sure your effort is concentrated where the risk is highest.

Contract and SLA requirements

Your vendor contracts should include, at minimum: data processing and security obligations, a breach notification requirement (72 hours is the standard), a right-to-audit clause or access to third-party audit reports, and data return or deletion obligations on contract termination.

For any vendor processing personal data on behalf of EU-resident users, a signed DPA is not optional. It is a legal requirement under GDPR Article 28 and Article 32.

Ongoing monitoring and review cycles

Assessing a vendor once at onboarding and then never again is a common failure. SOC 2 CC9.2 requires ongoing monitoring, not a one-time check.

Your policy should specify a reassessment schedule by tier (annual for Critical and High vendors is standard), and trigger conditions for out-of-cycle review: a vendor is breached, acquired, changes their scope of service, or is up for contract renewal.

The offboarding process is part of this too. When a contract ends, access should be revoked immediately and you should request written confirmation of data deletion or return.

Free Third Party Risk Management Policy Template

This is a complete, free third party risk management policy template you can adapt and use immediately. It covers all the sections auditors expect to see. No sign-up required.

It works as a third party vendor risk management policy template too: the structure is identical regardless of whether your organisation refers to external parties as “third parties” or “vendors.”

Use this as your third party risk management policy sample and adapt the tier definitions, assessment requirements, and review cadence to match your context. A third party risk management policy pdf is available for download below.

How to Write and Roll Out Your Third Party Risk Management Policy

The hardest part of this is not writing the policy. It is realising, at the start, that your vendor register does not exist and you need to build one before any of the rest makes sense.

Here is the order that works.

1. Assign a policy owner. This is step zero. Without a named owner, the policy will drift. Name a specific person: CISO, CTO, or designated security lead.

2. Build a vendor register. Inventory every external tool, service, contractor, and cloud provider your company uses. A spreadsheet works. The register should capture: vendor name, service description, tier classification, data access level, contract status, and last assessment date.

3. Classify each vendor by tier. Go through the register and apply your Critical, High, Medium, Low tiering. This is the most time-consuming step, but it determines everything else.

4. Run due diligence on Critical and High vendors you have not assessed. Collect SOC 2 reports, security questionnaires, and DPAs for any vendor that should have them but does not.

5. Customise the policy template to your organisation’s size, industry, and framework requirements. The free template in Section 6 is your starting point.

6. Get approval from leadership. CEO, board, or your designated approver, whoever your governance structure requires.

7. Communicate the policy to all relevant teams: engineering, procurement, legal, finance. An email with a link to the policy and a brief explanation of what changed is enough.

8. Collect acknowledgements. For SOC 2 and ISO 27001, you typically need evidence that employees have read and acknowledged the policy.

9. Map the policy to your compliance controls. SOC 2 CC9.2, ISO 27001 A.5.19 through A.5.23, NIST SP 800-161. If you use a GRC platform, link the policy to the relevant controls now.

10. Collect evidence. Assessment records, signed contracts, DPAs, monitoring logs. The policy without evidence is not a passing control.

11. Set a recurring review reminder. Annual at minimum. Assign it to the policy owner. Put it in the calendar now, not next year.

TPRM Policy and Compliance: SOC 2, ISO 27001, and NIST SP 800-161

An auditor asks for your vendor risk assessment records. You hand over the policy. They look at it and say: “Yes, but what records do you have showing this was implemented?”

The policy tells auditors what you intend to do. The records tell them what you actually did. Both matter.

Here is how a TPRM policy maps to the major frameworks.

SOC 2 CC9.2 is the control most directly addressed by a TPRM policy. It requires that the company identifies vendor risks and monitors vendor performance against their commitments. The policy is the control document. The vendor assessment records are the evidence that you follow it.

ISO 27001 controls A.5.19 through A.5.23 (2022 edition) address supplier security policies, supplier agreements, ICT supply chain security, monitoring and reviewing supplier services, and managing changes to supplier services. A well-structured TPRM policy maps directly to all five. See the ISO 27001 standard for the full control text.

NIST SP 800-161 is the dedicated supply chain risk management framework. Alignment to it gives you the most rigorous third party risk management framework posture available, and satisfies the NIST CSF supplier relationship category. If you work with government or defence contractors, this is often the standard they expect.

GDPR Articles 28 and 32 have different requirements. Article 28 requires a signed DPA with every processor handling EU personal data. Article 32 requires appropriate technical and organisational security measures. Both are addressed by a TPRM policy that includes proper contract requirements and vendor oversight.

What Auditors Look for in Your Third Party Risk Management Policy

Here is how an audit for this control typically works: the auditor will ask for your vendor register, pull three to five vendors from it, and ask to see the due diligence records, the contract, the DPA if applicable, and the most recent reassessment. That is the test.

A third party risk management policy example of what passes: dated SOC 2 report in file, completed questionnaire, signed DPA, evidence of annual reassessment, breach notification clause confirmed in contract. Everything linked to a vendor record with dates.

A common example of what fails: policy exists but no vendor register; assessments were done verbally or informally; DPAs were never signed; the last formal review was the initial onboarding two years ago.

Here is the full evidence checklist.

Vendor Risk Mistakes That Get Startups Caught in Audits

Most of the failures I see in vendor risk are not failures to write a policy. They are failures to maintain what the policy says you will do. Here are the seven that come up most.

1. No vendor register. Auditors ask for a list of your vendors and their risk classification. A surprising number of startups do not have one. “We know what tools we use” is not the same as a maintained register with classification, access level, and assessment history.

2. Treating all vendors equally. Applying the same heavyweight questionnaire to your cloud hosting provider and your office supplies vendor wastes time and misses the point. Applying the same lightweight process to both is dangerous. Tiering exists to make oversight proportional to risk.

3. Collecting SOC 2 reports but never reading them. A SOC 2 Type II report is a detailed document. The exceptions section and the user entity controls are what matter. Filing a report without reading it does not count as vendor oversight. Auditors sometimes ask: “Did you review the vendor’s SOC 2? What exceptions did you note?”

4. Missing DPAs. This is extremely common for startups processing EU user data. US-based SaaS tools often do not proactively send DPAs. They exist, but you have to ask. A missing DPA is a direct GDPR exposure and a finding in any ISO 27001 or SOC 2 audit that covers personal data.

5. Onboarding critical vendors without a security review. A new database tool gets approved by an engineering lead and added to production. Security never saw it. By the time anyone asks, it has been live for six months with broad access and no breach notification clause in the contract.

6. No offboarding process. A contractor’s access is never revoked after their engagement ends. An integration stays live after a contract lapses. Access reviews during audits surface these. They look worse than they are, but they are still a finding.

7. Annual reviews set but never run. The policy says annual reassessment. The calendar reminder gets dismissed. Nobody owns the follow-through. I have seen this in almost every company that does not have a dedicated security role. The fix is assigning a specific person to own the schedule and giving them the authority to chase vendors for updated documentation.

Right-Sizing Your Third Party Risk Management Policy

A founder asked me recently whether a 12-person startup really needs all of this. The honest answer is: not all of it, but more than you think.

The goal is a policy that matches your actual risk profile, not a policy that looks impressive in a document that nobody reads.

Startups (1 to 25 employees)

Keep it simple. At this stage, your vendor register might have 20 entries. Your Critical vendors are probably two or three cloud infrastructure providers. Your high-value due diligence effort should be concentrated there.

A single-page policy, a maintained spreadsheet for the vendor register, a one-page questionnaire for Critical vendors, and signed DPAs for any vendor processing personal data: that is a defensible, audit-ready setup for a company at this stage. A lightweight third party vendor risk management policy you actually follow is worth more than a comprehensive one that collects dust.

From a basic third party vendor risk management policy to a full TPRM programme

As you grow from 25 to 100 people, the vendor count grows, procurement gets distributed across more teams, and the risk of an unreviewed vendor slipping through increases.

This is the stage to formalise: introduce the four-tier classification system, make vendor security review part of the procurement workflow rather than an afterthought, and assign a dedicated owner with the authority to block onboarding until due diligence is complete.

Larger organizations with dedicated security teams

At this scale, you are likely looking at a full TPRM programme: dedicated tooling, automated monitoring for vendor certifications, integration with your GRC platform, and sub-policies for specific vendor categories.

The policy document becomes one layer of a larger structure, supported by workflows, evidence collection, and regular review cycles. The access control policy and data classification policy work in parallel with it, ensuring vendor access and data handling are governed consistently across the organisation.

Managing Your Third Party Risk Management Policy with ComplyJet

Writing the policy is the easy part. Maintaining it, collecting the evidence, keeping the vendor register current, running annual reassessments, and having everything ready when an auditor asks: that is where the operational overhead sits.

ComplyJet handles the full lifecycle of your TPRM policy: creation, version control, approval workflows, and employee acknowledgement tracking. The vendor management module lets you build your register, classify vendors by tier, track due diligence status, and store assessment records in one place.

Control mapping is automatic. Your third party risk management policy maps to SOC 2 CC9.2, ISO 27001 A.5.19 through A.5.23, and other frameworks without manual tagging. Evidence collected through the platform is automatically linked to the relevant controls.

Review reminders fire before they are due. You do not need to manage a calendar reminder and chase people manually.

FAQs

What is a third party risk management policy, exactly?

A third party risk management policy is a formal document that defines how your company identifies, assesses, and manages security and compliance risks from vendors, contractors, cloud providers, and other external service providers. It covers vendor classification, due diligence requirements, contract terms, ongoing monitoring, and what happens when a vendor has an incident.

What should a third party risk management policy include?

At minimum: purpose and scope, vendor classification tiers, due diligence requirements for each tier, contract and DPA requirements, an ongoing monitoring schedule, incident notification obligations, an offboarding process, exception handling, enforcement, and review cadence. See the table in the “What Your Third Party Risk Management Policy Should Cover” section above for the full breakdown with examples.

Does SOC 2 require a third party risk management policy?

Yes. SOC 2 CC9.2 requires that the company identifies and assesses vendor risks and monitors vendors against their commitments. A formal third party risk management policy is the control document that supports this requirement. Without it, CC9.2 is a failing control.

How often should you review your third party risk management policy?

At minimum, annually. You should also trigger an out-of-cycle review when a vendor is breached, acquired, or materially changes their service scope, or when your business undergoes significant change: a new market, a new regulatory obligation, or a new product line.

Can I use a free third party risk management policy template?

Yes. The inline template in the “Free Third Party Risk Management Policy Template” section above is a complete, free third party risk management policy template you can copy, adapt, and use immediately. It also works as a third party vendor risk management policy template if your organisation uses the term “vendors” rather than “third parties.” A third party risk management policy pdf version is available for download. No sign-up required.

Is there a third party risk management policy example I can adapt?

The template above is designed to be a practical third party risk management policy example, not a generic placeholder. It includes pre-filled best-practice text for every section, with bracketed placeholders only for genuinely company-specific values like the policy owner’s name and your company’s specific data retention period. Use it as your third party risk management policy sample and adapt it directly to your context.

What is the difference between a third party risk policy and a vendor risk management policy?

The terms are largely interchangeable. “Vendor risk management policy,” “third party risk policy,” and “third party vendor risk management policy” all describe the same type of document. “Third party risk management” is the broader, more commonly used compliance term across SOC 2 and ISO 27001 frameworks.

Who should approve a third party risk management policy?

Typically the CEO, COO, or a board-level approver, with the CISO or CTO as the policy owner who prepares and maintains the document. For SOC 2 and ISO 27001, the policy must have a named owner, a named approver, a version number, and a review date. These do not have to be the same person.

Related Policies

• Risk Management Policy: The parent policy governing how your organisation manages risk broadly. Your third party risk management policy operates within this framework and should be consistent with it.
• Information Security Policy: Sets the overarching security requirements that apply to all parties, including vendors. Reading both together gives you a complete picture of your security governance.