> ## Documentation Index
> Fetch the complete documentation index at: https://docs.visotrust.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Risk Analysis
> Read the Risk Analysis view in VISO TRUST: what impact, likelihood, control mitigation, and residual risk mean, and how each number is calculated.
**Risk Analysis** shows the work behind a vendor's risk score — which controls were in scope, what evidence was found, how much risk that evidence removed, and what remains. It's a snapshot of one assessment: every number reflects the evidence that existed when that assessment completed.
## Where to Find It
Risk analysis lives on the relationship's **Assessments** tab. Select an assessment from the selector at the top of the tab, then use the left sidebar to move between sections.
The sidebar starts with **Assessment summary** — risk level cards, the assessment timeline, artifacts, and the AI-generated summary — followed by two groups:
| Group | What it contains |
| ------------------ | ------------------------------------------------------------------------------------------------------ |
| **Risk analysis** | **All controls**, plus one section per [risk dimension](/risk-and-monitoring/control-domains) in scope |
| **Questionnaires** | One section per questionnaire attached to the relationship |
The ring next to each entry is a progress indicator — green for satisfied, red for the remainder. On risk analysis entries it's the share of in-scope controls that evidence shows are present; on questionnaire entries it's the share of questions answered. The Security entry also shows its residual risk label.
Older assessments were calculated with a previous version of the risk model. When you select one, the sidebar shows "Risk analysis history is not available for some older assessments" and the risk analysis sections can't be opened. The assessment summary and the questionnaire sections still work.
## Reading a Dimension
Each risk dimension opens with a card summarizing the dimension, followed by the full control list.
The card shows:
* **Control mitigation** — a bar and a percentage: the share of the dimension's in-scope controls that evidence shows are present
* **Inherent risk → residual risk** — the two risk levels for this dimension (Security only)
* **Risk breakdown** — an expandable, step-by-step walkthrough of the calculation
* **Download** — exports the underlying risk model output as CSV
The control mitigation percentage counts controls; the **control mitigation** value inside the risk breakdown is weighted. A dimension can show a high percentage of controls present while mitigating much less of its weight, if the controls with the most weight are the ones without evidence.
The relationship's headline risk score comes from the **Security** dimension — that's the inherent and residual risk used across the platform, and the only dimension that shows the full inherent → residual breakdown. Other dimensions show likelihood and mitigation so you can judge coverage.
## The Risk Breakdown
Expand **Risk breakdown** on the Security dimension to see the five steps that produce the score. Every value is on a 0–1 scale.
Other dimensions show a shorter breakdown — likelihood and mitigated likelihood only — because impact and the risk scores are set at the Security level.
### Step 1 — Impact: What's At Stake
Impact is set by the **highest sensitivity data type** shared with the vendor. One extremely sensitive data type sets impact for the whole relationship — sensitivities don't add up.
The step shows the data type responsible and its numeric sensitivity. See [Data Types](/third-parties/advanced/data-types).
### Step 2 — Likelihood: Controls In Scope
Likelihood is the share of your control framework that applies to this vendor. The more of your framework is in scope, the larger the threat surface.
Three numbers are shown:
| Metric | Meaning |
| ---------------------------- | -------------------------------------------------------------------------------------------------- |
| **Control domains in scope** | How many of this dimension's control domains apply to this relationship, out of all of its domains |
| **Control domain weight** | The combined weight of those in-scope domains, out of the dimension's total domain weight |
| **Likelihood** | The resulting likelihood value |
The **All controls** section shows the same three numbers across your whole framework rather than a single dimension.
Likelihood starts at 1 and is reduced by:
* the weight of every control domain that is **out of scope** for this relationship, and
* the weight of every individual control marked **Not applicable** inside an in-scope domain.
```
Likelihood = 1 − (weight of out-of-scope domains + weight of not-applicable controls)
```
Scope is driven by the business cases selected during relationship configuration. Narrowing the business cases takes domains out of scope and lowers likelihood. The bar underneath is clickable — selecting a segment jumps to that control domain in the list below.
### Step 3 — Inherent Risk
```
Inherent risk = Likelihood × Impact
```
Inherent risk is the baseline exposure before any credit for controls. The resulting score is mapped to a risk label using your organization's [risk tolerance](/risk-and-monitoring/risk-model).
### Step 4 — Mitigated Likelihood: What Controls Reduce
**Control mitigation** is the total weight of controls the vendor has proven, discounted by how trustworthy the evidence is. Subtracting it from likelihood leaves the part of the threat surface that is still unaddressed.
```
Unmitigated likelihood = Likelihood − Control mitigation
```
Mitigation only counts in-scope controls, and only where there is evidence. A control with no supporting evidence contributes nothing, no matter what the vendor claims. Controls marked **Not applicable** aren't counted as mitigation — their weight was already removed from likelihood in step 2.
### Step 5 — Residual Risk
```
Residual risk = Unmitigated likelihood × Impact
```
Residual risk is the number to act on. Impact never changes between the two calculations — controls reduce risk by shrinking likelihood, never by lowering the consequences of a breach.
### The Risk Graph
Below the steps, the risk graph plots likelihood (vertical) against impact (horizontal), with colored bands for each risk label under your current risk tolerance. Two markers are placed on it:
* **I** — inherent risk
* **R** — residual risk
The distance between them is the credit the vendor earned from evidence. A marker sitting high on the likelihood axis with little vertical drop means broad scope and thin evidence.
## Metrics Reference
| Metric | What it measures | How it's calculated |
| --------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Impact** | Severity if the vendor were compromised | Sensitivity of the most sensitive data type shared with the vendor |
| **Likelihood** | Size of the threat surface | 1 minus the weight of out-of-scope domains and not-applicable controls |
| **Inherent risk** | Exposure before controls | Likelihood × Impact |
| **Control mitigation** | Risk removed by proven controls | Sum of control weight × assurance × presence, across in-scope controls |
| **Unmitigated likelihood** | Threat surface still unaddressed | Likelihood − Control mitigation |
| **Residual risk** | Exposure after controls | Unmitigated likelihood × Impact |
| **Control domain weight** | A domain's share of the framework | Set per control domain in your framework |
| **Relative control weight** | A control's share of its domain | The control's own weight ÷ the total weight of every control in the domain |
| **Control weight** | A single control's contribution to likelihood | Control domain weight × Relative control weight |
| **Highest assurance** | Trustworthiness of the best evidence for a control | Assurance level of the highest-assurance artifact detection, reduced if the artifact is expired or description-only |
## The Control List
Under each dimension card, every control domain is listed with a bar showing how many of its controls are present. Domains that don't apply are labeled **Out of scope** or **Not applicable**.
Filter and search the list with:
* **All / Sufficient / Insufficient** — a domain counts as **Sufficient** only when every one of its controls is present; anything short of that is **Insufficient**. Both counts cover in-scope domains only.
* **Search** — match on control domain name
* **Detection types** — narrow to Subservicers, Sub-processor, Shared Responsibility, or CUEC detections
* **Issues** — narrow to domains with an **Exception** or an **Expired artifact**
Expand a domain to see its individual controls. Each control shows a status indicator:
| Indicator | Meaning |
| ----------- | -------------------------------------------------------------------------------------------------- |
| Green check | **Present** — evidence confirms the control is in place |
| Red error | **Not present** — evidence says the control is missing, or an audit raised an exception against it |
| Grey | **Not applicable** — the control doesn't apply to this vendor |
The ring around the indicator shows how much of that control's weight the evidence actually mitigated. A green check with a partial ring means the control is present, but the evidence supporting it carries less than full assurance.
Under each control are the **detections** — the specific passages in specific artifacts that substantiate it. Detections that disagree with the control's outcome are collapsed behind **Show irrelevant detections**: on a control judged present, that's the detections saying it isn't, and vice versa. Expand them when you want to see why a control landed where it did.
## Control Details
Select **View control details** from a control's menu to open a panel with the full calculation for that one control:
* **Description** — what the control requires
* **Control weight** — `Control domain weight × Relative control weight = Control weight`
* **Supporting evidence** — the highest assurance level found, the artifact it came from, and the test result if the control was tested
* **Control mitigation** — how much of the control's weight the evidence satisfied
The mitigation formula shown in the panel is:
```
Control weight × Highest assurance × Presence = Control mitigation
```
Presence is 1 when the control is present and 0 when it isn't. So a missing control mitigates nothing, and a present control backed by weak evidence mitigates only part of its weight. This is where a vendor's score is won or lost: raising assurance on a heavy control moves residual risk more than adding evidence for a light one.
## Questionnaires
Supplemental questionnaires get their own sections in the **Questionnaires** group rather than appearing as a risk dimension — their controls are excluded from the risk analysis control lists. Each questionnaire section shows:
* **Completion** — how many questions were answered, as a bar and a percentage
* **All / Answered / Not answered** filters, plus search across question text
* A table of questions with the answer, any additional information provided, and the **Responder**
The Responder column shows **Vendor** when the vendor answered directly, or **VISO AI** when VISO TRUST derived the answer from submitted artifacts. Hover the VISO AI label to see the reasoning behind the derived answer. Expand any answered row to see the artifact detections behind it.
## Snapshots and Updates
Risk analysis is bound to the assessment you're viewing. Evidence added after that assessment completed doesn't appear in it — selecting an older assessment shows what was known at the time, not today's picture.
New information surfaces as **Pending Changes** on the relationship instead, including:
* **Risk model updated** — the risk model has changed since this relationship's last assessment, and current scores may shift once it runs again
* **Supplemental questionnaires were added to this relationship** — new questionnaires are attached but not yet reflected in the analysis
Pending changes are incorporated the next time an assessment update runs. See [Pending Changes](/third-parties/relationships#pending-changes).
## Exporting the Analysis
The download button on any dimension card exports that dimension's risk model output as a CSV — a row per control with its weight, validation status, detection assurance, weighted presence, and the artifact that supported it, alongside the assessment's inherent and residual scores. From **All controls**, the export covers every dimension. Any user with access to the assessment can download it.
To lower residual risk, start from the **Insufficient** filter on the dimension with the most control weight in scope. Those controls have the largest unmitigated weight, so evidence there moves the score furthest. Use a [remediation request](/third-parties/assessments) or a follow-up questionnaire to collect it.