Residual risk, done right — what a vendor's risk actually is after your controls

Every vendor program starts by scoring inherent risk — the risk a vendor carries by virtue of what they do: the data they hold, the access they have, how critical they are. A financial-data aggregator with admin-level API access and customer banking data scores critical, full stop. That’s the right starting number.

But inherent risk isn’t the number you manage to. You don’t walk away from every critical vendor — you put controls around them: MFA on their credentials, quarterly access reviews, network segmentation. The risk you actually carry, after those controls, is your residual risk. And residual is the number that matters: it’s what tells you where to spend attention, and it’s what an auditor expects you to defend.

That’s exactly where most programs get hand-wavy. “We have controls, so it’s fine” isn’t a residual-risk assessment — it’s an assertion. ISO 27001:2022 frames it precisely: clause 6.1.2 has you assess risk, 6.1.3 has you treat it with controls, and what’s left is residual risk that someone has to formally own. SOC 2’s risk-assessment criteria expect the same: risks identified, controls mapped, residual evaluated. Talarity makes that chain explicit and arithmetical — residual is computed from the controls you link, and it only credits the controls that have actually been tested and passed.

Who’s involved

• Risk / vendor manager — links the compensating controls that mitigate a vendor’s inherent risk and sets how much each one carries.
• Control owner — runs the effectiveness test that turns a control from “we have it” into “it works,” which is what lets it count toward residual.
• Auditor — reads the residual number and the controls behind it: which controls, how effective, how weighted, with the test results that back them.

What’s on the page

This all happens on a vendor’s Risk Profile, where two panels sit one above the other:

• The inherent-risk panel — the vendor’s seven weighted factors producing an inherent score and tier (e.g. Critical, score 81). This is risk before any mitigation.
• The residual panel — initially mirrors inherent (Critical → Critical). As you link compensating controls — each with a weight and a rationale — it recomputes: the residual score and tier drop, the percentage reduction is shown, and each control’s effectiveness and weight are listed. A counter (“2 of 3 linked controls have effectiveness data”) flags controls that contribute nothing yet.

The rest of this guide walks that residual panel moving as controls are linked, tested, and verified.

Step 1 — Inherent risk: the question

Open a vendor’s Profile tab and the Risk Profile panel shows the inherent score — a seven-factor weighted model across data sensitivity, business criticality, system access, service type, fourth-party exposure, regulatory exposure, and industry risk (breach likelihood for the vendor’s sector). Each factor is rated and weighted; the blend produces an inherent tier.

Here, Ledgerlink scores Critical (81): financial data, admin access, data-processing service type. Directly below, the Residual Risk from Verified Controls panel starts honest — Inherent (Critical) → Residual (Critical), 0% risk reduction. With no controls credited, residual equals inherent. That’s the correct default: you don’t get a discount for controls you haven’t accounted for.

Step 2 — Link a compensating control

Under Link a Compensating Control, you pick an internal control, set a weight (0–1 — how much of the vendor’s risk this control addresses), and add a rationale.

The weight is the judgement call, and it’s worth making deliberately. A control that addresses the dominant driver of a vendor’s inherent risk — here, MFA + IP allow-listing against the privileged-API-access exposure — earns a high weight. A control that addresses a narrower slice earns less. The rationale is where you record why this control compensates for this vendor’s risk, so the weight isn’t an unexplained number at audit time.

Step 3 — Residual moves, and the math is visible

Link it, and residual recalculates immediately: Critical (81) → Medium (37), a 54% risk reduction, with the control shown at 100% effective · 60% weight.

The formula behind the number is deliberately simple and inspectable:

residual score = inherent × (1 − Σ(weight × effectiveness) × 0.9)

For Ledgerlink’s one control: 81 × (1 − 0.6 × 1.0 × 0.9) = 81 × 0.46 ≈ 37 → Medium. The × 0.9 is a hard cap: controls can reduce inherent risk by at most 90%, never to zero. No stack of controls turns a critical vendor into a no-risk vendor — there’s always a residual floor, because there’s always a residual risk.

The effectiveness in that formula isn’t a guess either — it comes from the control’s effectiveness test. A passed test is 100% effective, a partial test is 50%, a failed test is 0%. Which leads to the part that makes this defensible.

Step 4 — Stack controls; watch the cap

Add a second verified control — a quarterly access review at weight 0.4 — and the reductions compound: Critical (81) → Low (8), a 90% reduction.

The two controls’ weighted effectiveness sums to 100%, so the 90% cap kicks in: residual lands at 8 (Low) and won’t go lower no matter how many more controls you add. Each linked control shows its own effectiveness and weight, and each has a Remove — unlink one and residual recalculates back up. The panel is a live ledger of why this critical vendor is, in practice, a low-residual one.

Step 5 — “Verified” is the load-bearing word

Here’s the part that separates a residual number you can defend from one you can’t. Link a control that hasn’t been effectiveness-tested — the picker even labels it “(not tested)” — and give it a hefty 50% weight. Residual doesn’t budge:

The untested control sits in the list showing “no test data · 50% weight,” the summary reads “2 of 3 linked controls have effectiveness data,” and the residual stays exactly where it was — Low (8). An untested control’s effectiveness is null, and null contributes zero to the formula regardless of its weight.

This is the whole point of the feature, and the reason the panel says Verified Controls. You cannot talk your way to a lower residual by linking controls you haven’t proven work. “We have a vendor questionnaire” doesn’t move the number; “we ran the effectiveness procedures and it passed” does. The residual you present at audit is therefore backed by tested controls only — which is exactly the chain ISO 27001 clause 6.1.3 and SOC 2 expect: control identified → control tested → residual risk evaluated against what actually works.

You can still link an untested control — that’s useful for staging the controls you intend to test — but it openly contributes nothing until its effectiveness test passes. There’s no silent credit.

What you walk away with

• A residual risk number per vendor that’s computed, not asserted — inherent risk minus the weighted effectiveness of the controls you’ve linked, with a visible formula and a 90% reduction cap.
• A defensible chain: each point of risk reduction traces to a specific control, its weight, its rationale, and — critically — its passed effectiveness test.
• Honest accounting: untested controls can be staged but contribute zero; the panel always shows how many of the linked controls actually count.
• A live ledger an auditor can read top to bottom: this critical vendor carries low residual risk, and here is precisely why.

Open your most critical vendor, link the one control you’re most confident in — the one you’ve actually tested — and watch the residual drop with the math shown. Then try linking one you haven’t tested, and watch it do nothing. That difference is the difference between a residual-risk program and a wish list.