How to write a third-party risk management policy

A TPRM policy with no named owner gets edited by whoever was last asked a question by an examiner. Name one accountable owner, one approving body, and the functions that contribute, and write all three into the first page.

Roles are separated cleanly in the Interagency Guidance: the board of directors "has ultimate responsibility for providing oversight for third-party risk management and holding management accountable," and it "provides clear guidance regarding acceptable risk appetite, approves appropriate policies, and ensures that appropriate procedures and practices have been established." Management develops and implements the policies, procedures and practices. It also notes that some organizations "disperse accountability" across business lines while others "centralize the processes under their compliance, information security, procurement, or risk management functions." Either model works. Your policy has to say which one you run.

With the roles settled, lay out the document. Below is the shape a mature program's policy takes. Each section has an owner, which is what keeps the annual review from becoming a committee rewrite.

Scope is where a third party risk policy quietly fails. Most drafts cover "vendors," and the inventory ends up missing the consultant with database access, the affiliate running a shared service, the referral partner that talks to customers, and the fintech arrangement with no paper contract.

On purpose, the Interagency Guidance defines the term broadly: it addresses "any business arrangement between a banking organization and another entity, by contract or otherwise," and adds that "a third-party relationship may exist despite a lack of a contract or remuneration." Its examples include outsourced services, independent consultants, referral arrangements, merchant payment processing, services provided by affiliates and subsidiaries, and joint ventures, as well as newer structures seen with fintech companies. Write the scope clause to that width and let tiering decide how much oversight each relationship gets. Certa's guide to TPRM policy framework components covers how scope and tiering fit with the rest of the framework.

Define the terms you will use in every later section, once. Five matter most.

• Third party and third-party relationship: the guidance's definition above, including affiliates, consultants and arrangements without a contract.
• Critical activity: an activity that could cause significant risk if the third party fails to meet expectations, have significant customer impact, or have a significant impact on financial condition or operations. Those are the guidance's three characteristics, and it leaves the designation to each organization.
• Risk tier: the inherent risk classification assigned at intake, which drives every later requirement.
• Subcontractor (fourth party): any supplier, service provider or other organization a third party uses to deliver the activity.
• Business owner: the first-line manager accountable for the relationship and for accepting its residual risk within appetite.

Then express risk appetite in terms the program can act on. A board statement will say something like "low appetite for operational disruption from third parties." Your policy translates that into rules: critical activities may not be outsourced without committee visibility, no Tier 1 relationship proceeds with unremediated critical findings, concentration in a single provider for multiple critical activities is reported to the board. Under the guidance, both planning and ongoing monitoring test alignment with "risk appetite, risk profile, and broader corporate policies," so the appetite clause is what those tests check against.

Sample wording for the scope clause, to adapt with counsel:

This policy applies to every business arrangement between [Organization] or any of its subsidiaries and another entity, whether or not a written contract or payment exists, including outsourced services, consultants, referral and marketing arrangements, payment processors, affiliates providing services, joint ventures and technology partnerships. Relationships with customers of traditional products and services are governed by [Organization]'s lending and deposit policies and are outside this policy.

Sample policy language, not legal advice

Tiering is the engine of a vendor risk management policy. Every requirement that follows, from due diligence depth to reassessment frequency to who signs the contract, keys off the tier, so the policy must state how tiers are assigned and what each one obligates. It does not need the scoring formula. That is a procedure.

Principle from the guidance, method from you: "Not all relationships present the same level of risk, and therefore not all relationships require the same level or type of oversight or risk management." It observes that some organizations assign a risk level to each relationship while others identify critical activities and the third parties behind them, and it asks for "a sound methodology to designate which activities and third-party relationships receive more comprehensive oversight." Four tiers are enough for most programs.

State the inputs to the tier in the policy: data classification, system and network access, support for a critical activity, customer interaction, substitutability, location and reliance on subcontractors. Spend is a weak proxy. A $30,000 SaaS tool with admin rights to the core system outranks a $3 million facilities contract. Require that the tier is assigned at intake, before any due diligence is scoped, and re-evaluated whenever the scope of the relationship changes.

