Free Template

Third-Party Risk Management (TPRM) Policy Template

Document owner: [Policy Owner, e.g. Head of Information Security / Chief Risk Officer]
Approved by: [Approving Authority, e.g. Risk Committee / Executive Sponsor]
Effective date: [Effective Date]
Version: [1.0]
Next scheduled review: [Date, normally 12 months from effective date]
Classification: [Internal Use Only]

This document is a ready-to-adopt policy template. Replace every [bracketed placeholder] with details specific to [Company Name], delete any guidance that does not apply to your organization, and route the finished document through your normal policy approval process before it takes effect. Where this template references a control framework (SOC 2, ISO/IEC 27001, GDPR, and similar), confirm the reference matches the standards your organization and your regulators expect.

1. Purpose and Objectives

[Company Name] relies on third parties (vendors, suppliers, service providers, contractors, and partners) to deliver products and services. Those relationships introduce risk to our data, our operations, our customers, and our reputation. This policy establishes how [Company Name] identifies, assesses, mitigates, monitors, and governs risk arising from third-party relationships across their full lifecycle, from selection through offboarding.

This policy exists to protect the confidentiality, integrity, and availability of [Company Name] information and systems, to meet contractual and regulatory obligations, and to ensure that third parties are held to security, privacy, resilience, and ethical standards consistent with our own.

1.1 Objectives

The objectives of the Third-Party Risk Management (TPRM) program are to:

• Maintain a complete and current inventory of third-party relationships and the risk each one presents.
• Apply due diligence proportionate to the risk a third party poses, so that effort is concentrated where exposure is highest.
• Ensure risks are formally assessed and accepted by an accountable owner before a third party is engaged or granted access.
• Embed appropriate security, privacy, and resilience obligations into contracts.
• Continuously monitor third parties for changes in risk posture, certification status, performance, and security incidents throughout the relationship.
• Ensure data and access are recovered or revoked cleanly when a relationship ends.
• Provide evidence of effective third-party governance to auditors, customers, and regulators.

1.2 Policy Statement

No third party may be granted access to [Company Name] data, systems, facilities, or networks, and no contract that creates third-party risk may be signed, until the due diligence and approval requirements set out in this policy have been completed for the applicable risk tier. Compliance with this policy is mandatory for all personnel involved in selecting, contracting with, managing, or terminating third-party relationships.

2. Scope

This policy applies to all third-party relationships that store, process, transmit, or could affect [Company Name] data, systems, customers, operations, or regulatory standing, regardless of contract value, payment method, or how the relationship was initiated (including free tools, trials, and self-service signups).

2.1 In Scope

The following relationship types are within scope and must be assessed under this policy:

• Software and SaaS providers (cloud applications, APIs, developer tools, AI and machine-learning services).
• Infrastructure and hosting providers (cloud platforms, data centers, managed services, CDNs).
• Data processors and sub-processors that handle personal data or confidential information on our behalf.
• Professional services and consultants with access to systems, data, or facilities.
• Outsourced and managed service providers (payroll, support, IT operations, security operations).
• Payment, financial, and billing providers.
• Contractors, staffing agencies, and temporary workers granted system or facility access.
• Resellers, integration partners, and affiliates acting on our behalf or under our brand.
• Hardware suppliers and physical service providers where a failure or compromise would affect operations.
• Fourth parties (subcontractors of our vendors) where they materially affect a service we depend on.

2.2 Out of Scope

The following are generally out of scope, unless they are granted access to [Company Name] data or systems, in which case they must be assessed:

• One-off, low-value purchases of commodity goods with no data or system access (for example, office supplies).
• Regulated utilities (electricity, water) and similar pass-through services with no access to data or systems.
• Internal departments and wholly owned subsidiaries governed by [Company Name] internal policies (covered separately under [Internal Governance Policy]).

When in doubt about whether a relationship is in scope, treat it as in scope and consult the [Risk Team / TPRM Program Manager].

3. Roles and Responsibilities

Effective TPRM depends on clear accountability. The table below uses a RACI model: R = Responsible (does the work), A = Accountable (owns the outcome and final decision), C = Consulted (provides input), I = Informed (kept up to date). Adjust role names to match [Company Name] structure.

3.1 RACI Matrix

