Risk Register — signal-driven, three-layer, board-facing

What changed

The Risk Register shipped this week, and it works differently than every other GRC platform’s. Where Vanta, Drata, Hyperproof, and the rest populate the register from a pre-built library or manual entry, vCISO Lite’s auto-generates customer-environment-specific scenarios from real signals across the platform. If a KRI trips, a vendor concentration goes material, a threat-intel feed matches an asset in the dependency graph, or a vendor exposure gets repriced, a proposed row lands in the register.

Three layers

Board appetite and tolerance in Layer 1, FAIR scenarios in Layer 2, and the Deficiency Register in Layer 3. Findings are not risks; they are conditions that contribute to risk, and they get their own tab.

Signal-fed

Eight services propose scenarios from live telemetry: the customer-authored existential-risk exercise at onboarding, vendor concentration (HHI), vendor incidents, the dependency graph, KRI breaches, threat intelligence, KEV-tier findings, and audit or policy exceptions.

FAIR math

Scenarios follow the FAIR form (“[Threat] impacts [asset] via [method], causing [effect]”), 20–30 per customer, with dollar exposure via LEF × LM. They aggregate into Layer 1 category exposure against the board's tolerance trigger.

Board vocabulary

Layer 1 uses the NACD/NIST five ERM categories (operational, financial, compliance, reputational, strategic), not COSO's four. Each row carries an appetite statement, a quantitative tolerance trigger, auto-computed current exposure, an in-or-out-of-appetite verdict, and trend.

Audit trail

Customers accept, decline, or adjust each proposed row. The decision and its reasoning are recorded either way, in a form an auditor or regulator can read back.

Why it matters

The architecture follows FAIR discipline (Jack Jones / FAIR Institute): risks and control gaps are different things and belong in different registers. Conflating them is what turns a risk register into what Jones calls a “due-diligence dumping ground.” The two-register discipline Jones has been pushing since 2019 is the one every shipping GRC platform still ignores.

The design was validated against the governance sources boards actually cite: NACD/ISA 2026 Director’s Handbook on Cyber-Risk Oversight (5th Edition), NIST CSF 2.0 GV.RM-02, NISTIR 8286A (the NIST integrating-cyber-risk-into-ERM framework), ISO 31000:2018, and the FAIR Institute methodology. The NACD/NIST anchoring matters: COSO ERM 2017 uses four categories; NACD/NIST use five (the ones in Layer 1). The board vocabulary here is board vocabulary.

The Risk Register is where the founder or CISO shows up to a board meeting with the top scenarios, the current exposure, and the recommendation, and where the board records its decisions in a form the auditor and the regulator can defend. “Forward risk vs backward risk: the board report that shows where you’re headed” walks through why the current state of the practice fails at exactly that job. See also the Risk Quantification cluster, the Continuous Indicators cluster, and Why your KRIs stopped predicting anything.

Availability

Shipping this week to every platform tier.

The register seeds from the existential-risk exercise at onboarding, with customer voice preserved verbatim, and begins proposing scenarios as soon as the signaling services have data to draw from. Deficiencies, scanner findings, audit findings, and policy exceptions roll into Layer 3 and stay bidirectionally linked to the Layer 2 scenarios they contribute to.

Known limitations

Auto-proposals require the signaling services to have data. A customer without vendor, resilience, or indicator data populated yet will see the register seeded only from the existential-risk exercise and manual entry.

Threat-intelligence proposals require the matched asset to be in the dependency graph. If an asset is not catalogued, the match will not surface a scenario.

This is iteration one of the three-layer design. Scenario coverage expands as more signal sources come online in a given customer environment.