Every TPRM program has a policy. Most are longer than they need to be and quieter on the parts that actually drive program behavior.

This is a section-by-section template built from policies that hold up in regulatory exams and internal audits. The sections are the ones OCC examiners, ISO 27001 auditors, and internal audit teams actually read. The wording is tight so the policy stays usable. Scope lives in the policy. Procedural detail belongs in playbooks linked from each section, not inlined.

The seven sections every TPRM policy needs

Seven sections. Adding more bloats it. Removing any one leaves a gap an auditor will find.

1. Scope. Which relationships, data classifications, business units, and geographies the policy covers.
2. Definitions. Third party, fourth party, critical vendor, regulated data, and the tiering scheme.
3. Roles and responsibilities. A RACI by lifecycle stage naming functions (not individuals).
4. Risk tiering. Tier criteria, tier definitions, and the matrix that maps data and criticality to a tier.
5. Process. The lifecycle stages, required artifacts, and approval gates.
6. Exceptions. How exceptions are raised, approved, documented, and reviewed.
7. Review cadence. When the policy is reviewed, who signs off, and what triggers an out-of-cycle refresh.

A tier-1 bank's policy might run twenty pages because the tiering matrix and process section earn the length. A mid-market SaaS company's policy should hit eight to ten. Anything much longer is procedural detail masquerading as governance. Anything much shorter is missing one of the seven.

Section 1: Scope

Scope is the first sentence an auditor reads and it decides which vendors are in. Ambiguity here produces the orphaned-vendor problem every program eventually has to diagnose.

Template wording:

This policy governs all third-party relationships that involve access to {Company} systems, data (including Confidential and Regulated Data as defined in Section 2), facilities, or brand. It applies to all business units and geographies in which {Company} operates. Intra-group service agreements between {Company} entities are excluded and governed separately under {Group Services Agreement Policy}. Relationships used solely for transactional purchases of office supplies or commodity IT hardware with no system or data access are excluded.

Scope should make one explicit exclusion. Orphaned vendors are almost always the result of an implicit exclusion somebody assumed was in place. Name one narrow exclusion and future edge cases require an amendment, not an interpretation.

Section 2: Definitions

Precise definitions prevent argument at tier-determination time. Keep the list short: define only terms the policy uses in a non-standard way.

Template wording:

Third Party. Any entity external to {Company} that provides goods, services, or access to systems, data, facilities, or brand. Includes vendors, processors, subcontractors, outsourced operations, consultants, contingent workforce providers, and service integrators.

Fourth Party. A third party of a Third Party. In scope when identified by a Third Party's subprocessor disclosure or when identified through due diligence as processing {Company} Regulated Data.

Critical Vendor. A Third Party whose failure would materially impact {Company}'s ability to serve customers, meet regulatory obligations, or maintain operations. Designation is made during tiering and reviewed at least annually.

Regulated Data. Personal data as defined by applicable privacy law (GDPR, CCPA, CPRA, and successor frameworks), protected health information, cardholder data in scope for PCI DSS, and any data classified Confidential or Restricted under the {Data Classification Policy}.

Tier. The risk classification assigned to a Third Party at intake and reviewed per the cadence in Section 7. Tiers determine assessment depth, monitoring intensity, and review frequency.

Reference other policies rather than re-stating them. The TPRM policy stays stable when the data classification policy or the regulatory environment changes.

Section 3: Roles and responsibilities

Assign roles to functions, not people. Five functions cover most programs: Business Owner, Procurement, Security, TPRM, and Legal. A RACI by lifecycle stage is the right structure.

Template wording:

Business Owner. The employee who sponsors the Third Party relationship and relies on it to deliver work. Accountable for relationship performance, exception requests, renewal decisions, and acknowledgement of alerts generated by ongoing monitoring.

Procurement. Consulted on intake, owns contracting and commercial terms, maintains the contract repository, and provides the contract lifecycle data the program depends on.

Security. Executes technical assessments, reviews security documentation (SOC 2, ISO, penetration test summaries), and approves or conditions Third Party relationships involving access to systems or Regulated Data. For the evidence set most programs collect and how that set varies by tier, the vendor due diligence checklist covers the artifact depth referenced in Section 5.

TPRM. Owns this policy, the tiering methodology, the vendor inventory, the risk register, the monitoring program, and program-level reporting. Challenges first-line risk decisions where evidence warrants.

Legal. Owns Data Processing Agreements, indemnification, and any contractual terms addressing regulatory or liability exposure.

A RACI matrix by lifecycle stage sits as an appendix to the policy. It lists which function is Responsible, Accountable, Consulted, or Informed at each stage (plan, screen, assess, onboard, monitor, offboard). Named roles without the matrix leave gaps. For the underlying tiering logic, the vendor risk assessment spoke covers how the assessment depth varies by tier.

Section 4: Risk tiering

Tiering drives every downstream workflow. The matrix should produce a deterministic output: given the same inputs, two analysts assign the same tier.

Template wording:

Every Third Party relationship is assigned a Tier at intake (Section 5) and reviewed at least annually or upon material change. Tiering inputs include: data access scope, criticality to business operations, regulatory exposure, financial exposure, and concentration impact. The Tiering Matrix (Appendix A) maps inputs to one of four Tiers:

