Third-Party Risk Management Policy Template

A useful third-party risk management policy defines who may engage a provider, what risks must be assessed, which contract protections are required, how the relationship is monitored, and how it ends. Use the template below as a governance starting point: adapt it to your organization’s laws, contracts, risk appetite, and operating model. It is not a regulator-approved universal form.

The five-stage lifecycle—planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination—comes from US interagency banking guidance. That guidance is a sector-specific reference, not automatically applicable law or supervisory guidance for every organization. The OCC community-bank guide is voluntary and says relevance depends on an institution’s size, complexity, risk profile, and relationship. Check current requirements with counsel and your relevant regulator before adopting the policy.

1. Policy purpose and scope

Policy owner: [role or committee]
Approver: [governing body or authorized executive]
Effective date / review date: [dates]
Applies to: [legal entities, departments, locations, and covered relationship types]

Purpose. This policy establishes a risk-based process to identify, assess, approve, contract with, monitor, and terminate third-party relationships. The organization will scale its controls to the nature of the activity, the consequences of disruption, the data or systems involved, and the provider’s role in serving customers or meeting obligations.

Scope. Define which providers and arrangements count as third parties. Consider vendors, service providers, consultants, technology and cloud suppliers, outsourced functions, agents, and subcontractors that support a covered relationship. State any exclusions, such as ordinary purchases with no meaningful access or operational dependency, and who decides whether an exclusion applies. Do not let an exclusion remove an arrangement from review merely because it is labeled a purchase order, pilot, free service, or subcontract.

Related policies. Identify the procurement, information security, privacy, business continuity, records retention, incident response, compliance, and financial authority policies that work alongside this one. Explain which policy governs if requirements conflict, and route conflicts to [role].

2. Roles and accountability

Role	Policy responsibility to assign
Board or governing body	Oversee the program where appropriate to the organization’s governance; review material exposures, exceptions, and significant issues.
Executive sponsor	Ensure the program has authority and resources; resolve cross-functional issues and approve or escalate risk within delegated limits.
Business relationship owner	State the business need, complete planning, provide accurate scope and access details, monitor service, track remediation, and initiate exit planning.
Procurement / vendor management	Maintain intake and approval workflow, support selection and contracting, and keep the relationship inventory current.
Information security	Assess security controls, access, incidents, resilience, and technology dependencies in scope.
Privacy / data protection	Assess personal or sensitive data handling, locations, transfers, retention, and deletion as applicable.
Legal	Review legal and regulatory obligations, contract protections, liability, remedies, and exit terms.
Compliance / risk	Challenge risk ratings, identify applicable obligations, review exceptions, and aggregate reporting.
Continuity / operations	Assess service disruption, recovery arrangements, substitutability, and transition feasibility.
Independent review	Periodically evaluate whether the program is designed and operating as intended, proportionate to the organization.

For smaller organizations, one person may perform multiple functions, but document the assigned responsibilities and any independent review or compensating check. Banking guidance assigns management implementation and board oversight in its context; organizations outside that context should use their own governance structure.

3. Risk tiering and approval

Use a documented tiering method to determine due diligence depth, approvers, contract review, monitoring cadence, and exit planning. Evaluate at least these factors:

Impact and criticality of the supported activity, including customer impact and obligations if service stops.
Data sensitivity, volume, location, retention, and provider or subcontractor access.
System access, privileged access, connectivity, and ability to affect internal operations.
Customer-facing activity, regulatory or contractual significance, and reputational consequences.
Provider substitutability, concentration, dependencies, and practical time to transition.
Geography, resilience, financial condition, and relevant legal or geopolitical exposure.

Set the actual tier names and thresholds to fit your organization. For every relationship, record the rationale; do not rely on a label alone. Reassess when scope, access, data, provider ownership, subcontractors, performance, or threat conditions materially change.

Tier (adapt)	Example decision rule	Minimum workflow
[Low]	Limited impact, no sensitive data or meaningful system access, readily replaceable	Proportionate intake and screening; authorized business approval; retain rationale.
[Moderate]	Meaningful operational or data exposure with manageable alternatives	Relevant control evidence, functional review, contract safeguards, periodic monitoring.
[High / critical]	Critical activity, sensitive data, significant access, customer impact, concentration, or difficult exit	Enhanced cross-functional diligence, senior approval, negotiated protections, closer monitoring, documented continuity and exit plan.

Approval rule. No employee may commit the organization or grant access before required review and approval. Specify who may approve by tier and who may accept residual risk. Material findings, missing evidence, unresolved contract gaps, or requested exceptions must be escalated to [role]. Record the rationale, conditions, owner, expiry or review date, and approver for each exception or risk acceptance. A business owner should not accept risk beyond their delegated authority.

4. Third-party relationship lifecycle

Stage 1: Plan the relationship

Before selecting a provider, the business owner documents:

Business purpose, expected benefits, alternatives, and why external support is needed.
Proposed service, scope, locations, duration, users, data flows, systems, and access levels.
Expected customer, operational, legal, privacy, security, and compliance effects.
Dependencies, concentration, substitutability, and consequences if the provider fails or the relationship ends.
Initial tier, required reviewers, approval path, and proposed success and service measures.

