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.
The business cases selected during relationship configuration drive scope. Narrowing the business cases takes domains out of scope and lowers likelihood. The bar underneath is clickable: clicking 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
Each control domain and control row shows chips for anything a reader scans for. Any Exception or Expired artifact issue comes first, followed by Subservicers, Sub-processor, Shared Responsibility, or CUEC for the detection types present. The first two chips sit inline next to the row title, and anything beyond that collapses into a +N chip that opens the rest on hover. Applying a detection type or issue filter auto-expands the matching domains and their controls, and each control shows only the detections carrying a selected type. Controls whose detections all filter out drop off the list, as do controls without a selected issue. The Show irrelevant detections section opens with the filter, since a match can land there. Clearing a filter returns the hidden controls and detections but leaves anything you’ve already opened in place. Expand a domain to see its individual controls. To open every listed domain at once, click Expand all next to the filters. Once every domain is open, the button reads Collapse all and closes them. 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. The Sub-Processor List control works differently from other controls. Instead of detection passages, it shows the vendor’s collected sub-processor list as a table: each company, its purpose, and its location of processing. The underlying artifact detections sit behind View sub-processor detections. A collected sub-processor list carries full assurance, so this control shows as fully mitigated once the vendor provides its list. See Sub-Processor Collection. Under each control are the detections: the specific passages in specific artifacts that substantiate it. Each detection card is titled with the audit report type of the artifact behind it and carries a category badge such as Third party audit, Compliance attestation, or Self assessment. Detections in the Compliance attestation category show a tooltip on the badge explaining that the control is likely present based on evidence of compliance certification. That category covers presumed artifacts and cert-only artifacts like an ISO 27001 certificate. Detections from a presumed artifact are titled with the audit report type followed by Attestation (for example, SOC 2 Type 2 Attestation). They show no quoted passage, because there is no document behind them. Their assurance is discounted and labeled Presumed certification, so a presumed certification shows a lower level than the real report of the same type. Detections are ordered by assurance, highest first, so the detection the risk model scored sits at the top. The ordering uses each artifact’s effective assurance after any reduction for the presumed discount, expiry, or manual adjustment. So a live standard-assurance report ranks above an expired advanced one, and a real report ranks above the presumed version of the same certification. The same ordering applies to the detections behind questionnaire answers. 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 risk breakdown

Expand a control and click the Risk breakdown button 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:
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 is labeled with its response mode: AI response when VISO AI answers the questions from the vendor’s artifacts, or Vendor response required when the vendor answers directly. Each 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 and an icon showing who answered: VISO AI, a named person, or an error marker when the AI couldn’t answer from the available information
Hover an AI answer to see the reasoning behind it. Expand any answered row to see the artifact detections behind it: the passages the answer cited, ordered the same way as detections elsewhere in risk analysis. A question with no answer shows a dash in the answer column, and its row doesn’t expand.

​
AI answering states

A questionnaire section that isn’t fully answered yet shows why:
  • Awaiting the vendor’s response — the questionnaire requires a vendor response that hasn’t arrived
  • Answers will be generated once artifact processing is complete — the assessment or its artifacts are still processing
  • VISO AI is answering these questions — a run is in flight; the section header and its sidebar entry show a spinner, and unanswered rows show a placeholder until their answer lands
While a run is in flight, a Stop button on the processing banner cancels it so it can be started again. A questionnaire the AI hasn’t started answering shows a Pending change prompt instead of a status message.

​
Answering through an assessment update

Questionnaires added after the assessment completed aren’t answered automatically. Their section shows a Pending change prompt explaining that an assessment update will generate the answers with Artifact Intelligence. Click Update assessment in the prompt to start one. VISO AI answers the questionnaire as part of the update, and answers arrive in the table in real time as they’re generated. An assessment update is the only way to request answers, so the assessment summary always describes the same analysis as the answers beneath it. Re-answering works the same way: running an update re-answers AI questionnaires from the vendor’s latest artifacts, replacing the previous evidence. Users who can’t update the assessment, such as support and read-only users, see the prompt without the button. If the relationship is missing its context, the button is disabled with a tooltip asking you to add context first. AI answers also write evidence into the questionnaire’s control domains: a Yes answer validates the domain against the artifacts it cited, a No answer records it as not present, and an unanswerable question leaves it unvalidated. This evidence is for display only: supplemental questionnaire answers don’t move the risk score.

​
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. Each row is a 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.