Reassessment belongs here too. Write the frequency per tier and the triggers that pull a reassessment forward: a security incident, a material change in financial condition, a change of control, a new subcontractor handling your data, or a regulatory action against the third party. Ongoing monitoring, in the guidance's words, is "commensurate with the level of risk and complexity of the relationship" and may be "periodic or continuous," which is the language a tier table operationalizes.

The third party due diligence policy section is the one examiners read most closely, because due diligence files are what they sample. Its job is narrow: state the minimum areas that must be assessed for each tier, what counts as evidence, who reviews it, and what happens when the third party cannot meet the standard.

Fourteen due diligence areas appear in the Interagency Guidance as factors a banking organization "typically considers": strategies and goals, legal and regulatory compliance, financial condition, business experience, qualifications and backgrounds of key personnel, risk management, information security, management of information systems, operational resilience, incident reporting and management processes, physical security, reliance on subcontractors, insurance coverage, and contractual arrangements with other parties. Your policy does not need to repeat the guidance's paragraphs. It needs to say which areas apply at each tier and that Tier 1 covers all of them.

Two sentences from the guidance belong in your section almost verbatim. First, "relying solely on experience with or prior knowledge of a third party is not an adequate proxy for performing appropriate due diligence." That ends the argument about the incumbent vendor nobody has assessed in six years. Second, using external resources such as certifications or shared assessments "does not abrogate the responsibility of the banking organization to manage third-party relationships in a safe and sound manner." That lets you accept a SOC 2 Type II report as evidence while keeping the decision yours.

• Minimum due diligence areas per tier, with Tier 1 covering all 14 and lower tiers scoped to data, access and dependency
• Acceptable evidence by area: audited financial statements, SOC 2 Type II or ISO 27001 certificate with scope, penetration test summary, business continuity test results, insurance certificates, subcontractor list, screening results
• Timing: due diligence completes before contract execution, and before any data or access is granted
• Review and sign-off: which second-line function reviews each area and who approves the assessment at each tier
• Findings: how gaps are rated, when a finding blocks approval, and how remediation plans are agreed and tracked
• Use of external assessments and ratings, with the organization retaining the decision
• Record keeping: assessment, evidence, rationale and approval retained in the system of record for the life of the relationship plus the retention period

If you are rebuilding the evidence list from scratch, Certa's due diligence checklist is a reasonable starting inventory to cut down to your tiers.

Sample wording for the due diligence requirement, to adapt with counsel:

No third-party relationship assigned to Tier 1 or Tier 2 may be executed, and no access to [Organization] data, systems or premises may be granted, until due diligence covering the areas required for that tier in Appendix A has been completed, reviewed by the responsible second-line function, and approved by the authority designated in Section 3. Prior experience with a third party does not satisfy this requirement. Where a gap is identified, the relationship may proceed only under an approved exception or a documented remediation plan with dates and owners.

Sample policy language, not legal advice

A third party management policy that stops at onboarding governs the first month of a relationship that may last ten years. Three sections cover the rest: what every contract must contain, how the relationship is monitored, and how it ends.

Contracts. Sixteen contract areas appear in the guidance, from nature and scope of the arrangement, performance measures and the right to audit and require remediation, through confidentiality and integrity, operational resilience and business continuity, indemnification and limits on liability, insurance, subcontracting, foreign-based third parties, and default and termination. Your policy should list the provisions that are mandatory at Tier 1 and Tier 2, name who may approve a deviation, and require that executed contracts are retained in the system of record. On negotiating power the guidance is frank: where you cannot get a provision, require a documented assessment of whether "residual risks are acceptable" and who accepted them. For relationships that touch government officials, intermediaries or high-risk jurisdictions, cross-reference your anti-bribery obligations. Certa's anti-corruption policy guide covers the clauses that belong there.

Monitoring. Write monitoring as requirements by tier, not as a description of your dashboard. Monitoring factors in the guidance include changes in the third party's financial condition, lapses in insurance, audit and testing results, key personnel changes, use and location of subcontractors, incident response and business continuity testing, and the trend of customer complaints. Pick the factors that apply at each tier, set the review frequency, and say who receives the output. It also expects "sufficient staffing with the necessary expertise, authority, and accountability" for monitoring, so commit to that staffing in the policy rather than assume it.