Decide whether the activity is important or critical using your own documented criteria. Record the decision and reassess it if the activity or dependency changes.

Stage 2: Due diligence and selection

Assess the provider in proportion to the relationship’s risk and complexity. Review whether the evidence actually covers the proposed service, locations, systems, data, and subcontracting chain—not merely the provider as a whole. Depending on scope, diligence may cover:

Business strategy, experience, references, relevant qualifications, and key personnel.
Legal and regulatory compliance relevant to the service and your organization.
Financial condition and ability to continue providing the service.
Risk management, governance, internal controls, and control testing or independent assurance.
Information security, system architecture, identity and access controls, vulnerability management, and incident handling.
Operational resilience, continuity and recovery arrangements, capacity, and failure scenarios.
Privacy and data handling, including collection, use, storage, transfer, retention, and deletion.
Subcontractors, dependencies, locations, and the provider’s ability to oversee them.
Other relationship-specific issues, such as customer complaints, performance, concentration, or conflicts.

Set acceptable evidence types and freshness periods by tier. Record evidence source, date, scope, limitations, and reviewer. If evidence is missing, stale, limited, or out of scope, document the gap, understand the residual risk, consider alternatives or mitigations, and obtain approval before proceeding. A questionnaire is an input, not proof by itself.

ICT and cyber supply-chain supplement

For information and communications technology (ICT) suppliers, use additional checks relevant to the service and dependency chain. NIST’s July 2026 SP 1326 quick-start guide identifies five assessment components: Foreign Ownership, Control, or Influence (FOCI); Provenance; Resilience; Foundational Cyber Practices; and Supply Chain Tiers. Use these as prompts for technology supplier assessment, not as a replacement for the broader lifecycle policy. See the NIST SP 1326 publication and the NIST SP 800-161 Rev. 1.

Stage 3: Contract negotiation

Translate material risks into enforceable obligations and remedies. Legal and relevant control owners should tailor terms to the service, applicable law, and bargaining context. Consider provisions for:

Clear scope, service levels, responsibilities, reporting, and change control.
Access to relevant records and information; audit, assessment, or examination rights where appropriate.
Security and privacy requirements, permitted use, data location, retention, return, and deletion.
Incident notification, cooperation, investigation, evidence preservation, and remediation.
Complaint handling and required regulatory, customer, or internal reporting support.
Subcontractor approval or notice, flow-down obligations, visibility, and responsibility for subcontractor performance.
Continuity, recovery, testing, and communication during service disruption.
Insurance, indemnity, liability allocation, and remedies as appropriate to risk and counsel’s advice.
Termination rights, transition assistance, portability, data return or deletion, access revocation, and continued service during transition.

Document any unaccepted contractual control gap and the authorized risk decision. A signed contract does not replace due diligence or monitoring.

Stage 4: Ongoing monitoring

Assign a relationship owner and choose monitoring cadence and depth according to tier and change. Monitor, as relevant:

Service levels, quality, complaints, incidents, and remediation commitments.
Updated control evidence, audit findings, certifications or assessments, and scope changes.
Compliance obligations, security and privacy changes, and unresolved findings.
Provider financial or business condition, ownership, key personnel, or strategy changes.
Subcontractors, locations, dependencies, concentration, and supply-chain changes.
Continuity and resilience performance, test results, and ability to meet recovery expectations.

Record reviews, findings, owners, due dates, escalation, and closure evidence. Escalate material service failures, incidents, overdue remediation, significant control deterioration, or changes that alter the risk tier. Reapprove or reassess scope changes before they take effect where feasible.

Stage 5: Termination and transition

Plan for scheduled expiry, business decision, provider failure, security event, and other unexpected termination. The owner coordinates:

Alternative service or transition sequencing to preserve critical operations.
Data return, migration, deletion certification where available, and retention under contract and law.
Revocation of accounts, credentials, tokens, physical access, and integrations.
Transfer or closure of records, open incidents, complaints, claims, and outstanding obligations.
Customer, staff, regulator, and internal communications as applicable.
Confirmation of final invoices, assets, access removal, and contract closeout.

Retain policy, approval, assessment, contract, monitoring, exception, and exit records for the period required by applicable law, contract, and the organization’s records schedule. Document lessons that affect the inventory or future selection.

5. Inventory, records, and reporting

Maintain a central relationship register proportionate to the program. At a minimum, include the provider and service, business owner, contract dates, tier and rationale, data and system access, relevant subcontractors or dependencies, approvals, key diligence and monitoring dates, open findings, exceptions, and termination status. Define who updates it, how often it is reconciled with procurement and accounts payable records, and how changes are captured.

Define reporting frequency and recipients. Useful reporting may summarize relationships by tier, critical activities, overdue assessments or remediation, incidents, exceptions, concentration or dependencies, upcoming renewals, and planned exits. Escalate material issues promptly under incident and governance procedures rather than waiting for a periodic report.

6. Exceptions, policy breaches, and review

