Methodology Documentation
VendorSoluce® · NIST SP 800-161 Aligned

VIRA
Vendor Inherent Risk
Assessment

The structured methodology for determining a vendor's risk level before any controls or mitigations are considered — using observable relationship characteristics only.

NIST SP 800-161 Rev 1
International applicability
Version 1.0 · 2026
ERMITS LLC · Proprietary

What VIRA is

VIRA™ — Vendor Inherent Risk Assessment — is the proprietary methodology that powers VendorSoluce® inherent risk scoring. It is the structured process for determining how much risk a vendor relationship represents to your organization, evaluated entirely from observable facts about the relationship itself.

VIRA produces a scored inherent risk tier — Critical, High, Medium, or Low — that tells your procurement and security teams what level of due diligence is required before onboarding or renewing a vendor. It is not a security assessment. It does not evaluate what the vendor has done to protect themselves. It evaluates what they represent to you.

Core principle
"Inherent risk is a property of the relationship, not the vendor. It is determined entirely from observable facts about what the vendor does, what data they touch, and what happens to your organization if they fail — not from what they claim about their own security."
VIRA answers
How much risk are we potentially taking on?
Before any questionnaire, before any certification review, before any evidence collection. This is your baseline exposure — the worst case if this vendor has no controls at all.
VIRA does not answer
How well has the vendor mitigated that risk?
That is a residual risk question — answered by reviewing certifications, questionnaire responses, evidence, and controls. VIRA always precedes residual risk assessment.

Why inherent risk must be assessed first

Most organizations send the same 200-question security questionnaire to every vendor regardless of risk level. This wastes resources on low-risk vendors and — more critically — fails to calibrate effort toward the relationships that actually matter.

VIRA solves this by establishing the risk baseline before any vendor interaction begins. A vendor cannot influence their inherent risk score by presenting certifications or pointing to controls. The score reflects structural facts: what data they process, how deeply they're integrated, how critical their service is, and what regulatory obligations attach. These facts are determined by your organization, not self-reported by the vendor.

This matters for three specific reasons when a regulator, auditor, or customer asks about your third-party risk program:

Defensibility
Auditable rationale for every decision
Every tier assignment traces to specific, observable inputs — not judgment calls. "This vendor is High because they process 50,000+ customer records, have production API access, and require a DPA under GDPR."
Proportionality
Due diligence scaled to actual exposure
Low-risk vendors get a lightweight self-attestation process. Critical vendors get full questionnaires, evidence review, and executive sign-off. Resources follow risk.
Independence
Score is not influenced by vendor claims
A vendor cannot improve their inherent risk score by presenting a SOC 2 report or an ISO 27001 certificate. Those reduce residual risk. Inherent risk reflects the nature of the relationship.
Consistency
Same methodology across every vendor
VIRA produces comparable scores across your entire portfolio — new vendors, legacy vendors, and renewals. Historical comparisons are meaningful because the methodology doesn't change.

The five domains of inherent risk

VIRA evaluates inherent risk across five domains, each scored 0–100 and combined using a weighted formula. Domains are weighted to reflect their empirical contribution to third-party breach impact, grounded in NIST SP 800-161 Rev 1 (C-SCRM) guidance.

D1
Data sensitivity
The regulatory and operational consequences of a breach, determined by which categories of data the vendor accesses or processes, how many records are involved, whether data crosses borders, and the vendor's processing role (processor vs. sub-processor).
BiometricHealth / PHIChildren's data CredentialsFinancialPII Record volumeCross-border transferProcessing role
30%
D2
Operational criticality
The business impact if this vendor's service is interrupted or compromised — ranging from mission-critical (the organization cannot operate without it) to peripheral (the organization continues normally). Factors include recovery time objective and whether alternatives exist.
Business impact tierRecovery time objective Availability of alternativesUser scope
25%
D3
Access & integration scope
The depth of technical exposure — how embedded the vendor is in your environment. Privileged access and production system access carry the heaviest weights because they represent the greatest lateral movement potential in a compromise.
Privileged / admin accessProduction system access Network accessPhysical accessIntegration depth
20%
D4
Regulatory surface
Which regulatory frameworks attach because of this vendor relationship — determining the contractual, evidentiary, and penalty consequences of a breach or non-compliance event. HIPAA, CMMC, and FedRAMP carry the greatest weights due to mandatory contractual obligations and enforcement mechanisms.
HIPAA / BAA requiredGDPR / DPA required MODPACMMCFedRAMP PCI-DSSSOXExport controls
15%
D5
Concentration & 4th-party risk
Single-source dependency and sub-processor visibility. A sole provider of a mission-critical function creates systemic risk regardless of their security posture. Unknown sub-processors represent uncharacterized exposure that cannot be assessed until mapped.
Sole provider statusSub-processor count Geographic / jurisdictional riskVendor maturity
10%

