A third-party risk program is easier to build, and to defend to an auditor, when the underlying concepts are kept distinct. Risk is not the same as criticality. A score is not the same as a decision. A vendor is not the same as the vendors it depends on. The pages in this cluster take those distinctions one at a time; this page shows how they connect.
The lifecycle is the spine
Every serious framework describes some version of the same arc: plan, select and perform due diligence, contract, monitor, and end the relationship. The U.S. interagency guidance on third-party relationships names exactly those stages (planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination) and says the depth of work at each should scale with the risk and criticality of the relationship. Start with what TPRM is for the overall definition, and why manual assessment stops scaling for the reason most programs eventually need to change how the work gets done.
Concepts, in the order a program needs them
1. Measure the exposure before the controls
Inherent vs residual risk separates the exposure a vendor relationship creates from what remains after controls. The definition of risk as a function of likelihood and impact comes from NIST SP 800-30 Rev. 1. The practical consequence: inherent risk decides how hard to look at a vendor, residual risk decides whether to accept it, and conflating the two is how a well-controlled but critical vendor ends up under-reviewed.
2. Decide how much attention each vendor gets
Vendor tiering turns inherent risk into a documented rule: which vendors get a full assessment, which get a light one, and which are only monitored. Without it, effort follows whoever shouts loudest. Tiering is also what makes the rest of the program affordable, because it is the mechanism that lets low-risk vendors be handled cheaply and on purpose.
3. Look past the contract boundary
Fourth-party risk covers the vendors your vendors depend on, and concentration risk covers what happens when many of those dependencies converge on one provider. They are related but not the same problem: fourth-party risk is about visibility down a supply chain, concentration is about the shape of the whole portfolio. EU rules treat both seriously; DORA requires a register of information on ICT third-party arrangements and a preliminary assessment of ICT concentration risk, including subcontracting chains, before critical arrangements are entered into.
4. Finish the relationship properly
Vendor offboarding is the stage nothing forces to happen, so it is the one most often skipped: access revoked, data returned or destroyed, and the evidence kept. A dormant integration with live credentials is a standing exposure that no assessment ever covers.
5. Use the shared vocabulary
The TPRM glossary defines the terms above and the standards around them, so teams, vendors, and auditors mean the same thing by "critical", "sub-processor", or "residual".
How the concepts depend on each other
Tiering needs an inherent-risk judgment, so it comes after risk is measured. Fourth-party and concentration analysis need an inventory of who the critical vendors are, so they come after tiering. Offboarding needs to know what each vendor can touch, which is what the earlier work produced. Skipping ahead usually shows up as a tool purchased to monitor vendors nobody has tiered, producing alerts that nobody can rank.
Where to start
New program: read what TPRM is, then tiering. Inheriting a program with a long vendor list and no structure: start with inherent vs residual risk and tier from there. When the fundamentals are in place, the frameworks and compliance clusters show which standards and regulations shape the detail.
Frequently asked questions
What are the fundamentals of third-party risk management?
The core ideas are a lifecycle (planning, due diligence, contracting, ongoing monitoring, and termination), a way to measure exposure (inherent risk before controls, residual risk after), a way to allocate effort (vendor tiering), visibility beyond direct vendors (fourth-party risk), a portfolio-level view (concentration risk), and a defined exit (offboarding with access revocation and data return or destruction). Most program failures come from skipping one of these or blurring two of them together, for example scoring only residual risk and so under-reviewing critical vendors that happen to be well controlled.
What are the stages of the third-party risk management lifecycle?
The U.S. interagency guidance on third-party relationships (2023) describes five stages: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. The guidance expects the depth of work at each stage to scale with the risk and criticality of the relationship, which is why tiering sits near the front of a program. Other frameworks name the stages differently, but the arc from selection through monitoring to exit is consistent across them.
What is the difference between third-party, fourth-party, and concentration risk?
Third-party risk is the risk from a vendor you contract with directly. Fourth-party risk is the risk from the vendors that your vendor depends on, which you usually have no contract with and limited visibility into. Concentration risk is a portfolio property: many vendors, or many critical functions, depending on the same provider, region, or technology, so that one failure affects several of your services at once. A vendor can pass every individual assessment and still contribute to concentration.
Where should a new TPRM program start?
With an inventory and a tiering rule. List who your vendors are and what data and systems each can reach, then classify them by inherent risk so effort is proportional: deeper assessment for critical or data-heavy vendors, lighter treatment for the rest. Monitoring and automation are worth adding after that, because they are far more useful when applied to a tiered inventory than to an undifferentiated list.
What is the difference between inherent risk and residual risk?
Inherent risk is the exposure a vendor relationship creates before any controls are considered, driven by factors such as data sensitivity, system access, and how critical the service is. Residual risk is what remains after the vendor's controls and your own compensating controls are taken into account. Inherent risk should drive how deeply a vendor is assessed; residual risk should drive the decision to accept, remediate, or exit.