1.2 - Risk intelligence as the foundation: the ten data factors

This second webinar in C-Risk’s three-part series focuses on how to build a data-driven risk management program using data you already have, by wiring existing datasets into a coherent risk data chain. The session emphasizes a core premise: most cyber risk programs may be defensible to auditors but are not useful to boards, and today’s focus is the data architecture required to make risk quantification meaningful for executive decision-making.

Key Points Discussed

- No need for new data first: Most organizations already possess relevant inputs (asset inventory, vulnerability data, threat intelligence, incident logs, audit findings, third-party assessments), but they are stored in silos and not connected into a risk model.

- 10 key data factors exist but aren’t “wired together”: The webinar introduces 10 data factors and explains where they typically live (e.g., CMDB, attack surface tools, GRC/control frameworks, vulnerability management tools, incident/ticketing systems, TPRM tools, procurement questionnaires).

- Data factors group into five conceptual categories: The webinar organizes the 10 factors into:

• business context/value and criticality,
• exposed attack surface & threat landscape,
• defensive control capability and performance,
• weaknesses/vulnerabilities & findings,
• wider ecosystem including third-party landscape and history.

- Why assessments start from scratch: The “wiring problem” is described as primarily organizational, not technical.

Key causes:

• inconsistent or incompatible units (apples vs oranges),
• organizational seams (data owned/managed in isolation),
• multiple use cases rebuilding the data chain repeatedly.

- Real-world example of impact: A case is cited where compliance data existed, yet real business risk was not modeled resulting in major operational impact (Jaguar Land Rover example), with the implication that better data wiring could have improved decisions on likelihood and magnitude.

- Architecture-first approach (3 architectural decisions):

• choose an authoritative source per data factor (including ownership as a “political” decision),
• define refresh frequency aligned to how fast each factor changes,
• ensure scalable integration (prefer APIs; manual refresh only as last resort with named owners).
• Most DDRM programs fail due to tooling choices: A key warning is that picking a tool before architecture decisions leads to tool-shaped architecture rather than the required coherent model.

> Replay is available: here

‍

1.3 - From scenarios to Board appetite: the L2 taxonomy that changes governance

On June 18th, Neil MacGowan and Marco Bresciani will host episode 3 of the series: From scenarios to Board appetite: the L2 taxonomy that changes governance.

Cyber risk often sits in a silo, reported in maturity scores and heatmaps that don't translate into the language the rest of the business uses for risk.

Cyber risk quantification produces insights decision-makers and business leaders can act on: exposure in financial terms, treatment options compared by cost and benefit, scenarios that map to risk appetite. It's already how they think about every other risk on the enterprise register.

What you’ll learn:

• How to present quantified cyber risk to executives, the board, and ERM in a form they already use
• How to map cyber scenarios to enterprise risk appetite
• How to use CRQ outputs to inform treatment and investment decisions
• How to integrate CRQ outputs into existing governance and reporting cycles

Registation: here.

‍