Value Chain Risk Institute:
Continuous Vendor Risk Quantification

1. The Problem: Why Current Approaches Fail

The Questionnaire Fiction

The dominant vendor risk management approach — sending security questionnaires and collecting attestations — has a fundamental structural failure: it produces a document describing what a vendor claims, not what their systems show. There is no technical mechanism preventing a vendor from answering "yes" to every control question regardless of actual implementation. The output of a questionnaire process is the vendor's preferred narrative, timestamped.

External scanning services (Bitsight, SecurityScorecard, and similar) address the narrative problem but introduce a different failure: they observe only what is visible from outside the perimeter. An organization with a clean external footprint may have critical internal control failures completely invisible to external probes. External hygiene score ≠ internal security posture.

The Heisenberg Problem of Risk

Traditional risk quantification faces a fundamental granularity paradox: the more granular the data, the faster its truth expires. A vulnerability scan valid at the individual CVE level becomes obsolete the moment a developer commits new code. A port scan is accurate for the duration of the scan. A penetration test finding is valid for approximately five minutes past the engagement end.

VCRI refers to this as the Decay of Truth: all point-in-time security assessments begin decaying the moment they are produced. The faster the target changes — and modern agile infrastructure changes continuously — the faster the truth decays. This is why annual audits are effectively meaningless as security instruments; they are useful only as compliance artifacts.

This produces VCRI's core benchmark: 6 months → 6 seconds. Traditional risk-to-action pipelines — questionnaire distribution, vendor response, review, scoring, reporting — take approximately six months end-to-end. VCRI's continuous telemetry pipeline surfaces a risk signal in approximately six seconds. The gap is not an incremental improvement; it is a categorical architectural difference.

The Nth Party Problem

Enterprise value chains have extended far beyond direct vendor relationships. A company doing data analysis on your behalf is a third party. If that company uses a cloud-based AI service for processing, the AI provider is a fourth party. If the AI provider contracts its compute infrastructure, that is a fifth party. In practice, data processed under an enterprise contract may traverse four to six organizational boundaries before returning a result.

Current vendor risk management treats this as a third-party problem. It is not. Every layer of the chain introduces independent risk that compounds non-linearly. Visibility requirements must extend through the full chain — not just to the direct vendor relationship.

The Regulatory Inflection Point

Global regulators have reached the same conclusion simultaneously. The EU's DORA (Digital Operational Resilience Act), the U.S. CMMC and CSRMC frameworks, Saudi Arabia's SAMA, UAE's NESA, and Japan's ISMAP are all moving in the same direction: from periodic attestation toward continuous, quantified, operationalized vendor risk management. The compliance question is no longer "did you check your vendors?" — it is "can you demonstrate continuous visibility?"

Organizations that cannot answer the latter question are increasingly exposed to regulatory liability, insurance pricing pressure, and contractual risk — in addition to the underlying security exposure.

2. Architecture: The Inside-Out Data Pipeline

The Inside-Out Model

VCRI's foundational architectural decision is Inside-Out data acquisition. Rather than inferring vendor security posture from external observation (Outside-In), VCRI connects directly to the commercial security platforms vendors already operate and ingests live telemetry via authorized API access. The vendor's vulnerability management platform, SIEM, identity provider, and GRC tools are the source of truth — not a form the vendor fills out.

This distinction is not cosmetic. It changes what the data represents: instead of a vendor's representation of their posture, VCRI receives the actual output of the systems governing that posture. A vendor cannot selectively disclose through an automated pipeline in the same way they can curate a questionnaire response.

In practice, this means VCRI requests read authorization on platforms the vendor already operates — endpoint security via CrowdStrike or SentinelOne, identity posture via Microsoft Entra ID or Okta, vulnerability coverage via Tenable or Qualys, SIEM telemetry via Splunk, Microsoft Sentinel, or Google Chronicle, firmware integrity via Eclypsium, and remediation velocity via ServiceNow. No new infrastructure is required. No data is exported from the vendor's environment. The vendor authorizes VCRI as a read-only reader on tools they already use — the same permission model as adding an auditor to a tenant.

Full Pipeline

