CRQ: Proof of Concept to Operating System

The real work begins now.

For years, the central challenge of cyber risk quantification was legitimacy. Every presentation opened with the same slide: what CRQ is, why it matters, why the organization should care. Practitioners spent as much energy defending the method as applying it. That era is not entirely over, but the next one has already begun.

Today, CRQ has crossed the threshold of familiarity. Boards ask about their financial exposure to cyber events, CFOs expect cyber risk to be expressed in their own terms, and the CISOs who built their first quantification model three or four years ago now have something rare in this field: enough hindsight to judge what worked, and enough perspective to decide what comes next.

A few years ago, the debate turned on whether CRQ was real, whether it deserved the effort, and whether peers were using it at all. For teams already running a program, those questions are settled. What they ask now is how to make quantification faster and how to embed it in the processes where decisions are actually made. When an organization already equipped with a security rating tool comes to Citalid, it rarely doubts quantification itself; more often, the score it has never made it into procurement, underwriting or the budget cycle.

“For a long time, cyber risk was seen as a topic of concern only to the IT and cybersecurity departments. Yet it cuts across every activity in the organization. With Citalid, we were able to raise awareness among business teams and align cyber risk with the company’s other strategic priorities.”

Jean-Paul Joanany, Head of Information Systems Security and Business Continuity, Action Logement Services

That shift changes what adoption requires. The early adopters who spent years justifying the concept now face a different set of problems: integration, operationalization and scale. CRQ drew attention quickly because it broke with the way risk had always been assessed, and that novelty carried it for a while. It no longer does. Legitimacy is not yet fully won across the market, but current users have entered a phase that depends less on enthusiasm and more on making the method hold up in daily use, which is harder and considerably more interesting.

From Insight to Infrastructure

The first generation of CRQ programs was built around a single deliverable: the number. How much could a ransomware attack cost? What is our annualized loss exposure? In boardrooms used to heat maps, those figures were a genuine change.

A number, however precise, is not a system, and organizations that have run CRQ for several years are starting to feel the limits of periodic analysis. Their path tends to follow the same sequence. They first prove that financial quantification is possible and credible. They then anchor it to real decisions such as budget cycles, insurance renewals and board reporting. Eventually they realize that an analysis refreshed manually once or twice a year cannot keep pace with a threat landscape that changes every week. At that stage, they are looking less for a more accurate result than for sturdier infrastructure: workflows that carry the output where it is needed, and models stable enough to be trusted each time they update.

The maturity test: can your CRQ output update automatically when your threat landscape changes? Can it feed your GRC platform? Can a procurement manager access a cyber risk score for a new supplier without pulling in the security team every time? If the answer is no, you have insight, not infrastructure.

Five Structural Shifts Reshaping CRQ

Better models and richer datasets will matter, but they will not define the next phase on their own. What will define it is how quantification integrates into the way the organization operates. Five shifts are already underway.

1. The API economy of risk

Risk quantification has historically lived in spreadsheets, reports and slide decks. The next generation connects CRQ engines directly to the tools organizations already use: GRC platforms, procurement systems, ERP software, SIEM dashboards. This changes who can access risk intelligence and when. A cyber risk score available through an API can appear inside a supplier onboarding workflow, a credit decision or an M&A due diligence checklist, without an analyst having to run and export a report.

Integration also works in the other direction. CRQ once meant collecting data by hand and fitting it into a model. Connected tools can now gather much of that input automatically, so teams can spend their time on results rather than on inputs. CRQ then stops being a product used by the risk team and becomes a capability embedded in the organization’s processes. The number travels further, and that is also where the risk lies: unreliable data circulating quickly across many systems does more damage than unreliable data sitting in a report. Any API strategy therefore depends on the quality of the model behind it.

2. AI as a friction remover

There is a great deal of noise around AI and risk quantification. Its real contribution is narrower: removing the friction that has always made CRQ feel heavy. Running a scenario used to require long preparation, from gathering evidence to calibrating assumptions in spreadsheets. Platforms that have integrated AI now handle much of that input work. Citalid’s AI for Defense Profile, for example, reads existing security documents and produces an assessment against the framework the organization has selected.

Modeling itself has always been the sharpest source of friction. Translating a threat scenario into calibrated frequency and magnitude assumptions is where practitioners lose the most time, and where less experienced users give up. When AI is built into that step rather than added as a separate tool, modeling stops being reserved for experts and becomes something a wider group of practitioners can run and trust.

This matters because the main obstacle to adoption was rarely skepticism about the method. It was the effort needed to get a result, and the difficulty of seeing how that result had been built. When an analysis takes a week, CRQ stays confined to the annual review. When it takes a day, it can inform decisions as they arise.

Judgment remains with the practitioner: choosing the scenarios that matter, validating assumptions, and defending a figure in front of a board that will push back.

3. UX as a risk governance issue

An observation that rarely appears in CRQ literature is that the usability of a risk platform is itself a governance question. When outputs are hard to access, interpret or update, they get used less, and decisions are made without them. The analysis sits in a database while the decision is made on instinct, because nobody had time to pull the report before the meeting.

Organizations running CRQ at scale treat the way results are consumed as part of the method. By UX, they mean the language and format in which each reader receives the output. A board member reading a short brief, a CFO feeding a figure into a capital allocation model and a CISO testing scenario assumptions all draw on the same model, but they make very different use of it. A single screen designed for all three serves none of them well. The right result has to reach each reader at the right moment, in a form that reader can act on.