The scoring formula

Each domain is scored independently on a 0–100 scale using observable inputs. Domain scores are then combined using a weighted formula to produce a raw inherent score. Non-negotiable override conditions may elevate the final tier above the weighted result.

// VIRA scoring formula — version 1.0
raw_score= D1×0.30 +D2×0.25 +D3×0.20 +D4×0.15 +D5×0.10
final_score= max(raw_score, override_minimum) // override_minimum = 0 if no overrides apply
inherent_risk_tier = tier lookup on final_score   // Critical ≥75 · High 50–74 · Medium 25–49 · Low <25

All domain inputs are capped at 100. Within each domain, factors are individually weighted and summed, then capped. This prevents any single factor from producing an artificially extreme domain score while still reflecting the compounding effect of multiple high-risk inputs.

Partial scores are not interpolated. Each observable input produces a discrete point value — there are no fuzzy or probabilistic inputs. This keeps the methodology auditable: every point in the score traces to a specific observed characteristic.

Non-negotiable overrides

Four conditions force a minimum tier regardless of the weighted score. These exist because the domain-weighted average can mask a single catastrophic risk factor. A vendor with a 20/100 weighted score who has privileged access to your production database should never be classified as Low risk.

Overrides are evaluated after the weighted score is calculated. If the calculated tier is already at or above the override minimum, no change is made. If it is below, the score is elevated to the minimum value for the required tier.

