The terms below are grouped by what they describe rather than listed alphabetically, because most of them only make sense next to the concept they modify. Jump to any term directly, or read a group in order.
Program fundamentals: TPRM, VRM, C-SCRM, inherent risk, residual risk, vendor tiering, vendor due diligence.
Portfolio risk concepts: fourth-party risk, Nth-party risk, concentration risk, vendor offboarding.
External signal & monitoring: attack surface, ASM, security rating, continuous monitoring.
Questionnaires & certifications: SIG, CAIQ, SOC 2, SOC 2 Type I vs Type II, ISO/IEC 27001, ISO/IEC 27036.
Regulations & contract terms: DORA, NIST SP 800-161, BAA, DPA, subprocessor, right-to-audit clause.
Program fundamentals
TPRM (third-party risk management)
The overarching discipline of identifying, assessing, and controlling the risk that vendors, suppliers, contractors, and other outside parties introduce into an organization. See what is TPRM for the full lifecycle.
VRM (vendor risk management)
Often used interchangeably with TPRM. Where practitioners draw a line, VRM tends to describe the narrower practice of assessing software and service vendors specifically, while TPRM is treated as the broader umbrella that also covers contractors, staffing agencies, and other non-vendor third parties a program is accountable for.
C-SCRM (cyber supply chain risk management)
NIST's term for managing the cybersecurity risk that enters an organization through its supply chain - the hardware, software, and services it acquires from suppliers, and the subcontractors those suppliers rely on in turn. NIST SP 800-161 Revision 1 is the primary US federal standard for building a C-SCRM program.
Inherent risk
The exposure a vendor represents before any controls are considered. A payroll processor handling employee PII is inherently high-risk regardless of how well it is actually secured, simply because of what it touches.
Residual risk
What remains after accounting for the vendor's own controls and any compensating measures on your side. Tiering, monitoring intensity, and reassessment cadence should be driven by residual risk, not inherent risk alone - two vendors with identical inherent risk can warrant very different scrutiny depending on how well each is actually controlled.
Vendor tiering
Sorting vendors into risk tiers - typically critical, significant, and low - based on factors like data access, operational dependency, and regulatory scope, so assessment depth and monitoring intensity scale with actual exposure instead of being applied uniformly. See the tiering table in security ratings vs evidence-based TPRM for a worked example.
Vendor due diligence
The pre-contract review of a prospective vendor's security controls, financial stability, and reputation, typically combining a questionnaire (SIG or CAIQ), certification review (SOC 2, ISO 27001), and reference or background checks before onboarding.
Portfolio risk concepts
Fourth-party risk
The risk introduced by your vendor's own vendors - the cloud provider a SaaS tool runs on, or the payment processor a platform integrates with. You have no direct contract with a fourth party, so visibility depends entirely on your vendor disclosing its subcontractors.
Nth-party risk
The general case of fourth-party risk extended to any tier of subcontracting beyond the fourth party - fifth parties, sixth parties, and so on down a subcontracting chain. Frameworks increasingly expect firms to map this chain rather than stop at the first tier; DORA, for example, extends its ICT third-party requirements to "sub-outsourcing" arrangements that support critical functions.
Concentration risk
The exposure created when many of an organization's vendors - or an entire sector's vendors - depend on the same underlying provider: a single cloud region, a single identity provider, a single payment rail. One provider's outage or compromise then cascades across vendors that look independent on paper. DORA requires in-scope financial entities to assess and manage ICT concentration risk explicitly, not just vendor by vendor.
Vendor offboarding
The end-of-relationship process: revoking access (SSO, VPN, physical badges), confirming the vendor has returned or certified destruction of your data, and closing out contractual obligations. It is often the weakest-governed stage of the lifecycle, since - unlike onboarding or renewal - nothing forces it to happen on a schedule.
External signal and monitoring
Attack surface
The complete set of internet-facing assets and entry points - exposed services, subdomains, certificates, DNS records, cloud storage, known software versions - that an attacker could target. NIST's definition describes it as the set of points on a system's boundary where an attacker can try to enter, affect, or extract data from that system.
ASM (attack surface management)
The continuous discovery, inventory, and monitoring of an attack surface - yours or a vendor's - so new exposure is caught as infrastructure changes, rather than assessed once and assumed static.
Security rating
A numeric or letter score of a vendor's external security posture, assembled from attack-surface and other observable signals by a rating provider without requiring the vendor's participation. See security ratings vs evidence-based TPRM for what these scores capture well and where they fall short.
Continuous monitoring
Assessment that runs on an ongoing basis rather than a fixed calendar - watching for new vulnerabilities, breach signals, and posture drift between formal reassessments. See continuous vendor monitoring for what it typically watches.
Questionnaires and certifications
SIG (Standardized Information Gathering questionnaire)
A modular, standardized vendor-security questionnaire published by Shared Assessments, built so buyers do not each invent their own question set and vendors can reuse validated answers across customers instead of re-answering the same questions for every deal.
CAIQ (Consensus Assessments Initiative Questionnaire)
A questionnaire published by the Cloud Security Alliance as part of its STAR program, mapped to the CSA Cloud Controls Matrix. It is the cloud-focused counterpart to the SIG and is the more common choice when the vendor being assessed is a cloud service provider specifically.
SOC 2
A System and Organization Controls report defined by the AICPA, in which an independent CPA firm attests to a vendor's controls against the Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). Reports are delivered to customers under NDA rather than published publicly.
SOC 2 Type I vs Type II
A Type I report opines on whether controls are suitably designed at a single point in time. A Type II report opines on whether those same controls operated effectively over an observation period, typically six to twelve months. For TPRM purposes, a Type II report covering a longer period is materially stronger evidence than a Type I snapshot.
ISO/IEC 27001
The international standard for an information security management system (ISMS). Certification means an accredited body has audited the vendor's ISMS against the standard's control set, not just reviewed a self-attestation. See the current edition on iso.org.
ISO/IEC 27036
The ISO standard specifically for information security in supplier relationships, published in parts covering overview and concepts, requirements, ICT supply chain security, and cloud services. Where ISO/IEC 27001 covers an organization's ISMS broadly, ISO/IEC 27036-1 is the part TPRM programs cite specifically when justifying how supplier risk should be evaluated and managed.
Regulations and contract terms
DORA (Digital Operational Resilience Act)
The EU regulation, applicable to financial entities since January 2025, that imposes specific ICT third-party requirements: a register of contractual arrangements, mandatory contract clauses covering audit rights and exit strategies, concentration-risk assessment, and direct regulatory oversight of providers designated "critical." See the regulation text on EUR-Lex.
NIST SP 800-161
NIST Special Publication 800-161 Revision 1, "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations" - the primary US federal C-SCRM standard, defining a supply chain risk management program with documented controls mapped to the broader NIST SP 800-53 control catalog.
BAA (Business Associate Agreement)
A contract required under HIPAA between a covered entity and any vendor ("business associate") that creates, receives, maintains, or transmits protected health information (PHI) on its behalf. It obligates the business associate to safeguard PHI and to flow the same obligations down to its own subcontractors. See HHS guidance on business associates.
DPA (Data Processing Agreement)
A contract required under GDPR Article 28 between a data controller and any processor handling personal data on its behalf. It must specify the subject matter, duration, and purpose of processing, require the processor to act only on documented instructions, and require the processor to impose the same obligations on any sub-processor it engages.
Subprocessor
A vendor's own vendor engaged to help process your data on the vendor's behalf - for example, the cloud hosting provider behind a SaaS product. This is the fourth-party relationship expressed as a data-protection term: under GDPR, engaging a subprocessor requires the controller's specific or general written authorization and contractually binding the subprocessor to the same data-protection obligations.
Right-to-audit clause
A contract provision giving the customer, or a party acting on its behalf, the right to inspect a vendor's controls, request evidence, or conduct an on-site or remote audit - sometimes with reciprocal terms that let a vendor satisfy multiple customers through a single pooled audit instead of many. DORA explicitly requires audit and access rights in ICT third-party contracts supporting critical functions.
Where to go next
For the full program lifecycle these terms sit inside, start with what is TPRM, then continuous vendor monitoring and evidence-based risk scoring for how modern programs keep this vocabulary current rather than filed away in an annual questionnaire. For platform evaluation, see comparing TPRM platforms.
Frequently asked questions
What is the difference between inherent risk and residual risk in third-party risk management?
Inherent risk is the exposure a vendor represents before any controls are considered, based on factors like the data it can access and how critical it is to your operations. Residual risk is what remains after accounting for the vendor's own controls and any compensating measures your organization has in place. Mature programs tier vendors and set monitoring intensity based on residual risk, since two vendors with identical inherent risk can warrant very different levels of scrutiny depending on how well each is actually controlled.
What is a fourth-party vendor?
A fourth party is your vendor's own vendor - for example, the cloud infrastructure provider a SaaS tool runs on, or a payment processor a platform integrates with. You have no direct contract with a fourth party, so visibility into it depends on your vendor disclosing its subcontractors. Extending the same idea further down a subcontracting chain - fifth parties, sixth parties, and beyond - is generally called Nth-party risk, and regulations like DORA increasingly expect firms to map that chain rather than stop at the first tier.
What does C-SCRM stand for and how does it relate to TPRM?
C-SCRM stands for cyber supply chain risk management, the term NIST uses in NIST SP 800-161 for managing cybersecurity risk introduced through an organization's supply chain of hardware, software, and services. It overlaps heavily with third-party risk management but frames the problem specifically around supply chain integrity and federal control mapping, while TPRM is the broader, vendor-inclusive discipline covering the full lifecycle from intake through offboarding.
What is the difference between the SIG and CAIQ questionnaires?
The SIG (Standardized Information Gathering questionnaire), published by Shared Assessments, is a general-purpose, modular vendor-security questionnaire used across industries. The CAIQ (Consensus Assessments Initiative Questionnaire), published by the Cloud Security Alliance as part of its STAR program, is mapped specifically to the CSA Cloud Controls Matrix and is the more common choice when the vendor being assessed is a cloud service provider. Many programs use the SIG as their default questionnaire and substitute or supplement it with the CAIQ for cloud-specific vendors.