Activity	Vendor Owner (Business)	Risk / TPRM Team	Security	Procurement	Legal / Privacy
Identify need and propose vendor	A / R	I	I	C	I
Assign risk tier / classification	C	A / R	C	I	C
Collect due-diligence evidence	R	A / R	C	C	C
Security and architecture review	I	C	A / R	I	I
Privacy / data protection review (DPA, transfers)	C	C	C	I	A / R
Contract negotiation and security terms	C	C	C	R	A / R
Final risk acceptance / approval to onboard	A	R	C	I	C
Ongoing monitoring and reassessment	C	A / R	C	I	I
Incident response involving the vendor	R	C	A / R	I	C
Offboarding and access revocation	A / R	C	R	C	C
Exception review and approval	R	A / R	C	I	C

3.2 Role Definitions

• Vendor Owner (Business Owner / Relationship Owner): The named individual within the requesting business unit who is accountable for the relationship. They justify the business need, supply business context, drive collection of evidence from the vendor, accept residual risk for their function, and remain the point of contact for the life of the relationship.
• Risk / TPRM Team: Owns this policy and the end-to-end TPRM process. Assigns risk tiers, coordinates assessments, maintains the vendor inventory and risk register, tracks remediation, schedules reassessments, and reports program status to leadership.
• Security (Information Security / InfoSec): Defines security control requirements, performs technical and security assessments, reviews evidence (SOC 2, pen tests, questionnaires), evaluates architecture and access, and leads the security response when a vendor is involved in an incident.
• Procurement / Vendor Management: Manages sourcing, ensures TPRM steps are completed before purchase orders or contracts are issued, owns the contract lifecycle and renewals, and enforces the no-contract-without-approval gate.
• Legal / Privacy / Data Protection: Reviews and negotiates contractual terms, ensures required clauses (security, confidentiality, audit rights, breach notification, liability) are present, executes Data Processing Agreements (DPAs) and transfer mechanisms, and advises on regulatory obligations.
• Executive Sponsor / Risk Committee: Provides governance oversight, approves the highest-risk engagements and material risk acceptances, and is the final escalation point for disputes and high-impact exceptions.

4. Vendor Classification and Risk Tiering

Every in-scope third party must be assigned a risk tier before due diligence begins. The tier determines how much due diligence is required, how often the vendor is reassessed, and who must approve the engagement. Tiering is based primarily on two factors: data sensitivity (the most sensitive data the vendor can access) and operational criticality (the impact on [Company Name] if the vendor fails, is breached, or becomes unavailable).

4.1 Tier Definitions

Tier	Label	Data sensitivity	Operational criticality	Typical examples
Tier 1	Critical / High Risk	Accesses, stores, or processes regulated, personal, financial, or highly confidential data at volume (e.g. PII, PHI, cardholder data, secrets, source code).	Outage or compromise would cause severe operational, financial, legal, or reputational harm, or directly affect customers. No quick workaround.	Cloud / hosting platform, core payment processor, primary CRM, identity provider, key data processor.
Tier 2	Moderate Risk	Accesses limited or lower-volume confidential or personal data, or internal-only data.	Outage causes meaningful but contained disruption; a workaround or alternative exists within an acceptable timeframe.	Marketing automation, support tooling, analytics, non-critical SaaS with some data access.
Tier 3	Low Risk	No access to confidential or personal data; handles only public or non-sensitive information.	Outage has minimal operational impact and is easily absorbed or replaced.	Public website tools, commodity SaaS with no data access, low-value suppliers.

Tiering rule: When the data-sensitivity factor and the criticality factor point to different tiers, assign the higher (more stringent) tier. The Risk Team may raise a vendor's tier based on additional factors such as regulatory exposure, concentration risk, geographic or geopolitical risk, public security history, AI or automated decision-making, or extensive use of subcontractors.

4.2 Risk Factors to Consider

• Data: type, sensitivity, and volume of data accessed; whether data leaves [Company Name] environment; cross-border transfers.
• Access: level of system, network, or facility access (read-only vs. privileged/admin; persistent vs. one-time).
• Criticality and dependency: impact of downtime, availability of alternatives, recovery time, and concentration risk.
• Regulatory exposure: applicability of GDPR, CCPA/CPRA, HIPAA, PCI DSS, SOX, DORA, or sector-specific rules.
• Integration: depth of integration (API, SSO, embedded code) and the blast radius of a compromise.
• Fourth-party risk: the vendor's own use of subcontractors and sub-processors.

5. Due-Diligence Requirements per Tier

Due diligence must be completed and documented before a third party is approved. The depth of due diligence scales with the assigned tier. The table below sets the minimum evidence required per tier; the Risk Team or Security may require additional evidence based on specific risk factors.

5.1 Minimum Due-Diligence Matrix

