Two vendors can look identical on an intake form - same data access, same contract value, same integration - and still warrant completely different levels of scrutiny. The reason is that "vendor risk" is really two separate measurements. Inherent risk is what a vendor relationship exposes you to before any controls are considered. Residual risk is what's left after you account for the vendor's actual controls and your own compensating measures. A program that scores only one of these, or scores them together as a single blended number, cannot tell a well-controlled high-exposure vendor from a poorly-controlled one - which is exactly the distinction a risk program exists to make.
Defining the two terms precisely
NIST's Computer Security Resource Center glossary defines inherent risk, via NIST IR 8286 (itself drawing on the COSO Enterprise Risk Management framework), as "the risk to an entity in the absence of any direct or focused actions by management to alter its severity". In vendor terms: what does this relationship expose you to, independent of anything the vendor or you do to reduce it? Inherent risk is a function of what the vendor touches - the type and volume of data it can access, how operationally dependent you are on it, its regulatory scope, and where it and its subprocessors sit jurisdictionally.
Residual risk is what remains after controls are applied. NIST SP 800-30 Revision 1 defines it, via CNSSI 4009, as the "portion of risk remaining after security measures have been applied." In vendor terms: given the vendor's actual controls - encryption, access management, incident response, audited certifications - and any compensating measures on your side, how much of the inherent exposure is actually still live? Residual risk is the number that should drive a tiering or onboarding decision, because it reflects the relationship as it really operates, not as a worst case.
Scoring each independently
The two scores need different inputs, so score them as separate steps rather than one blended judgment call.
| Inherent risk factors (fixed by the relationship) | Residual risk factors (change with controls) |
|---|---|
| Data sensitivity and volume the vendor can access | Certification and audit evidence quality (SOC 2 Type II vs. self-attestation) |
| Operational dependency - what breaks if the vendor is unavailable | Access control and encryption practices, validated rather than claimed |
| Regulatory scope of the data or function involved | Incident history and how the vendor has handled past events |
| Integration depth and privileged access granted | Continuous monitoring signal - has posture held steady or drifted? |
| Subprocessor chain and jurisdictional exposure | Contractual protections: audit rights, breach notification terms, liability |
A simple, defensible approach many programs use: score inherent risk on the left-hand factors to land a vendor in a tier (critical, significant, low), then score residual risk on the right-hand factors as a modifier within that tier - "high inherent, well-controlled" and "high inherent, poorly controlled" land in the same inherent tier but get very different assessment depth, monitoring intensity, and contract terms.
A worked example
Consider two vendors with the same inherent risk profile - both process employee PII and both are operationally critical to payroll. Vendor A has a current SOC 2 Type II report, enforces MFA and encryption at rest, and has no incident history. Vendor B has only a self-attestation, no evidence of encryption practices, and a publicly disclosed breach eighteen months ago. Both start at the same inherent-risk tier - critical - because inherent risk describes the exposure, not the vendor's behavior. But Vendor A's residual risk is materially lower than Vendor B's, and that difference should show up directly in monitoring cadence, reassessment frequency, and how much contractual protection you insist on. A program that stops at "both are critical vendors" and treats them identically has thrown away the one distinction that should change what it does next.
Where programs get this wrong
- Letting controls move the inherent score. Inherent risk describes what the relationship touches, not how well it's protected - it should only change if the relationship changes (more data, more access, a new use case), not because the vendor added a control.
- Scoring residual risk once, at onboarding, and never again. A control set assessed at onboarding degrades in relevance the moment conditions change - a certification lapses, a new vulnerability surfaces, staff turns over. Residual risk needs the same continuous reassessment that any current-state measurement does; a residual score from an annual questionnaire is already partly wrong on day two.
- Tiering by inherent risk alone. Inherent risk is useful for deciding how deep an assessment should be. It's a poor basis for deciding how much ongoing scrutiny a vendor gets once assessed - that decision belongs to residual risk, because it's residual risk that actually changes over the life of the relationship.
- No documented methodology. If a score can't be traced to specific inherent factors and specific control evidence, it isn't defensible to an auditor or to the vendor itself. See evidence-based vendor risk scoring for what a traceable residual score looks like in practice.
Why the distinction is a compliance expectation, not just good practice
This is not TPRM-specific vocabulary - it's core enterprise risk management terminology that regulators and standards bodies now expect to see applied to vendors specifically. The COSO Enterprise Risk Management framework treats the inherent/residual distinction as foundational to how any organization should reason about risk before and after treatment. NIST SP 800-30 builds its risk-assessment methodology around the same before-and-after structure, and the tiering framework in security ratings vs evidence-based TPRM shows how to allocate assessment effort using exactly this split. A program that can show a regulator or customer both numbers, and the methodology connecting them, has a materially stronger answer than one that can only produce a single, unexplained "risk score."
Putting it into a program
In practice: use inherent risk to decide how much assessment a vendor gets up front, and use residual risk - re-measured as evidence and monitoring signal change - to decide how much ongoing scrutiny it keeps. Platforms that pair continuous monitoring with evidence-based scoring, Rescana among them, are built to keep the residual number current automatically rather than relying on a human to remember to re-run it. Whatever platform runs the program, the two scores should be visibly separate and each traceable to the factors behind it.
Frequently asked questions
How do you calculate residual risk for a third-party vendor?
Residual risk is calculated by starting from the vendor's inherent risk - what the relationship exposes based on data access, operational dependency, and regulatory scope - and then adjusting for the vendor's actual controls: certification and audit evidence (such as a current SOC 2 Type II report), validated access management and encryption practices, incident history, and contractual protections like audit rights and breach notification terms. There is no single universal formula; most programs use a structured rubric that scores control effectiveness against each inherent-risk factor and treat the result as a modifier within the vendor's inherent-risk tier. The key requirement is that the calculation is documented and traceable, so a regulator, auditor, or the vendor itself can see which specific controls moved the score.
Does a vendor's inherent risk change if they add new security controls?
No. Inherent risk describes the exposure created by what the vendor relationship touches - the data it can access, how critical it is to your operations, its regulatory scope - independent of how well that access is protected. Adding a control changes residual risk, not inherent risk. Inherent risk should only change if the relationship itself changes: the vendor is granted more data or access, takes on a new function, or its regulatory scope shifts. Conflating the two is a common scoring error - it makes it impossible to distinguish a well-controlled high-exposure vendor from a poorly-controlled one, which is the distinction a risk program needs to make.
Should vendor tiering be based on inherent risk or residual risk?
Both, at different points in the process. Inherent risk is the right input for deciding how deep an initial assessment should be - a vendor with high inherent risk warrants full evidence-based due diligence, while a low-inherent-risk vendor may only need a lighter check. Residual risk is the right input for deciding ongoing monitoring intensity and reassessment cadence, because it reflects the vendor's actual current control state and changes over the life of the relationship as evidence and monitoring signals change. Tiering on inherent risk alone treats a well-controlled vendor the same as a poorly-controlled one with identical exposure, which misallocates scarce assessment and monitoring effort.