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

# Control Domains & Artifact Types

> How control domains define the security categories assessed in VISO TRUST, and how artifact types like SOC 2 and ISO 27001 reports map evidence to controls.

**Control domains** are the categories of security requirements that VISO TRUST assesses vendors against. **Artifact types** are the documents and evidence that validate whether those requirements are met. Together, they form the evidence-to-controls mapping that drives every risk score.

## Control Domains

A control domain is a grouping of related security controls — for example, Access Control, Incident Response, Data Protection, or Vendor Management. The domains in scope for a given assessment are determined by the **business cases** selected for that relationship.

VISO TRUST's default framework covers these dimensions:

| Dimension                   | What it covers                                                                                                                         |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Security**                | Core information security controls — access management, encryption, vulnerability management, incident response, etc.                  |
| **Privacy**                 | Data handling, consent, sub-processor management, and compliance with privacy regulations (GDPR, CCPA, HIPAA)                          |
| **Artificial Intelligence** | Risk controls specific to vendors that develop or deploy AI — model governance, bias, transparency, and AI-specific security practices |
| **Resilience**              | Business continuity, disaster recovery, and operational stability                                                                      |
| **Product Security**        | Secure software development, dependency management, and vulnerability disclosure programs                                              |
| **Cyber Insurance**         | Coverage and limits of the vendor's cyber insurance policy                                                                             |
| **Service Locations**       | Where the vendor stores data and operates, for data residency and geopolitical exposure                                                |
| **Subservicers**            | The vendor's own downstream providers, for nth-party visibility                                                                        |

Every dimension that has controls in scope gets its own section in the relationship's [risk analysis](/risk-and-monitoring/risk-analysis), where you can see those controls and the evidence behind them. Only the Security dimension produces the inherent and residual risk scores used across the platform.

Controls introduced by your organization's own **supplemental questionnaires** are tracked separately — they appear under Questionnaires in the risk analysis rather than as a risk dimension.

You can further tailor the controls in scope through [Custom Frameworks](/third-parties/advanced/custom-frameworks). The full framework is listed in-platform under **Glossary → Control Domains**.

## How Controls Come In Scope

Controls are brought into scope by the business cases selected during relationship context configuration. Each business case maps to a set of control domains — the combination of selected business cases determines the full set of controls that must be assessed.

Example: A vendor selected with the business cases **"Stores customer data"** and **"Has privileged system access"** will have a broader set of controls in scope than a vendor selected only as a **"Provides software as a service."**

Changing a relationship's business cases immediately updates which controls are in scope. Control domains that fall out of scope are marked **Out of scope**. New in-scope controls show **No Information** until evidence is collected.

## Control Status

Each in-scope control has a status that reflects the current state of evidence:

| Status               | Meaning                                                                                                        |
| -------------------- | -------------------------------------------------------------------------------------------------------------- |
| **Present**          | The control is described as implemented — evidence confirms it's in place                                      |
| **Description Only** | Evidence describes the control but doesn't test it, so it counts as present at reduced assurance               |
| **Not Present**      | The control is described as not implemented, or the audit includes a qualified opinion or exception against it |
| **No Information**   | No evidence addresses this control yet                                                                         |
| **Not Applicable**   | Confirmed by the vendor (or your team) that this control doesn't apply to their environment                    |

**Out of scope** applies at the control domain level: the domain is enabled in your organization, but doesn't apply to this relationship based on its business context.

In the [risk analysis](/risk-and-monitoring/risk-analysis) view, these statuses are grouped into three indicators — **Present** (green), **Not present** (red), and **Not applicable** (grey) — with a ring showing how much of the control's weight the evidence actually mitigated.

Controls with no supporting evidence represent gaps — they keep the residual risk score high and are the primary targets for remediation requests and follow-up questionnaires. Controls marked **Not applicable** are handled differently: their weight is removed from likelihood rather than counted as mitigation, so they neither raise nor lower the score.

## Artifact Types and Control Mapping

Every artifact type recognized by VISO TRUST maps to a defined set of controls it can validate. When an artifact is uploaded and analyzed, Artifact Intelligence extracts evidence from the document and credits the controls it satisfies.

Each type covers a characteristic set of domains:

| Artifact Type             | Controls typically validated                                  |
| ------------------------- | ------------------------------------------------------------- |
| SOC 2 Type II             | Security, availability, confidentiality, processing integrity |
| ISO 27001                 | Information security management across all domains            |
| HITRUST CSF               | Security, privacy, compliance (especially healthcare)         |
| PCI DSS ROC/AOC           | Payment card data security controls                           |
| Penetration Test          | Vulnerability management, application security                |
| Data Processing Agreement | Privacy, sub-processor management, data handling              |
| Cyber Insurance Policy    | Cyber insurance coverage and limits                           |
| Security Policy           | Policy-level coverage across security domains                 |
| SOC 2 Type I              | Design of controls (no operating effectiveness testing)       |
| Vendor Questionnaire      | Self-attested coverage across any domain                      |

## Assurance Levels

Every artifact type carries a numeric assurance value, displayed as one of four levels on a four-dot meter:

| Level        | Assurance value | Example artifact types                                |
| ------------ | --------------- | ----------------------------------------------------- |
| **Advanced** | 0.92 and above  | ISO 27001, SOC 2 Type II, PCI DSS AOC/ROC, HITRUST r2 |
| **Standard** | 0.90 – 0.91     | SOC 1 Type II, HITRUST i1                             |
| **Moderate** | 0.80 – 0.89     | SOC 2 Type I, SOC 1 Type I, HITRUST e1                |
| **Limited**  | Below 0.80      | Vendor questionnaires, privacy policies               |

Assurance is what scales control credit: a present control backed by an Advanced artifact mitigates nearly all of its weight, while the same control backed by a questionnaire mitigates well under it. Every artifact type's own level is listed in-platform under **Glossary → Artifact Types**.

Assurance can also be **reduced** below an artifact type's normal level. The risk analysis view labels the reason:

| Reason                | What happened                                           |
| --------------------- | ------------------------------------------------------- |
| **Artifact expired**  | The artifact is past its validity period                |
| **Description only**  | The evidence describes the control without testing it   |
| **Reduced assurance** | A VISO TRUST auditor manually lowered the assurance     |
| **Audit ignored**     | The artifact doesn't count toward the risk model at all |

## The Assurance Hierarchy

When multiple artifacts of different assurance levels address the same control, VISO TRUST uses the highest-assurance artifact to determine the control's status. A validated SOC 2 report supersedes a self-attested security policy for the same control.

When a high-assurance artifact is available, it also supersedes expired lower-assurance artifacts of the same type, and older versions of the same artifact type.

## Compliance Certifications vs. Validated Artifacts

When VISO TRUST detects a publicly claimed certification (a SOC 2 badge on a vendor's website) but doesn't have the actual report, it grants **partial credit** — a lower-confidence signal that the vendor likely meets those controls.

To upgrade from partial to full credit, request the actual certification document through a collection request. Submitting and analyzing the full report replaces the partial credit with validated evidence.