ConditionRationaleMinimum tier
Tier 1 sensitive data processing
(Health, Biometric, Children's data)
Regulatory penalties and reputational consequences of a breach involving these categories are disproportionately severe. HIPAA, COPPA, and GDPR Art. 9 impose significantly elevated obligations. High
Privileged or admin system access Privileged access enables lateral movement, credential harvesting, and complete environment compromise. A vendor with admin credentials represents a standing threat actor if their own systems are compromised. High
Sole provider of a mission-critical function
(no documented alternative)
Single-source dependency on a mission-critical function creates systemic risk that cannot be mitigated through vendor controls alone. The organization's resilience is structurally dependent on this vendor's continuity. High
Regulated processing requiring a BAA
(HIPAA Business Associate Agreement)
HIPAA mandates a signed BAA before any PHI sharing. The legal obligation and downstream liability exposure — regardless of the vendor's security posture — requires at minimum standard due diligence. Medium

The four risk tiers

VIRA produces four output tiers. The tier determines the required due diligence level before onboarding approval — not just a label, but a prescribed process depth.

75–100
Critical
Severe structural exposure. Multiple high-weight factors converge — typically privileged access, Tier 1 data, and mission-critical function combined.
Enhanced due diligence required
50–74
High
Significant exposure from one or more domains. Often: production access + significant data volume, or sole provider of an important function.
Standard-plus due diligence
25–49
Medium
Moderate exposure. Vendor processes personal data or has system integration, but neither the data sensitivity nor the operational criticality reaches the higher threshold.
Standard due diligence
0–24
Low
Limited structural exposure. Minimal data access, peripheral operational role, no privileged access, no significant regulatory surface.
Lightweight due diligence

Required due diligence by tier

The inherent risk tier determines the minimum due diligence process required before onboarding approval. These requirements are prescribed — they are not negotiable based on vendor size, relationship history, or contract value. The tier reflects structural risk; due diligence requirements follow from the tier.

Critical
Enhanced
Full security questionnaire (150+ controls), independent evidence review, on-site or virtual technical assessment, executive sign-off, legal review of all contract terms, and annual mandatory reassessment.
Full questionnaire (150+) Evidence vault review Penetration test results SOC 2 Type II ISO 27001 certificate Legal contract review Executive approval Quarterly monitoring
High
Standard-plus
Standard security questionnaire (80+ controls), evidence review for key controls, certification verification, execution of required legal agreements (DPA, BAA where applicable), bi-annual reassessment.
Security questionnaire (80+) SOC 2 Type II or equivalent Evidence review DPA / BAA execution Insurance verification Annual reassessment
Medium
Standard
Standard security questionnaire, self-attestation acceptable for some controls, certification review, privacy notice review. Annual reassessment.
Security questionnaire Certification attestation Privacy notice review Annual reassessment
Low
Lightweight
Simplified self-attestation form covering basic security hygiene. Periodic monitoring. Annual review or upon material change to the relationship.
Self-attestation form Basic security check Annual review

The VIRA assessment process

VIRA is conducted as the first step in the VendorSoluce® vendor lifecycle — before any vendor interaction, questionnaire, or evidence collection. The process is completed by the organization's risk or procurement team, not by the vendor.

01
Vendor intake — relationship characterization
Complete the VIRA intake form covering all five domains. Inputs are based on your organization's knowledge of the proposed relationship — service scope, data access rights, integration depth, and applicable regulatory frameworks. The vendor does not participate in this step.
Output: Five domain scores
02
Weighted score calculation
Domain scores are combined using VIRA's weighted formula (D1×0.30 + D2×0.25 + D3×0.20 + D4×0.15 + D5×0.10) to produce a raw inherent score. Override conditions are then evaluated — if any apply, the score is elevated to the minimum for the required tier.
Output: Final inherent risk score (0–100)
03
Tier assignment and report generation
The final score maps to an inherent risk tier. The VIRA report is generated — documenting the score, domain breakdown, factor chips, override conditions, applicable regulations, and the prescribed due diligence requirements. This report becomes part of the vendor file.
Output: VIRA Inherent Risk Report
04
Due diligence — residual risk assessment
Based on the tier, the prescribed due diligence process begins. The vendor receives a security questionnaire calibrated to their tier. Evidence is collected, certifications are verified, and required legal agreements are executed. This produces the residual risk assessment.
Output: Residual risk assessment + evidence vault
05
Onboarding decision and ongoing monitoring
The combination of inherent risk tier and residual risk assessment drives the onboarding decision. Approved vendors enter the portfolio. VIRA scores are reassessed annually, or upon any material change to the relationship (expanded data access, new integration, service scope change).
Output: Approved vendor record in portfolio

Inherent vs. residual risk

VIRA's scope ends at the inherent risk score. Understanding what falls inside and outside that boundary is essential to using the methodology correctly.

FactorInherent risk (VIRA)Residual risk (post-VIRA)
Who determines it Your organization — from observed relationship facts Evaluated jointly — questionnaire responses, certifications, evidence
Vendor certifications Not considered — SOC 2, ISO 27001 do not affect inherent score Primary inputs — reviewed and verified during due diligence
Security questionnaire Not used — inherent risk precedes vendor interaction Required — depth calibrated to inherent risk tier
When it changes When the nature of the relationship changes — new data access, new integration, expanded scope When vendor controls improve or deteriorate — new certifications, findings, incidents
Can vendor improve it? No — inherent risk reflects the relationship, not vendor actions Yes — better controls, evidence, and certifications reduce residual risk
Audit defensibility Fully auditable — every point traces to an observable input Depends on evidence quality and documentation discipline

Standards alignment

VIRA is grounded in established third-party risk management standards. The five-domain structure and weighting rationale draw directly from the following frameworks:

Primary
NIST SP 800-161 Rev 1
C-SCRM for Systems and Organizations
Provides the foundational supply chain risk management framework — including the concept of inherent vs. residual risk, supplier criticality tiering, and the requirement to assess risk before supplier interaction. Domain 2 (operational criticality) and Domain 5 (concentration) map directly to NIST 800-161 supply chain risk categories.
Primary
NIST CSF 2.0
Cybersecurity Framework
Governs the Govern and Identify functions, including third-party risk identification and supplier risk management. VIRA's domain structure reflects the CSF's emphasis on understanding the organizational context of risk before implementing controls.
Regulatory
ISO/IEC 27036
Information Security for Supplier Relationships
Provides specific guidance on supplier risk assessment — including the principle that risk assessment precedes supplier engagement, and the requirement for documented risk criteria. VIRA's tier-to-due-diligence mapping aligns with ISO 27036-3 acquisition process requirements.
Regulatory
GDPR Article 28
Processor obligations
Requires controllers to use only processors that provide sufficient guarantees — implying a documented assessment of processor risk before engagement. Domain 4 (regulatory surface) incorporates GDPR's DPA requirement and data transfer obligations as explicit risk factors.
Ready to apply VIRA™

Start your first inherent risk assessment

The VIRA assessment takes approximately 15 minutes per vendor. Results feed directly into your vendor portfolio — no backend required.