A CRQ model that nobody looks at is worth exactly as much as no model at all.

“Before Citalid, we couldn’t answer the Executive Board’s question: what would a ransomware attack targeting our group cost? Today, we have a structured estimate by risk scenario, updated regularly, and presented directly to governance bodies.”

Mehdi Ben Thabet, Project Manager Cybersecurity, BPCE

The constraint is now shifting. A fixed interface, however well designed, remains one format built for an average user. AI makes it realistic to generate the right output on demand for each decision: a structured export for one reader, a narrative brief for another, a live dashboard for a third. That flexibility brings a new requirement. When the same number can reach the board as a slide, a partner system as an API payload and procurement as a supplier scorecard, governance has to guarantee that all three still say the same thing. Interface design remains a governance question, and it becomes an auditability question as well.

4. From single asset to ecosystem risk

One of the most consequential evolutions in CRQ is the extension of its scope beyond the organization’s own perimeter. Supply chain attacks have made this unavoidable. A company’s cyber exposure cannot be separated from that of its suppliers, subsidiaries, partners and critical service providers, which together form what is sometimes called the extended organization.

Advanced programs are beginning to quantify third party risk as part of the organization’s own risk posture rather than in a separate module. A ransomware scenario that ignores a concentrated dependency on a few critical SaaS providers is incomplete. A credit assessment that does not account for a borrower’s supplier concentration is missing a material variable.

This has direct implications for TPRM, M&A due diligence, cyber insurance portfolio management and regulatory compliance under DORA, NIS2 and, in France, the Military Programming Law (Loi de programmation militaire, or LPM), which imposes cybersecurity obligations on operators of vital importance. Ecosystem risk is already a present gap, and the most advanced organizations are actively closing it.

5. A fresh start for compliance and CRQ

Most major cyber regulations contain a trap, and many organizations fall straight into it. DORA, NIS2 and the LPM do something genuinely useful: they set a minimum standard of cyber hygiene that can be audited, enforced and compared across organizations. The problem starts when compliance becomes the goal, because it then becomes the ceiling. Teams optimize for the audit instead of the risk, and documentation ends up standing in for judgment. When an attack hits, a well kept procedure protects no one.

The organizations using CRQ most effectively have redrawn that boundary. They treat regulation as the floor, the minimum acceptable posture. They use quantification as the instrument that tells them how far above that floor they need to be, given their threat landscape, their sector, their dependencies and their risk appetite. This is a more rigorous reading of regulation, in which quantification strengthens compliance.

In practice, these organizations run a single workflow. Quantification outputs feed regulatory reporting as a byproduct of real risk management, instead of a separate exercise layered on top. The result is less duplicated work, better documentation and a risk posture that holds up when it is tested.

“Quantification enabled us to prove that our cyber strategy was proportionate, effective, and grounded in the actual threat landscape.”

CISO, Private Equity firm

CRQ as a Transformation Catalyst

One dimension of CRQ adoption rarely appears in technical writing, because it is not primarily technical: the organizational change that mature programs produce. When financial quantification is embedded in decision making, it changes how functions work together. Finance and security start using the same terms, procurement and risk management share data, and the executive committee gains an instrument to monitor cyber exposure as a financial position rather than through a status report.

Organizations that have invested in CRQ for several years tend to describe the same outcome. The most valuable result was not the model output but the conversations the model made necessary: between the CISO and the CFO, between the risk team and the board, between the security architect and the business owner of a critical process.

Quantification works less as a measurement tool than as a change of language. Organizations that take it seriously end up having better conversations about risk, not because the numbers are perfect, but because they provide a shared frame of reference that did not exist before.

The Audit Trail Problem

As CRQ matures, a new operational requirement is emerging: auditability. Organizations that use quantification to inform material decisions, whether capital allocation, insurance coverage or regulatory reporting, need to be able to reconstruct at any time why a given estimate was reached. That means keeping a log of analytical decisions, versioning scenario assumptions, and recording who challenged what and when. In short, it means applying to the CRQ process the rigor expected of financial accounting.

Internal audit functions are starting to include CRQ processes in their scope, and regulators are starting to ask how organizations derive their cyber risk estimates. The documentation discipline that some teams treated as overhead is becoming a differentiator and, in some jurisdictions, a requirement.

What Comes Next: A Practical Agenda

The next steps differ with each organization’s maturity, but a few priorities apply broadly.

• Integrate before you expand. Before adding use cases, make sure existing CRQ outputs are embedded in decision workflows rather than produced and filed.
• Design for decision makers, not analysts. The primary audience for CRQ outputs is the CFO, the board member, the procurement officer and the supplier relationship manager, not the CRQ analyst.
• Invest in the API layer. CRQ gains value with every adjacent system it connects to, so integration belongs in the requirements from the start.
• Extend scope deliberately. Third party risk, credit risk and due diligence are extensions of the same model, so build toward ecosystem coverage step by step.
• Close the loop between regulation and quantification. Use compliance requirements as inputs to your CRQ scenarios, and CRQ outputs as evidence in your compliance documentation.

The organizations that lead cyber risk management over the next decade will not necessarily have the most sophisticated models. They will be the ones that made quantification a reflex: part of every material decision, accessible to every relevant stakeholder, and connected to every process that touches cyber risk.

The hardest part of CRQ was never the mathematics. It was, and remains, the organizational change. What has moved is the question on the table: few teams still debate whether to start, and many are now working out how to go further. That is a harder problem, and a far more useful one to have.