View source for Third-Party Risk Management

'''Third-party risk management''' ('''TPRM''') is the organizational discipline of identifying, assessing, treating, monitoring, and governing risks created by relationships with external parties that provide products, services, technology, data processing, or other capabilities. It applies throughout a relationship's lifecycle, from planning and selection through contracting, operation, change, and termination.

Third parties may include suppliers, outsourced service providers, consultants, cloud platforms, software vendors, data processors, logistics partners, and other external organizations. Their activities can expose an enterprise to operational disruption, cybersecurity incidents, privacy violations, regulatory noncompliance, financial loss, concentration risk, or reputational harm.

TPRM is part of [[Enterprise Risk Management (ERM)]] and overlaps with [[Vendor Management]], [[Cybersecurity Risk Management]], [[IT Risk Management]], and [[Supply Chain Risk Management]]. Vendor management governs supplier relationships and commercial performance more broadly; TPRM evaluates the risks those relationships create and the adequacy of the enterprise's responses. In regulated banking, the US federal banking agencies' 2023 interagency guidance presents planning, due diligence, contract negotiation, ongoing monitoring, and termination as stages of the third-party relationship lifecycle.<ref name="bank">Board of Governors of the Federal Reserve System, FDIC and OCC (2023), ''Interagency Guidance on Third-Party Relationships: Risk Management'', [https://www.federalreserve.gov/frrs/guidance/interagency-guidance-on-third-party-relationships.htm official guidance], 6 June. The guidance applies to banking organizations supervised by the issuing agencies.</ref>

== Purpose and scope ==

TPRM enables organizations to use external capabilities while maintaining appropriate accountability for the resulting risks. Outsourcing an activity may transfer some responsibilities or costs, but it does not automatically transfer accountability for customer outcomes, contractual commitments, data protection, or legal obligations.

A TPRM program typically supports:
* Identifying and inventorying relevant third-party relationships and dependencies.
* Classifying relationships by criticality and risk exposure.
* Evaluating providers before selection or contract renewal.
* Establishing contractual security, performance, privacy, and continuity requirements.
* Monitoring controls, performance, incidents, changes, and financial stability.
* Coordinating corrective actions, exceptions, and risk acceptance.
* Preparing for business interruption, supplier failure, and orderly exit.

The intensity of oversight should reflect the nature of a relationship. An office-supply contract and a cloud platform hosting critical customer records do not warrant identical assessments. The 2023 banking guidance explicitly emphasizes risk-based oversight proportionate to the institution and relationship.<ref name="bank2">Federal Deposit Insurance Corporation (2023), ''Interagency Guidance on Third-Party Relationships: Risk Management'', [https://www.fdic.gov/news/financial-institution-letters/2023/fil23029.html supervisory summary], 6 June.</ref>

== Categories of third-party risk ==

{| class="wikitable"
! Risk category
! Illustrative exposure
! Typical evidence or control
|-
| Operational
| Supplier outage interrupts a critical business service
| Service continuity plan, resilience testing, service performance data
|-
| Cybersecurity
| Vendor access or compromised software exposes enterprise systems
| Access controls, independent assurance, vulnerability and incident procedures
|-
| Privacy and data protection
| Personal or confidential information is mishandled
| Data processing terms, retention rules, transfer controls, access audits
|-
| Regulatory and legal
| External activity causes a violation of applicable obligations
| Regulatory mapping, compliance assessment, audit rights, contractual duties
|-
| Financial
| Provider instability or adverse pricing disrupts expected delivery
| Financial review, commercial safeguards, alternative arrangements
|-
| Concentration
| Several important services depend on one provider or shared subcontractor
| Dependency mapping, concentration analysis, contingency planning
|-
| Strategic and reputational
| Provider conduct or limitations undermine business commitments
| Suitability assessment, governance review, ongoing stakeholder reporting
|}

These risks frequently interact. A common cloud-provider outage may simultaneously affect operational continuity, financial results, contractual commitments, and customer trust.

== Third-party risk management lifecycle ==

=== Planning and intake ===

Before entering a relationship, the sponsoring business unit identifies the service, intended outcomes, data involved, system access, critical dependencies, and any regulatory requirements. The organization determines whether an approved supplier already meets the need and whether the proposed arrangement creates concentration or other material risks.

A useful intake record specifies the business owner, supplier identity, service scope, data types, operational criticality, geographic exposure, and expected contract term. Procurement involvement should begin early enough to prevent unauthorized commitments or shadow supplier relationships.

=== Inherent-risk assessment and tiering ===

'''Inherent risk''' is the exposure associated with the proposed activity before considering relevant safeguards. Common assessment factors include access to sensitive data, privileged access to systems, interruption consequences, reliance on subcontractors, transaction volume, geographic exposure, and regulatory importance.

Organizations may use risk tiers, but the criteria and thresholds should be explicit. A high-risk classification signals the need for deeper review; it does not itself establish that the provider is unacceptable. Risk-based tiering should not rely solely on spend because a low-cost service may control an essential business dependency.

=== Due diligence and selection ===

Due diligence evaluates whether the provider is capable of performing the service securely, reliably, and in accordance with applicable obligations. It may examine service capability, governance, control effectiveness, recovery arrangements, financial condition, regulatory posture, subcontracting, and the history of material incidents.

Evidence can include security reports, independent certifications, audit findings, technical test results, customer references, contract terms, and recovery exercise records. A certification or standard questionnaire is useful only within its scope and period; it should not be mistaken for assurance about every product, location, control, or dependency.

For technology supply chains, NIST SP 800-161 Revision 1 provides a cybersecurity supply-chain risk management approach spanning strategy, policy, plans, and risk assessments.<ref name="nist">National Institute of Standards and Technology (2022), ''Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations'', NIST SP 800-161 Revision 1, [https://csrc.nist.gov/pubs/sp/800/161/r1/final official publication], 5 May.</ref>

=== Contract negotiation and approval ===

Contracts should allocate responsibilities, define required controls, and establish the organization's rights to monitor and respond. Relevant terms may concern performance levels, incident notification, confidentiality, security, audit access, data ownership, subcontractors, business continuity, liability, termination, and data return or deletion.

A contract is not an effective safeguard simply because it contains standard clauses. The terms must be appropriate to the service, enforceable where relevant, and operationally supported. High-risk exceptions should be approved by authorized risk owners rather than accepted informally by procurement staff.

=== Onboarding and operational integration ===

The provider is connected to approved business processes, systems, and governance arrangements. Activities may include identity provisioning, access review, data-transfer configuration, secure connectivity, service monitoring, and confirmation of incident contacts and escalation procedures.

Access should follow least-privilege principles and be revoked when no longer required. The enterprise should maintain records of the services and data that the provider actually handles rather than relying solely on its original proposal.

=== Ongoing monitoring ===

Monitoring assesses changes in exposure and whether contractual and control expectations remain satisfied. The cadence depends on service criticality and the risk profile. Relevant signals include incidents, control exceptions, financial deterioration, changes in subcontracting, new locations, service degradation, regulatory developments, and changes to technology architecture.

A periodic assessment can become stale before the next review. Material incidents, acquisitions, new data use, or a change of hosting provider may justify immediate reassessment. Findings should lead to clear owners, decisions, deadlines, and verification of corrective action.

=== Renewal, exit, and termination ===

Before renewing a relationship, the enterprise reviews performance, remaining risk, alternatives, and changes to business need. For termination, it plans transition to another provider, internal service delivery, or discontinuation.

Exit planning may require data retrieval, secure deletion, migration testing, continuity arrangements, license handover, credential revocation, asset recovery, and proof that subcontractors also meet relevant termination obligations. Termination is not complete merely when the commercial contract ends.

== Governance, ownership, and oversight ==

An effective TPRM operating model distributes responsibilities without allowing accountability to disappear between departments.

* '''Business or service owner:''' defines the need, owns the business consequences of the relationship, and sponsors necessary decisions.
* '''Procurement and vendor management:''' administer supplier selection, commercial processes, contracts, and performance coordination.
* '''Risk and compliance functions:''' establish assessment standards, advise on obligations, challenge risk decisions, and track material exposure.
* '''Cybersecurity and IT teams:''' evaluate technology dependencies, access, security controls, resilience, and integration risks.
* '''Legal and privacy teams:''' assess data obligations, rights, liabilities, and contractual protections.
* '''Executive or board oversight:''' monitors material exposure, concentration, risk appetite, and exceptions as appropriate to governance requirements.

Organizations should define who can accept residual risk and under what conditions. A supplier's commercial sponsor may understand business value but require independent challenge when the supplier poses material security, continuity, or compliance risk.

== Third-party inventories and risk registers ==

The '''third-party inventory''' identifies relationships, business owners, services, contracts, key dependencies, criticality, and lifecycle status. A '''risk register''' records specific exposure scenarios, risk assessments, controls, decisions, remediation work, and review triggers.

{| class="wikitable"
! Record
! Information it should preserve
|-
| Relationship identity
| Provider, legal entity, service, owner, contract and renewal dates
|-
| Dependency
| Critical business process, systems, data, locations, and subcontractors
|-
| Risk assessment
| Scenario, impact, likelihood where meaningful, assumptions, evidence
|-
| Safeguards and assurance
| Relevant controls, test scope, findings, evidence date and limitations
|-
| Decision
| Approved response, risk owner, authority, rationale, residual exposure
|-
| Monitoring and exit
| Reassessment triggers, incidents, remediation status, transition plan
|}

A single overall vendor score may hide materially different risk scenarios. Reporting should preserve the differences between, for example, financial distress, privileged access risk, and unavailable recovery arrangements.

== Fourth parties and concentration risk ==

A '''fourth party''' is commonly understood as a subcontractor or other external organization on which a direct supplier relies. An enterprise may have no direct contract with the fourth party, yet experience disruption if it fails.

Dependency maps should identify critical subcontractors and shared infrastructure where reasonably possible. Several direct suppliers may all depend on one identity provider, cloud region, telecommunications network, or data service. This creates concentration exposure that a supplier-by-supplier review can overlook.

The appropriate response may include diversified service design, contingency arrangements, increased testing, or explicit acceptance. Requiring every supplier to use a different subcontractor is neither always feasible nor necessarily risk-reducing.

== Measurement and reporting ==

TPRM should measure both the quality of the control process and the substantive risks being managed.

{| class="wikitable"
! Indicator
! Interpretation
! Limitation
|-
| Critical relationships with current assessments
| Coverage of risk review for important suppliers
| Completion does not prove that identified risks are controlled
|-
| Overdue high-risk remediation
| Unresolved material findings requiring action
| Depends on severity definitions and evidence of closure
|-
| Supplier incident impact
| Business effects of third-party failures
| Reporting gaps and attribution may distort the trend
|-
| Concentration exposure
| Reliance on common providers and dependencies
| Supplier counts alone do not establish resilience
|-
| Tested exit or recovery readiness
| Ability to continue or transfer critical services
| A written exit plan is not a successful transition test
|-
| Risk acceptance exceptions
| Exposure retained through authorized decisions
| More exceptions may reflect better detection rather than higher underlying risk
|}

Metrics should identify their population, observation window, evidence source, and exclusions. Supplier risk reporting should connect control findings to potential business consequences and specific decisions.

== Relationship to related disciplines ==

{| class="wikitable"
! Discipline
! Principal scope
! Relationship to TPRM
|-
| Vendor management
| Commercial relationships, performance, and supplier coordination
| Shares supplier records and coordinates contractual remedies
|-
| Cybersecurity risk management
| Cyber threats to business and information assets
| Assesses security exposures arising from third-party access and dependencies
|-
| Supply chain risk management
| Risks across sourcing, production, delivery, and dependency networks
| Overlaps where products, services, and subcontracting create shared exposure
|-
| Enterprise risk management
| Enterprise-wide risk appetite, aggregation, and governance
| Receives material third-party exposure for executive decision-making
|-
| IT risk management
| Risks affecting technology services and objectives
| Addresses technology-specific third-party risks
|-
| Business continuity management
| Continuation and recovery of essential activities
| Provides resilience requirements, tests, and transition arrangements
|}

== Common challenges ==

'''Incomplete inventories.''' Decentralized purchases and software subscriptions can escape formal review.

'''Questionnaire-driven assurance.''' Large assessments may collect documents without demonstrating the effectiveness of important controls.

'''One-size-fits-all processes.''' Low-risk suppliers receive excessive scrutiny while critical dependencies lack adequate testing.

'''Limited visibility into subcontractors.''' Hidden fourth-party dependencies can create concentration and continuity risks.

'''Unclear risk acceptance.''' Commercial teams may approve exceptions without authority to retain their business consequences.

'''Monitoring reduced to annual refresh.''' Material changes can occur between scheduled assessments.

'''Unworkable exit plans.''' Data portability or service migration may be contractually promised but not tested.

== Illustrative example ==

Consider a hypothetical healthcare technology company that relies on an external software provider to process appointment information. The provider stores sensitive data and depends on a cloud platform and a separate identity service. Before contracting, the company assesses data protection, availability, subcontractors, incident procedures, and recovery arrangements.

The contract defines required notification, access, audit, and termination obligations. During operation, the provider changes a critical subcontractor. The company reassesses the dependency, reviews control evidence, and updates its continuity plan. Later, a recovery exercise confirms whether data can be retrieved and services transferred within the required period.

The example illustrates that third-party risk management requires both initial due diligence and continuing oversight of real dependencies.

== See also ==

* [[Vendor Management]]
* [[Enterprise Risk Management (ERM)]]
* [[Cybersecurity Risk Management]]
* [[IT Risk Management]]
* [[Supply Chain Risk Management]]
* [[Business Continuity Management (BCM)]]
* [[Procurement Management]]
* [[Cloud Computing Governance]]

== References ==

<references />