Skip to main content
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: 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.

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: 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.
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 is the baseline exposure before any credit for controls. The resulting score is mapped to a risk label using your organization’s risk tolerance.

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.
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 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

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: 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 weightControl 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:
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.

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 or a follow-up questionnaire to collect it.