Require written exception requests that identify the requirement, reason, affected relationship, risk, compensating controls, accountable owner, approving authority, and review or expiry date. Track exceptions to closure and escalate expired or breached conditions. Define consequences and corrective actions for engaging a provider outside this process.

Review this policy at least [interval] and after material legal, organizational, or risk changes. Review the operating procedures, register quality, control effectiveness, and significant findings. Independent review should be proportionate to organization size, complexity, risk profile, and provider exposure.

7. Adoption checklist

Confirm scope, exclusions, related policies, and jurisdiction-specific requirements with appropriate counsel and control owners.
Name accountable roles and delegated approval limits.
Set tier criteria, diligence depth, evidence standards, monitoring cadence, and escalation triggers.
Configure intake, approval, exception, register, and reporting records.
Apply the lifecycle to existing relationships using a risk-based transition plan.
Train relationship owners and review whether records and escalations work in practice.

8. ScreenshotNeo: documenting website and supplier evidence

For vendor reviews that include a public website, product page, or status page, a screenshot can preserve a dated visual record alongside the assessment. ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media. A screenshot is supporting evidence only: it does not verify a supplier’s controls, financial condition, or contractual compliance. Keep source URLs, capture time, reviewer, and purpose with the record, and follow your retention and privacy rules.

Or skip the browser setup

One GET request returns a screenshot. Replace the target URL and use an API key from your account. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie or consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. Plans include 1,000 screenshots a month free with no card; paid plans start at $5 for 3,000. Create a free account and get 1,000 screenshots a month with no card.

9. Common implementation problems

Problem	Why it happens	Practical fix
Every provider receives the same questionnaire	The process is not tied to impact or scope.	Use tiered diligence and ask only relevant questions, while retaining a rationale for the tier and any gaps.
Evidence is present but does not cover the service	Assessment scope, period, location, product, or subcontractors differ from the proposed relationship.	Compare evidence scope with the actual service and record limitations, alternatives, or mitigations.
Business commits before review completes	Intake and procurement gates are late or unclear.	Make approval a pre-commitment and pre-access requirement; define an urgent exception path with delegated authority.
Contract language is generic	Material assessment findings were not passed to legal and control owners.	Map each material risk to an obligation, evidence right, remedy, owner, or documented acceptance.
Monitoring stops after onboarding	No relationship owner, calendar, event triggers, or recordkeeping exists.	Set tier-based review dates, change triggers, follow-up owners, and escalation for overdue actions.
Exit is infeasible when needed	Portability, alternatives, access revocation, or data disposition were not planned.	Assess transition during planning and contract negotiation, then maintain an actionable exit plan for critical services.

10. Performance, reliability, and cost of the program

Risk-based depth helps focus review effort where disruption or exposure matters most. Avoid making the tier process so elaborate that low-risk relationships bypass the register or high-risk reviews become a paperwork exercise. Track elapsed review time, overdue evidence and remediation, exception age, and whether critical services have current continuity and exit plans; use these operational measures to improve the process, not as claims that risk has been eliminated.

Plan for provider failure and unavailable evidence. A provider may decline an audit right, have a limited assurance report, or change its service or subcontractors. Define what alternative evidence or compensating controls may be accepted, who may accept residual risk, and when the relationship must be paused or declined. Keep sufficient records to explain decisions later.

Program cost includes staff time for intake, diligence, legal review, monitoring, remediation, and transition planning, as well as any assessment or tooling costs. Scale those resources to risk, organizational complexity, and applicable obligations. No numerical benchmark is provided here because the source material identifies no relevant statistic.

11. FAQ

Is this a legally approved policy template?

No. It is an adaptable governance template. Have counsel and relevant control owners align it with applicable laws, contracts, sector rules, and your operating model.

Does every organization need a board-level third-party risk committee?

This template does not prescribe one. Assign oversight through the governance structure and delegated authorities that fit the organization.

Does a vendor questionnaire complete due diligence?

No. The assessment should be proportionate and supported by evidence relevant to the service, with scope and limitations documented.

When should a relationship be reassessed?

At the cadence set by its tier and when a material change occurs, such as expanded access, new data, an incident, ownership change, or a new subcontractor dependency.

What is the current status of the US interagency banking guidance?

The dossier’s sources report that on September 11, 2026, the OCC announced proposed interagency guidance to revise and replace the existing guidance, with a Federal Register notice published September 15, 2026. At that point it was a proposal open for comment, not a final replacement. Recheck the OCC announcement and Federal Register before publication or relying on current regulatory status.

Sources and audience boundary

2023 interagency guidance on third-party relationships, including the lifecycle and risk considerations.
OCC Community Bank Third-Party Relationships guide; voluntary and intended for community-bank context.
NIST SP 1326, ICT supplier assessment quick-start guide.
NIST SP 800-161 Rev. 1, cyber supply-chain risk management guidance.

The exact regulatory proposal status and linked agency notices should be checked again before publication, since status can change. Organizations outside US banking should treat the banking materials as reference points and map this policy to their own laws, contracts, risk appetite, and operating model.