Third Party Risk Management: Framework & Best Practices

Orca Security Team · 10-minute read

Key Takeaways

• Third-party risk management (TPRM) covers supplier selection, contracts, ongoing monitoring, and exit. Outsourcing work does not automatically transfer accountability.
• Risk-based tiers determine how closely to assess and monitor suppliers. Review fourth parties and concentration across critical activities.
• Contract terms should secure audit rights, incident notification, subcontractor notice, and data return before onboarding.
• A supplier register cannot show every package and dependency already running in cloud workloads; technical inventory complements vendor assessments.

Third-party risk management (TPRM) identifies, assesses, and controls risk from suppliers that process data, support operations, or reach your systems. Outsourcing an activity does not necessarily transfer your regulatory or contractual responsibilities. A risk-based lifecycle helps manage the relationship from selection through exit.

What is Third-Party Risk Management?

Third party risk management is the discipline of governing outside relationships as a portfolio of risk exposures. A third party is any external organization performing an activity on your behalf or reaching your systems, data, or customers. That covers cloud providers, payment processors, contract developers, and the analytics tool a marketing team signed up last quarter.

Third Party, Fourth Party, and Concentration

A fourth party is the third party’s own third party. Regulators call these subcontractors, defined as the “suppliers, service providers, or other organizations” a vendor enlists. A SaaS vendor holding your customer records runs on a hyperscaler, sends mail through a delivery service, and ships logs to an observability platform. None of them signed anything with you.

Concentration is the exposure a per-supplier review cannot surface. Two hundred assessments can each return green while one provider quietly carries five critical activities. NIST calls this an enterprise-level condition, listing “concentration of products or services from a single supplier” among vulnerabilities that sit above any one system. An alphabetical register hides it, and a register ordered by supported activity does not.

Why Third-Party Risk Management Is Critical for Modern Businesses

The reason is structural, and NIST calls it information asymmetry. Buyers “often lack visibility and understanding” of how the technology they acquire is developed, integrated, and deployed. You see a product page, an attestation, and an invoice, while the supplier sees its build pipeline, its staffing, and its incident history.

Cloud adoption widened that gap without touching the accountability. A finance team can put regulated data into a new platform in an afternoon, and security may hear about it at renewal. The vendor’s outage then becomes your outage, and its compromise becomes your breach notification.

For regulated organizations, the applicable rules depend on sector and geography. The 2023 interagency guidance gives US banks a lifecycle for third-party relationships. The EU’s Digital Operational Resilience Act requires financial entities to maintain an ICT contract register and sets contract and exit requirements. These are useful models, but their specific obligations should not be presented as universal requirements.

Understanding the Third-Party Risk Management Lifecycle

The 2023 interagency guidance describes five stages of a continuous lifecycle: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. The sections below follow a SaaS vendor that will hold customer records.

1. Planning and 2. Due Diligence

Planning decides whether the relationship should exist and how much scrutiny it earns. Regulators tie depth to consequence, saying the scope of due diligence should be “commensurate with the level of risk and complexity” of the relationship.

Due diligence then collects what the vendor can be made to show. That list runs to a SOC 2 report and its exceptions, an ISO certification and its scope statement, and a subprocessor list. The scope boundary is often the strongest signal, since it names which systems the auditor never examined. Relying solely on prior experience with a vendor “is not an adequate proxy”, and NIST warns against treating a first assessment as exhaustive.

A questionnaire is worth defending on its own terms. It is not evidence, and treating it as evidence is the error; it is a set of assertions the vendor chose to make. A later audit or breach investigation tests reality against those assertions. That function differs from what third-party and due-diligence assessments do for a team reviewing its own estate.

3. Contract Negotiation and Onboarding

Contracting is where a program acquires rights or spends three years without them. The joint guidance lists seventeen categories of provision, and four decide whether anything downstream is checkable. Audit and remediation rights set what evidence you can demand, and compliance responsibility fixes who answers to which regulator. Subcontracting terms decide whether fourth parties can change silently, and termination clauses govern the data on exit.

Negotiating power is the honest problem, and the guidance addresses it directly. Where a bank has “limited negotiating power”, it should understand the resulting limits and decide whether the residual risk is acceptable. It also offers a remedy rarely used, noting that organizations “may gain an advantage by negotiating contracts as a group”. Where neither works, the gap belongs on the risk register with a named owner.

4. Ongoing Monitoring

Monitoring exists because an assessment goes stale immediately, and the regulators say so. Both “the level and types of risks may change” across the life of a relationship, so a certification issued in March describes March.

The useful signals arrive without asking. Certificate expiry dates, published incident history, and subprocessor list changes are all public. The guidance names subcontractor use and location as monitoring factors, alongside changes to a vendor’s business strategy, financial condition, and key personnel. A subprocessor change is often the only public notice that a fourth party moved.

Each of those can be watched continuously, much as a team maintains continuous visibility across cloud assets it owns. Annual questionnaires across two hundred suppliers consume the year and confirm little. Continuous monitoring of higher-risk suppliers can complement periodic reassessment by surfacing relevant changes between formal reviews. Tiering makes that possible.

5. Termination and Exit