Requirement	Tier 1	Tier 2	Tier 3
Security questionnaire (e.g. SIG, CAIQ, or [Company] standard)	Required (full)	Required (lite)	Optional / short
Independent audit report (SOC 2 Type II) or equivalent	Required	Required or compensating evidence	Not required
ISO/IEC 27001 certificate (or equivalent)	Required or SOC 2 accepted in lieu	Preferred	Not required
Penetration test summary / attestation (within 12 months)	Required	Recommended	Not required
Data Processing Agreement (DPA) where personal data is involved	Required	Required	Required if any personal data
Sub-processor list and notification commitment	Required	Required	If applicable
Business continuity / disaster recovery evidence	Required	Recommended	Not required
Cyber insurance evidence	Required	Recommended	Not required
Financial stability / viability check	Required	Recommended	Not required
Privacy / data-transfer assessment (SCCs, adequacy)	Required if data crosses borders	Required if data crosses borders	If applicable
Reference checks / public reputation review	Required	Recommended	Optional

5.2 Acceptable Evidence and Validity

• Audit reports and certifications must be current. Treat SOC 2 Type II reports as valid for [12] months from the report period end; where there is a gap, obtain a bridge letter.
• Certifications (ISO/IEC 27001, PCI DSS, and similar) must be valid and within their stated scope. Confirm the scope actually covers the service [Company Name] will use.
• Review every report for exceptions, qualified opinions, and carve-outs, not just the presence of the document. Material exceptions must be assessed and tracked as risks.
• Where a vendor cannot provide an independent audit, Security may accept compensating evidence (completed questionnaire plus supporting documentation) and record the residual risk for acceptance.
• All evidence and decisions must be stored in [TPRM system / repository] and linked to the vendor record.

6. Onboarding and Approval Workflow

The onboarding workflow ensures that no third party reaches production access without the right reviews and a recorded approval. The Vendor Owner initiates the request; the Risk Team coordinates; the relevant reviewers complete their parts; an accountable approver signs off.

6.1 Workflow Steps

1. Intake. The Vendor Owner submits a request via [Intake Form / TPRM Tool] describing the business need, the data and systems involved, and the proposed vendor.
2. Tiering. The Risk Team assigns a risk tier (Section 4) based on the intake details.
3. Due diligence. Evidence is collected per the tier requirements (Section 5). The Vendor Owner obtains documents from the vendor; Security and Privacy review them.
4. Assessment and findings. Reviewers document findings, gaps, and required remediations. High-risk gaps must be remediated, mitigated, or formally accepted as exceptions (Section 11) before approval.
5. Contracting. Procurement and Legal finalize the contract, including the security and data terms required in Section 8.
6. Approval / risk acceptance. The accountable approver for the tier (see 6.2) records a decision: approve, approve with conditions, or reject.
7. Provisioning. Only after approval is access granted, accounts created, and the vendor added to the inventory with its tier, owner, and next review date.

6.2 Approval Authority by Tier