The pipeline above reflects the preferred automated API pull path. Vendors who cannot integrate immediately may use the AI-Assisted Intake path — see below — which pre-processes unstructured submissions into the same normalized schema before entering the CRIBL pipeline.

CRIBL Integration Layer

CRIBL serves as the data pipeline — responsible for ingesting vendor system data and transforming it into the normalized schema that VCRI's scoring engine consumes. The preferred ingestion model is automated API pull: CRIBL connects to the vendor's live systems and ingests telemetry continuously without vendor-side preparation.

CRIBL's confirmed transform capabilities supporting the VCRI pipeline include:

SCF Normalization Layer

The Secure Controls Framework (SCF) serves as VCRI's master control translation layer. Because vendors operate under heterogeneous compliance regimes — some under SOC 2, others under ISO 27001, NIST CSF, HIPAA, PCI-DSS, or CMMC — their raw evidence arrives in incompatible frameworks. SCF provides a unified control library that maps all major frameworks to a common schema.

This enables apples-to-apples comparison across the entire vendor population regardless of which framework any individual vendor operates under. A SOC 2 Access Control control and a NIST CSF PR.AC control both map to the same SCF control identifier and ultimately to the same CAM scoring cell.

Provenance Packs

For component-level supply chain visibility, vendors submit Provenance Packs — a bundled collection of all applicable Bills of Materials (BOMs) for a vendor's product and service portfolio. The BOM ecosystem is evolving rapidly; VCRI accepts any machine-readable BOM type vendors can provide:

• SBOM — Software Bill of Materials: software components, dependencies, versions, origins, and known-vulnerability mapping
• HBOM — Hardware Bill of Materials: component-level hardware provenance, supply chain origin
• FBOM — Firmware Bill of Materials: firmware versions, embedded components, update history
• CBOM — Cryptographic Bill of Materials: cryptographic primitives, key lengths, algorithm choices, post-quantum readiness
• Governance BOMs — compliance artifact inventories, policy registers, control evidence bundles
• Manufacturing, AI/ML, Operations BOMs — any additional BOM types applicable to the vendor's category

The individual BOM formats are maintained by their respective standards bodies (NTIA, CISA, CycloneDX, SPDX, and others). VCRI does not define the BOM standards; it ingests and processes whatever vendors provide.

Minimum requirements are category-appropriate: software-primary vendors are expected to submit at minimum an SBOM; hardware vendors an HBOM; firmware/embedded vendors an FBOM. Additional BOMs are credited in the vendor's Alpha (α) score — more complete provenance means higher accuracy confidence. As the BOM ecosystem evolves and new BOM types become standard, VCRI's category minimums will update to reflect industry expectations.

Provenance Packs are the "digital birth certificate" for a vendor's systems. They feed the Trust and Identity dimensions of the CAM scoring matrix and provide the evidentiary substrate for the Alpha (α) score.

Dashboard Output Model

VCRI's dashboard outputs a Traffic Light Protocol (TLP) signal per vendor per TIPPSS category. Critically, the dashboard exposes category-level risk signal only — specific CVEs, vulnerability details, or configuration specifics are never surfaced to the client organization. This is intentional:

• It protects the vendor's competitive and security-sensitive details
• It prevents the dashboard from becoming a roadmap for attackers
• It focuses the client on risk decisions, not vulnerability management (which remains the vendor's responsibility)

3. The CyberAssuranceMatrix (CAM) & TIPPSS

Intellectual Lineage

The CAM was co-authored by Joshua Marpet and Mitch Parker (CISO, Indiana University Health; co-Vice Chair, IEEE/UL 2933). It builds on two prior frameworks: Sounil Yu's CyberDefenseMatrix (CDM), which organizes active defense operations, and the TIPPSS framework from IEEE/UL 2933, originally developed for clinical IoT security and extended by VCRI for value chain verification.

TIPPSS: The Six Verification Dimensions

TIPPSS defines six orthogonal dimensions of security assurance derived from IEEE/UL 2933. Each dimension represents a distinct failure mode if unverified:

The CAM Matrix: 5 Assets × 6 TIPPSS Dimensions

The CAM scores vendors across a 30-cell matrix — five asset categories (Devices, Applications, Networks, Data, Users) against each TIPPSS dimension. Each cell identifies the verification approach and the technologies expected at each maturity level. The gap between a vendor's current state and required state in any cell is the risk in that dimension.

The full 150-cell reference matrix (6 TIPPSS × 5 assets × 5 CMM levels with named technologies) is documented in Methodology/Risk-Quantification/CMMI-CAM-MATRIX.md.

4. CMM Maturity Levels: Scoring Vendors 1–5

VCRI scores vendor security posture using CMM (Capability Maturity Model) levels 1–5 per TIPPSS dimension per asset type. CMM was selected for three reasons: universal recognition across DoD, government, and enterprise procurement; granularity superior to simpler scales; and direct intellectual lineage — Joshua Marpet co-authored CMMC v1, which was derived from CMM.

CMM's key contribution to VCRI's model: it describes not just what technology is present, but how consistently and predictably an organization operates it. A firewall that is present but not maintained to policy is not a CMM Level 3 control — it is Level 1 or 2 at best. The CAM maps both the technology expectations and the process characteristics for each level.

5. The Greeks: Data Quality Weighting

Every risk score in the VCRI platform is weighted by four data quality coefficients — The Greeks. They are not separate scores. They are multipliers applied to raw CAM gap scores before any Dollar-at-Risk calculation is produced. A vendor with a high raw risk score and high Alpha/Beta is a confirmed risk. A vendor with a high raw risk score but low Greeks may simply be poorly measured — the risk is real but the signal is noisy. Both are important to distinguish.

Gamma: The Systemic Concentration Score

Gamma is displayed as the Systemic Concentration Score on the Decision Science Quadrant dashboard view. It answers the question: "If this vendor has a problem, how bad is our problem?" A vendor with a moderate raw risk score but high Gamma (many critical processes depending on them) may require more urgent attention than a vendor with a higher raw risk score but low Gamma.

Gamma is computed at two levels: the individual client level (how much does this vendor affect MY value chain) and, where data permits, the ecosystem level (how many VCRI clients depend on this vendor — a true systemic risk indicator).

Portable Trust: The Vendor Incentive

Vendors who maintain strong Alpha and Beta scores gain a significant operational benefit: Portable Trust. A verified VCRI score is shareable across all of a vendor's customer relationships simultaneously. Rather than responding to separate questionnaire requests from 50 different enterprise clients, a vendor with a strong VCRI profile can direct clients to that profile as the authoritative answer.

This creates a market incentive aligned with the governance objective: vendors who allow automated API access and maintain continuous telemetry achieve the highest Alpha and Beta scores, which makes their Portable Trust profile most valuable to their customer relationships. Transparency becomes the rational economic choice, not merely a policy requirement.

6. The Atomic Unit of Risk: Functional System Pricing

The Granularity Problem

Security tooling can quantify risk at extraordinary granularity — down to the individual CVE, switch port, or line of code. The Heisenberg Problem applies here: that level of granularity renders continuous quantification impossible, because the target changes faster than it can be measured. Point-in-time CVE counts are the wrong unit for continuous risk pricing.

At the opposite extreme, organization-level risk is too coarse to drive prioritization decisions. Telling a board that "cyber risk costs us $X" annually provides no actionable signal about which vendors, systems, or controls to address first.

The Functional System

VCRI defines the Functional System as the atomic unit of risk quantification: the smallest self-contained loop that generates or protects value. What "value" means depends on the organization:

• Revenue generating — commercial entities — processes that directly produce revenue: payment processing, subscription billing, sales pipeline execution.
• Revenue protecting — commercial entities — processes that prevent revenue loss: fraud detection, authentication, backup and disaster recovery, access controls. If these fail, money already earned is lost.
• Direct mission support — public entities — systems that execute an agency's core mandate: a VA benefits processing system, an FDA drug approval pipeline, a DOD logistics platform. Failure means mandate delivery fails.
• Indirect mission support — public entities — systems that enable mandate execution without directly delivering it: identity management, internal communications, procurement systems. Failure cascades into mandate delivery.

For public entities, the "Process Value" input to VCAR is the mission-impact dollar equivalent — the dollar value of benefits processed, services delivered, or operational capacity supported per unit time. The formula is identical; the value unit reflects the organization's context.

The Functional System has three properties that make it the right unit:

• Stable: The revenue-generating purpose of a Functional System persists even as the code, infrastructure, and configuration beneath it change. This stops the Decay of Truth at the scoring level.
• Priceable: Clients assign a dollar value and downtime impact to each Functional System ("this process going down costs us $50,000 per week"). This gives every risk score a direct financial translation.
• Bridging: It is simultaneously visible to security engineers (who can point to the supporting systems) and to executives (who recognize the business process it represents).

Total Risk Exposure and Risk Distribution

Most Functional Systems carry multiple risk types simultaneously. VCRI identifies all material risks from the vendor's telemetry, computes a Dollar-at-Risk figure for each, and sums them into a Total Risk Exposure for that system. The dashboard displays each risk type's proportional contribution — visualized as a breakdown by risk category — giving prioritization signal beyond the aggregate number. A CISO can see not just that a given vendor relationship carries $500K in exposure, but that 62% of it is ransomware risk and 23% is credential compromise risk, and prioritize remediation accordingly.

Business Impact Analysis Integration

VCRI provides standard Business Impact Analysis (BIA) templates to help clients accurately quantify the dollar value of each Functional System. These templates ensure that the Process Value inputs to the risk pricing model are defensible — not rough estimates — and consistent with industry-standard methodology for downtime cost calculation.

7. Governance Model: Why the Data Can Be Trusted

The credibility of VCRI's risk signal depends entirely on the trustworthiness of the underlying data. A sophisticated prospect's first governance question is invariably: "If vendors are paying customers, what prevents them from gaming the submission?" The answer is architectural, not merely contractual.

Layer 1 — Automated Pull as the Preferred Model

VCRI's preferred ingestion model is direct API pull from vendor security systems via CRIBL. When this model is active, the vendor does not interact with the data submission process — CRIBL connects to the live systems and ingests whatever those systems report. The vendor's ability to curate their submission is structurally removed. Planned integrations span the major commercial security platforms: CrowdStrike and SentinelOne for endpoint posture; Microsoft Entra ID and Okta for identity risk; Tenable and Qualys for vulnerability coverage; Splunk, Microsoft Sentinel, and Google Chronicle for SIEM telemetry; Eclypsium for firmware and hardware supply chain integrity; and ServiceNow for patch and remediation velocity. Each integration requires only a read-scope API authorization — the vendor adds VCRI as a reader on a platform they already operate, with no data leaving their existing SaaS tenants.

For vendors who decline API access and submit packaged data instead, VCRI accepts the submission — but the vendor's Beta (β) score reflects the lower provenance quality. Packaged submissions receive a lower automation coefficient than live API-sourced data. The market signal is transparent: a vendor's Beta score communicates to every client organization how their data arrived. This creates a structural incentive: vendors who want the strongest Portable Trust profile have a direct economic reason to allow automated access. Transparency is the rational choice.

Layer 2 — Expected-State Comparison

VCRI does not simply store what vendors submit. Every submission is evaluated against an expected-state model: given the vendor's stated CMM maturity level, what should their security telemetry show? Gaps between expected and actual state surface as risk signals regardless of whether the submitted data itself is "clean." A vendor submitting spotless data that fails to account for missing controls is as detectable as one submitting data indicating known gaps.

Layer 3 — Non-Profit Governance Board

As a non-profit consortium, VCRI's operational policies — including what data is collected, how it is evaluated, and how the scoring model is calibrated — are governed by a board with no financial stake in vendor outcomes. Board members include former senior executives from Oracle and Lawrence Livermore National Laboratory, the CISO of a major healthcare system, and the architects of the underlying standards frameworks. The governance board, not the paying vendor base, controls the methodology.

8. Regulatory Alignment

VCRI's continuous vendor risk quantification model is specifically designed to satisfy the technical requirements of the emerging global regulatory landscape. The following maps the key technical requirements of each major framework to VCRI's capabilities.

9. Integration Reference

Technology Partner Stack

Standards Basis

10. Get Involved

Utilizes Secure Controls Framework (SCF) — securecompliance.org