Exit is planned at signature or improvised under pressure. The guidance names what to settle in advance: alternate providers, the time needed to move, termination costs, and joint intellectual property.

The agencies also flag “data retention and destruction, information system connections and access control” as needing management after the relationship ends. An API key issued in year one still works in year four unless somebody revokes it. DORA agrees from the other side, requiring exit plans to be documented, tested, and reviewed. An untested exit plan is a document, not a control.

Which TPRM Frameworks Apply?

The right framework depends on the supplier, sector, and activity. Use these sources to shape the relevant parts of the lifecycle.

Framework or rule	What it prescribes	Lifecycle stage it governs
NIST SP 800-161r1	C-SCRM strategy, policy, and plans at the enterprise, mission, and operational levels	Planning and due diligence, with control requirements that flow into contracts
2023 Interagency Guidance	Risk management practice for each of the five stages, scaled to risk and complexity	All five stages
ISO/IEC 27036-2:2022	Information security requirements for supplier relationships, for buyers and suppliers alike	Contracting and onboarding
ISO/IEC 27036-3:2023	Visibility into dispersed, multi-layered hardware, software, and services supply chains	Due diligence and ongoing monitoring
DORA, Chapter V	A register of ICT contracts, pre-contract assessment, mandatory contract terms, tested exit plans	Planning, contracting, and exit

How to Build a Risk-Based TPRM Program

Building the program is mostly sequencing. You need a policy that settles arguments, a tiering rule that directs effort, and a register that survives someone leaving.

Set Policy, Ownership, and Risk Acceptance Rules

A third party risk management policy earns its place by settling disputes before they start. Who can sign a supplier contract, and above what value that changes. What triggers an assessment, since renewal and scope change both qualify. Which findings block onboarding, who accepts residual risk when a vendor will not negotiate, and how fast a supplier must notify you.

Tier Suppliers by Data, Access, Criticality, and Substitutability

Tiering makes the program affordable. Assign each supplier a tier from the activity it supports. The tier then sets diligence depth, contract terms, and monitoring cadence. This is the logic of prioritizing by risk rather than by count, applied to suppliers.

Four inputs decide the tier, and spend is not one of them.

• Data. Which categories the supplier holds or can reach, and whether any of it is regulated.
• Access. Whether it holds credentials, network paths, or code-execution rights in your environment.
• Criticality. Whether an outage stops a customer-facing process, and how long you can run without it.
• Substitutability. How fast the activity could move. DORA treats this as a supervisory criterion, citing the cost, time, and added risk of migrating data and workloads.

Run the concentration check once tiers exist. Group suppliers by supported activity, then look for one provider appearing under several critical ones. Regulators expect this reported to the board, listing “dependency on a single provider for multiple activities” among the items for periodic reporting.

How to Measure a TPRM Program

Third-party risk management, shortened to TPRM, is measured on throughput and coverage. The program works when assessments finish before contracts sign and the register matches reality. Five measures show that, and none of them is a maturity score.

• Register completeness. The share of active suppliers with a tier, a named business owner, and a contract on file. DORA makes this a formal artifact for ICT contracts.
• Coverage by tier. The share of tier-one suppliers with a current assessment, judged against the policy’s cadence and not the calendar year.
• Assessment cycle time. Days from request to decision. When this outruns procurement’s timeline, teams route around the process and shadow suppliers appear.
• Contract control coverage. The share of tier-one contracts carrying audit rights, breach-notification timelines, subcontractor notice, and data-return terms. This one predicts whether the next incident is investigable.
• Exit readiness. The share of critical suppliers with a documented and tested exit plan. It only looks good if somebody rehearsed it.

Where Orca Fits: Visibility into Cloud Software Dependencies

Orca is not a TPRM platform. It does not send or score vendor questionnaires, maintain a vendor register, or rate suppliers. Its own guide to SaaS security posture management draws that line, noting Orca answers infrastructure and workload questions across AWS, Azure, and GCP. Buying a supplier-governance tool stays a separate decision.

What Orca supplies is the half a questionnaire cannot reach: the third-party software already running inside your own estate. SideScanning™ collects data “from the workloads’ runtime block storage without requiring agents” and rebuilds the file system in a read-only view. Packages, libraries, and container images are then inventoried straight from the workload. Software composition analysis produces “a full SBOM of your Code repositories, including transitive dependencies”, which is the software equivalent of a fourth party.

To see agentless cloud coverage applied to the third-party code in your environment,Get a Demo.

Third-Party Risk Management FAQs

How is third-party risk management different from vendor management?

Vendor management runs the commercial relationship: selection, pricing, performance against service levels, and renewal. Third-party risk management asks what could go wrong and who answers for it. The two overlap at contracting and often report to different executives, which is where programs stall. The split works when vendor management owns the register and the calendar, and risk owns the assessment criteria.

What if a supplier refuses to share the information requested?

Treat it as a finding, not a dead end. The joint guidance expects a third party to sometimes be new, closed to site visits, or barred from sharing. Three options follow: accept the gap with a documented owner and review date, compensate with scoped credentials and encryption keys you hold, or decline. Which one applies depends on the tier.