Tier	Required reviews	Final approver
Tier 1	Risk, Security, Legal/Privacy, Vendor Owner	[Executive Sponsor / CISO / Risk Committee]
Tier 2	Risk, Security, Vendor Owner (Legal as needed)	[Risk Team Lead / Security Manager]
Tier 3	Risk (lightweight), Vendor Owner	[Vendor Owner's Manager / TPRM Program Manager]

6.3 Onboarding Checklist

• ☐ Intake request submitted with business justification and data/systems described.
• ☐ Risk tier assigned and recorded.
• ☐ Required due-diligence evidence collected and reviewed (per Section 5).
• ☐ Findings documented; high-risk items remediated, mitigated, or formally accepted.
• ☐ Contract signed with required security, privacy, and breach-notification terms.
• ☐ DPA and data-transfer mechanism executed where personal data is involved.
• ☐ Final approval / risk acceptance recorded by the correct authority.
• ☐ Vendor added to inventory with tier, owner, criticality, and next review date.
• ☐ Access provisioned on least-privilege basis; continuous monitoring enabled.

7. Ongoing Monitoring and Reassessment

Third-party risk is not static. Certifications lapse, ownership changes, breaches occur, and services evolve. [Company Name] performs both periodic reassessment (a scheduled re-review of each vendor) and continuous monitoring (ongoing watch for changes between reviews). The cadence scales with tier.

7.1 Reassessment Cadence by Tier

Tier	Full reassessment	Evidence refresh (SOC 2 / certs)	Continuous monitoring	Business review
Tier 1	Annually	Annually, plus on expiry of any report or certificate	Continuous (automated, see 7.2)	Quarterly
Tier 2	Every [12-24] months	On expiry / renewal	Continuous, lighter-weight	Annually
Tier 3	At renewal or every [24-36] months	Not routinely required	Periodic spot checks	At renewal

7.2 Continuous Monitoring

Between scheduled reassessments, the Risk Team maintains ongoing visibility into each in-scope vendor's risk posture. Continuous monitoring should track, at minimum:

• Trust centers and security/compliance pages, where vendors publish their certifications, audit status, and subprocessor lists. Changes here often signal a new certification, a lapsed one, or an added sub-processor before any formal notice is sent.
• Certification and report validity (SOC 2, ISO/IEC 27001, PCI DSS), including expiry dates and renewals.
• Sub-processor list changes, which may introduce new fourth-party risk or data-transfer concerns.
• Status, security, and DPA/terms pages for material changes to service commitments or data handling.
• Public breach disclosures, security advisories, and adverse news affecting the vendor.
• Service performance and availability against agreed SLAs (incidents, outages, degradations).
• Financial or ownership changes (acquisition, insolvency signals) that affect viability or data control.

Manually re-checking dozens of vendor trust centers and certification pages is impractical, so monitoring of these public pages should be automated. Configure change detection on each Tier 1 and Tier 2 vendor's trust center, security/compliance page, status page, sub-processor list, and DPA so that the Risk Team is alerted when any of them changes, rather than discovering a lapsed certificate or a new sub-processor at the next annual review. Record the monitored URLs against each vendor in [TPRM system / monitoring tool].

7.3 Triggered (Event-Based) Reassessment

A full or partial reassessment must be triggered, regardless of the scheduled cadence, whenever any of the following occurs:

• The vendor experiences a security incident or data breach.
• A certification or audit report lapses, is downgraded, or shows new material exceptions.
• The scope of the relationship changes (new data types, new access, new integration, or new region).
• The vendor is acquired, merges, changes control, or shows signs of financial distress.
• A new or changed sub-processor introduces material risk.
• A significant regulatory or legal change affects the relationship.
• Repeated SLA breaches or performance failures occur.

8. Contractual and Security Requirements

Risk controls are only enforceable if they are in the contract. Before signing, Legal and Procurement must confirm that contracts with in-scope third parties include the clauses below, scaled to tier. Absence of a required clause for a Tier 1 vendor must be treated as a finding and remediated or formally accepted as an exception.

8.1 Required Contract Clauses

• Confidentiality and data ownership: [Company Name] retains ownership of its data; the vendor may use it only to deliver the contracted service.
• Information security obligations: the vendor maintains a security program aligned to a recognized standard (e.g. ISO/IEC 27001, SOC 2, NIST CSF) and applies appropriate technical and organizational controls.
• Data protection / DPA: where personal data is processed, a Data Processing Agreement governs processing, with approved transfer mechanisms (e.g. Standard Contractual Clauses) for cross-border data.
• Encryption: data encrypted in transit and at rest to [Company Name] minimum standards.
• Access control: least-privilege access, strong authentication (including MFA for privileged access), and prompt removal of access for departing personnel.
• Sub-processor controls: prior approval or advance notice of new sub-processors, with flow-down of equivalent obligations.
• Breach and incident notification: notification within a defined window (see Section 9) with cooperation duties.
• Audit and assessment rights: the right to request evidence, complete assessments, or audit (directly or via independent reports).
• Business continuity and resilience: commitments to availability, recovery objectives (RTO/RPO), and continuity testing for critical vendors.
• Service levels: measurable SLAs with remedies for failure.
• Liability and indemnification: appropriate liability allocation and cyber insurance requirements.
• Return and deletion of data: defined process and timeframe for return and certified destruction of data on termination.
• Compliance and ethics: compliance with applicable laws and [Company Name] standards (e.g. anti-bribery, sanctions, [Supplier Code of Conduct]).
• Termination rights: the right to terminate for material breach, persistent SLA failure, or unacceptable risk.

9. Incident and Breach Notification Expectations

Third parties must notify [Company Name] promptly of incidents that affect, or may affect, our data, systems, or services. These expectations must be reflected in contracts and reinforced during onboarding.

9.1 Notification Requirements

• Notification window: the vendor must notify [Company Name] without undue delay and no later than [24-72] hours after becoming aware of a confirmed or suspected security incident or data breach affecting our data or services.
• Notification channel: notice must be sent to [security@company.com / designated contact] and to the Vendor Owner.
• Minimum content: nature of the incident, data and systems affected, time of detection, current status, immediate containment actions, and a named point of contact.
• Cooperation: the vendor must cooperate with [Company Name] investigation, preserve evidence, and not make public statements about a shared incident without prior coordination where contractually agreed.
• Follow-up: a root-cause analysis and remediation plan must be provided within [10 business days] of containment.

9.2 [Company Name] Response

On receiving a vendor incident notice, the Risk Team and Security activate the [Incident Response Plan], assess impact on [Company Name] and its customers, determine regulatory and customer notification obligations, and track the vendor's remediation through to closure. A vendor incident is grounds for triggered reassessment (Section 7.3) and may justify suspension or termination.

10. Offboarding and Termination

Risk does not end when a contract does. Offboarding ensures access is revoked, data is recovered or destroyed, and obligations are confirmed complete. Offboarding must be performed for every in-scope vendor when a relationship ends, whether by expiry, termination, or non-renewal.

10.1 Offboarding Checklist

• ☐ Trigger offboarding in [TPRM system] and notify Security, Procurement, and Legal.
• ☐ Revoke all vendor access (accounts, API keys, certificates, VPN, SSO, physical access).
• ☐ Disable integrations and remove any embedded code, webhooks, or connections.
• ☐ Recover [Company Name] data in a usable format before access is removed.
• ☐ Obtain written confirmation (and certificate where required) of secure data deletion by the vendor and its sub-processors.
• ☐ Confirm any post-termination obligations (confidentiality, support, transition assistance) are documented.
• ☐ Settle final invoices and close out the contract.
• ☐ Disable continuous monitoring for the vendor and archive the vendor record with an offboarding date.
• ☐ Conduct a brief lessons-learned review for Tier 1 exits.

11. Exceptions Process

Where a business need requires deviating from this policy (for example, engaging a Tier 1 vendor that cannot provide a SOC 2 report, or proceeding before a control gap is closed), a formal exception is required. Exceptions make risk visible and time-bound; they are not a way to bypass the policy permanently.

11.1 Requesting and Approving Exceptions

1. The Vendor Owner submits an exception request describing the deviation, the business justification, the associated risk, and any compensating controls.
2. The Risk Team and Security assess the residual risk.
3. The exception is approved by the authority matching the residual-risk level: [Risk Team Lead] for low/moderate residual risk, [Executive Sponsor / Risk Committee] for high residual risk.
4. Approved exceptions are recorded in the [Exception Register] with an owner, compensating controls, an expiry date (maximum [12] months), and a remediation plan.
5. Exceptions are reviewed at expiry and either remediated, renewed with fresh justification, or closed. Expired exceptions are escalated.

12. Review and Version Control

This policy is reviewed at least annually by the [Policy Owner], and additionally after any significant regulatory change, major incident, audit finding, or organizational change. Material changes require re-approval by the [Approving Authority]. All versions are retained for audit purposes.

12.1 Compliance and Enforcement

Compliance with this policy is mandatory. Violations may result in remediation requirements, suspension of vendor access, contract termination, and, for personnel, action under [Company Name] [HR / Disciplinary Policy]. Compliance is verified through periodic internal review and audit.

12.2 Version History

Version	Date	Author / Owner	Summary of changes	Approved by
[1.0]	[Date]	[Author]	Initial version adopted.	[Approver]
[ ]	[ ]	[ ]	[ ]	[ ]

12.3 Related Documents

• [Information Security Policy]
• [Data Protection / Privacy Policy]
• [Incident Response Plan]
• [Acceptable Use Policy]
• [Supplier Code of Conduct]
• [Business Continuity Policy]

12.4 Definitions

• Third party: any external organization or individual that provides goods or services to, or acts on behalf of, [Company Name].
• Fourth party: a subcontractor or sub-processor used by one of our third parties.
• Due diligence: the process of gathering and evaluating evidence about a third party's risk before and during the relationship.
• SOC 2: an independent audit report (Type I or Type II) on a service organization's controls relevant to security, availability, processing integrity, confidentiality, and privacy.
• ISO/IEC 27001: an international standard for an information security management system, with certification by an accredited body.
• DPA (Data Processing Agreement): a contract governing how a processor handles personal data on behalf of a controller.
• Trust center: a vendor's public page that publishes its security posture, certifications, audit reports, and sub-processors.
• Residual risk: the risk that remains after controls and mitigations have been applied.