• Tier 1 (Critical). Access to Regulated Data at volume, material criticality to operations, or regulatory designation as a Critical ICT Third Party under DORA. Requires full due diligence, continuous monitoring, annual re-assessment, and named executive accountability.
• Tier 2 (High). Access to Regulated Data, or moderate operational criticality. Requires full due diligence, quarterly monitoring review, and biennial re-assessment.
• Tier 3 (Moderate). Limited data access or non-critical operational role. Requires abbreviated due diligence, annual monitoring review, and triennial re-assessment.
• Tier 4 (Low). No Regulated Data access and non-material operational role. Requires intake screening only and ad-hoc review triggered by change.

The Tiering Matrix itself lives in Appendix A as a table. Four tiers produce useful differentiation. Three collapses Tier 2 and Tier 3 into an over-assessed middle. Five adds administrative cost without changing behavior.

Section 5: Process

Keep the process section short and point at playbooks for operational detail. Inlining playbook content bloats the policy and forces an amendment every time the playbook is tuned.

Template wording:

The Third Party Risk Management lifecycle comprises six stages. Each stage has defined entry and exit criteria, required artifacts, and the approver named in the stage's playbook.

• Plan. Business Owner and Procurement define the relationship, required access, and tier hypothesis. Artifact: Intake Request. Playbook: {TPRM-P-01}.
• Screen. TPRM performs initial risk screening (cyber rating, sanctions, adverse media, financial indicators). Artifact: Screening Summary. Playbook: {TPRM-P-02}.
• Assess. Security, TPRM, and Legal perform full due diligence scaled by Tier. Artifact: Risk Decision. Playbook: {TPRM-P-03}.
• Onboard. Procurement executes contract; Security provisions access; TPRM records the relationship in the Vendor Register. Artifact: Onboarding Record. Playbook: {TPRM-P-04}.
• Monitor. Ongoing oversight per Tier. TPRM reviews monitoring output; Business Owner acknowledges alerts. Artifact: Monitoring Log. Playbook: {TPRM-P-05}.
• Offboard. Procurement terminates contract; Security revokes access; TPRM records exit assessment. Artifact: Offboarding Record. Playbook: {TPRM-P-06}.

Approval authority at each gate is defined in the stage playbook and matches the escalation thresholds in Appendix B.

Reviewers scan the process section first for coherence between named roles and named artifacts. Every artifact named here must exist as a template in the governance repository. Missing artifacts come up in the next audit. For the onboarding mechanics specifically, the vendor onboarding spoke covers the procurement-to-TPRM handoff in detail. For selecting the platforms that operationalize the process, the vendor risk management software breakdown walks through the three-layer tool market.

Section 6: Exceptions

Without a working exception process, the policy fractures silently under operational pressure. With a documented one, exceptions become auditable risk acceptances rather than quiet bypasses.

Template wording:

Exceptions to this policy may be requested when compliance is operationally infeasible or when the business case justifies a temporary deviation. Exception requests follow the Exception Request process in {TPRM-P-07} and require:

• A documented business justification
• Identification of the specific policy requirement being waived
• Residual risk assessment performed by TPRM
• Compensating controls where available
• Expiration date (maximum 12 months)
• Approval by the Exception Approver named in Appendix B, escalated per the exception's Tier and residual risk

Exceptions are logged in the Exception Register, reviewed monthly by TPRM, and reported quarterly to the {Risk Committee}. Exceptions expiring without renewal are closed and the underlying condition is remediated.

A policy without an exception log encourages undocumented exceptions. The log is the most-scrutinized artifact in an internal audit, because it shows whether the program respects its own policy or quietly bypasses it.

Section 7: Review cadence

Annual review is the baseline. Event-driven review handles the rest.

Template wording:

This policy is reviewed at least annually by the TPRM Program Owner and approved by the {Chief Risk Officer} or delegate. Out-of-cycle review is triggered by any of:

• Material regulatory change (issuance or amendment of guidance affecting third-party risk, such as OCC Interagency Guidance updates, DORA technical standards, state privacy law amendments; see the regulatory compliance monitoring walkthrough for how teams surface these signals)
• Significant organizational change (merger, acquisition, divestiture, new business line, new geography)
• Material incident involving a Third Party with policy implications
• Finding from internal or external audit referencing this policy

• New regulatory pipeline items surfaced through horizon-scanning regulatory intelligence processes (proposed rules, consultation papers, pending legislation)

Changes are tracked in the policy revision log. Material changes (scope, definitions, tiering methodology, role reassignment, approval thresholds) require re-approval through the standard policy approval workflow. Editorial changes (clarification, typography, cross-reference updates) may be applied by the Policy Owner with notification to the {Risk Committee}.

A policy with no revision log looks like a policy that is never reviewed. The log is evidence.

Integrating monitoring into policy

The section most TPRM policies underdevelop is how ongoing monitoring feeds back into the policy's tiering and re-assessment cadences. Monitoring that stays operational (runs in a separate system, produces alerts, nothing else) creates the gap between the policy's picture of the vendor and the vendor's current state.