• Tier 1: continuous monitoring of security ratings, sanctions, adverse media and financial signals, quarterly performance review against SLAs, annual reassessment with a walkthrough
• Tier 2: monthly signal review, annual performance review, reassessment every 12 to 18 months
• Tier 3 and 4: automated signal monitoring, reassessment on trigger
• All tiers: incidents, material findings and policy exceptions reported to the risk committee at least quarterly, with concentration on a single provider called out

Offboarding. Termination factors in the guidance double as the policy's exit requirements: transition options, the capabilities and time required to move the activity, costs and fees, and "data retention and destruction, information system connections and access control, or other control concerns that require additional risk management and monitoring after the end of the third-party relationship." Require a written exit plan for Tier 1 at contract execution, and a closed offboarding checklist for every tier: access revoked, data returned or destroyed with certification, surviving obligations tracked, inventory updated.

Whatever platform runs this, require that every disposition carries its rationale. On Certa, every screen, adjudication and disposition is captured with documented rationale, citations and timestamps, immutable and exportable on demand, which is the record an examiner asks for when a vendor was cleared two years ago by an analyst who has since left.

Information security deserves its own section because it is the area most likely to be governed by a separate document, and the two have to agree. A third-party vendor security policy section states the minimum controls any third party with access to your data, systems or premises must meet, the evidence that proves it, and the incident obligations the contract must carry. It references the enterprise information security policy for the control detail.

In the guidance, the due diligence question is whether the third party's information security program is consistent "with the banking organization's information security program," which means your own policy is the baseline, not a generic control list. It also points to the regulators' Computer Security Incident Notification Rule (12 CFR part 53 for the OCC, 12 CFR 225 subpart N for the Board, 12 CFR 304 subpart C for the FDIC), which is why the notification clock a third party agrees to has to let you meet your own reporting deadline.

• Applicability: any third party that stores, processes or transmits [Organization] data, connects to its network or identity provider, or has physical access to its facilities
• Minimum controls by data classification: encryption in transit and at rest, multi-factor authentication for administrative and remote access, logging and monitoring, vulnerability management with defined patch windows, secure development practices for software suppliers
• Evidence by tier: SOC 2 Type II report or ISO 27001 certificate with scope statement for Tier 1 and Tier 2, annual penetration test summary for anything internet-facing, attestation for Tier 3
• Incident notification: a contractual window measured in hours from confirmation, aligned to your own regulatory reporting obligations, with cooperation and root-cause duties
• Subcontractor flow-down: the same requirements apply to any subcontractor handling your data, with notice of changes and the right to object
• Data handling: residency, retention, return and certified destruction at exit, and restrictions on use of your data to train models
• Access lifecycle: least privilege, joiner and leaver timelines, periodic access review, immediate revocation on termination

Keep the questionnaire out of the policy. This section states the requirement and the evidence standard. Which questions get asked at each tier, and how answers are scored, is the security assessment procedure's job.

A policy is followed when it is impossible to skip. Every requirement in the document should map to a procedure that explains how, and to a workflow control that makes the step happen in the system where the work is done. If a clause maps to nothing, it is either a wish or a finding waiting to be written.

A working third party risk management policy example is a short traceability table kept beside the policy, one row per clause. It is what internal audit tests against and what you update when the platform changes.

This is also where no-code configuration earns its place in a policy program. On Certa, Vibe Configuration™ is built to turn a policy into a live workflow, no code, no IT ticket, with changes made in minutes via chat. A large US firm automated its entire bespoke TPRM process in 2 days using Certa AI. Certa's TPRM orchestration suite runs the lifecycle those workflows describe, from intake through offboarding, with the audit trail attached to every step.

Three habits keep the policy alive after go-live. Train the first line on the clauses that touch them, mostly intake, tiering and the business owner's attestation, and record completion. Run the exception register as a management report, because a growing register is the earliest sign the policy and the business have drifted apart. And report the policy's own metrics to the committee: share of relationships tiered, Tier 1 due diligence completed before execution, reassessments on time, exceptions open past expiry. Those four numbers tell the board whether the policy it approved is the policy being run.