Policy-level integration requires three specific clauses across Section 4 (Tiering) and Section 5 (Process):

Tier-driven monitoring intensity. Each Tier definition in Section 4 should specify the monitoring scope explicitly: which vendor surfaces are monitored (sub-processors, trust center, privacy policy, terms of service, certifications, status page, financial disclosures), and what the alert cadence is. For a deeper look at what a sub-processor monitoring plan covers, see what is a sub-processor. Tier 1 vendors get the full surface monitored continuously. Tier 4 gets nothing. Tier 2 and Tier 3 sit in the middle.

Alert-to-acknowledgement routing. The Monitor stage in Section 5 should name who acknowledges which alert types. Sub-processor additions route to Legal and Privacy. Privacy policy changes route to Legal and the Business Owner. Status page incidents route to the Business Owner. Certificate expirations route to Security. Ambiguity here produces the alert-queue-nobody-reads problem. The continuous vendor monitoring spoke walks through the signal architecture and routing logic most programs converge on, and the TPRM automation workflows reference documents the alert-routing patterns teams build regardless of platform.

Change-triggered re-tiering. Material changes detected through monitoring should be named as re-tiering triggers in the definition of "material change" in Section 4. A Tier 3 vendor that adds a sub-processor processing Regulated Data becomes a Tier 2 candidate and re-assessment follows. The Salesforce sub-processors walkthrough shows what a well-governed sub-processor surface looks like and how change cadence there shapes tiering logic upstream. Without this clause, monitoring signals bypass the tiering model and the register drifts.

The tighter the policy binds monitoring to tiering and re-assessment, the closer the register stays to reality.

Using the template

Replace every

{Company}

,

{Group Services Agreement Policy}

,

{Data Classification Policy}

,

{Risk Committee}

,

{Chief Risk Officer}

, and

{TPRM-P-XX}

placeholder with your organization's equivalent. Confirm the tiering criteria in Section 4 match how your business actually classifies risk. Populate Appendix A (Tiering Matrix) and Appendix B (Approval Thresholds) with your real thresholds. Cross-reference each playbook mentioned in Section 5 against your governance repository.

Before adoption, do three review steps in order. Run a tabletop walkthrough of a recent vendor intake against the draft. It surfaces ambiguities faster than any desk review. A mock audit by internal audit tests whether the policy is legible to a reader outside the program. Legal review confirms the definitions and contractual references align with your current DPAs and contract templates. Skip any of the three and the policy goes live with undetected gaps.

A well-written policy is a short document. The power is in the appendices (the Tiering Matrix and the Approval Thresholds table) and in the playbooks the process section references. Populate them and the policy stops being governance theatre and starts being the document the program actually runs off.

For the program-level view (lifecycle, frameworks, operating model, metrics), the complete TPRM guide is the anchor this template supports.

Frequently asked questions

What is a third-party risk management policy?

A TPRM policy is the internal document that defines how an organization manages the risks introduced by its vendors, processors, and other external parties. It covers scope, definitions, roles, risk tiering, process, exceptions, and review cadence. Alongside a tiering matrix and operational playbooks, the policy is what auditors and examiners read first when reviewing a program's maturity.

What is the NIST standard for third-party risk management?

The primary NIST reference is NIST SP 800-161r1 Rev. 1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations). It defines C-SCRM practices across tiers, integrates with NIST 800-53 controls, and is the most common federal reference. NIST CSF 2.0 adds a Govern function that formalizes supply-chain oversight at the executive level. Federal contractors and many regulated industries reference both.

What are the five phases of third-party risk management?

Most framework literature describes five core phases: planning and tiering, due diligence and assessment, contracting and onboarding, ongoing monitoring, and termination or offboarding. Some references split monitoring into performance monitoring and risk monitoring, producing a six-phase model. A TPRM policy codifies the phases and names the artifacts and approvers at each gate.

What is the difference between TPRM and GRC?

Third-party risk management is a program focused on the risk introduced by external parties. Governance, risk, and compliance (GRC) is the broader enterprise function that covers all organizational risk (including but not limited to third-party risk), compliance with regulatory obligations, and the governance framework under which the enterprise operates. TPRM typically reports into GRC in larger organizations. GRC platforms (OneTrust, ProcessUnity, Archer, MetricStream) commonly include TPRM modules, which is where the terminology overlap usually originates.

How long should a TPRM policy be?

Tier-1 financial services programs commonly run twenty pages, because the tiering matrix, approval thresholds, and exception workflow earn the length. Mid-market SaaS companies land between eight and twelve pages. Anything much shorter is likely missing one of the seven core sections. Anything much longer is absorbing procedural detail that belongs in playbooks linked from the process section.

How often should a TPRM policy be reviewed?

Annual review is the baseline. Out-of-cycle review is triggered by material regulatory change (OCC Interagency Guidance updates, DORA technical standards, state privacy law amendments), significant organizational change (M&A, new business lines), material third-party incidents, or findings from internal audit that reference the policy. Every review cycle should produce a dated entry in the revision log.