CROC: when detecting threats is no longer enough

Detecting attacks faster is still essential. But cybersecurity maturity now also depends on another capability: understanding which exposures really represent risk to the business, deciding where to act first, and keeping critical operations running when controls fail. That need is where the Cyber Risk Operations Center, or CROC, comes from.

This is the first article in a Futture series on Cyber Risk Operations, and it does not assume you know the concept: it explains where it comes from, what it solves, how it relates to the SOC, GRC and continuity, and where to start.

The cybersecurity paradox

Think about the security inventory of a large company today: a SIEM taking in millions of events a day, EDR or XDR on the endpoints, SOAR automating responses, vulnerability management, CSPM or CNAPP watching the cloud, attack surface management, IAM and PAM, threat intelligence, a GRC platform, a SOC running around the clock, and Red, Blue and Purple Team exercises.

And yet significant incidents keep happening. Often, the information that would have prevented the incident was there: the vulnerability had been detected, the asset was in the inventory, the alert was raised. What was missing was a process that connected those dots in time and concluded: this is what matters most right now.

Perhaps the problem is not a lack of security data. Perhaps the problem is turning that data into risk decisions.

An organisation can have thousands of open vulnerabilities, millions of events a day and hundreds of alerts rated critical, and still be unable to answer questions any board considers basic. Which of these problems represents the greatest risk to the business? Which asset actually supports a critical process? Which threat has the capability and opportunity to exploit a given exposure? Which control would reduce the most risk for the same investment? How much risk was actually reduced after the last remediation campaign? And if an attack succeeds tomorrow, can the business keep operating?

No single tool answers any of these questions. All of them require combining information that lives in different systems, teams and languages — and that combination, done continuously, is what we call Cyber Risk Operations.

The SOC is still essential — but it solves a different problem

Before going further, an important clarification: nothing in this article diminishes the role of the Security Operations Center. The SOC is the capability that detects, investigates, responds and contains. It works on events, detections, threats and incidents, under time pressure. Without it, the organisation simply does not see the attack happening.

The problem appears when the SOC is also expected to answer for enterprise risk. It was designed to answer "what is happening and how do we contain it?", not "which exposure is most likely to become a material loss?". Asking that of it usually produces two distortions: treating everything as urgent, or using technical severity as if it were risk.

An example makes the difference concrete. A CVSS 9.8 vulnerability on an isolated server, with no internet access, no sensitive data and no role in any relevant process, may represent less risk than a CVSS 7.5 vulnerability, remotely exploitable, on an internet-facing system that supports the payments process. By score, the first comes first. By risk, the second comes well ahead.

Severity is not risk. Severity describes how serious a flaw is in the abstract. Risk depends on who can exploit it, what it exposes, which controls stand between the attacker and the asset, and what happens to the business if everything goes wrong. We covered this in detail in the article on how to read a CVSS 4.0 score.

What a CROC is

A Cyber Risk Operations Center is an operating model for continuously identifying, contextualising, assessing, prioritising, treating and monitoring cyber risk. The term does not yet have a standardised definition in the market, and some organisations use variations of the name. What matters is the function: turning technical signals from different security domains into risk context, prioritisation and decisions.

The goal is not to produce another dashboard — many risk dashboards are opened once a quarter, the day before the committee. It is to build an operational risk cycle: something that runs every week, has owners, produces decisions and measures whether they reduced risk.

That cycle rests on a chain of reasoning that connects the asset to the resilience of the business:

1. Asset
2. Business context
3. Attack surface
4. Threat
5. Vulnerability and exposure
6. Control
7. Cyber risk
8. Business impact
9. Treatment
10. Residual risk
11. Resilience

Each link is worth defining, because much of the confusion about risk comes from using these terms as synonyms:

From Security Operations to Cyber Risk Operations

The change of model fits in a simple comparison. Security Operations asks: what is happening? Cyber Risk Operations keeps that question and adds others: what does this mean for the business? Do we need to act now? Which risk should we reduce first? Which decision produces the greatest risk reduction for the effort available?

In practice, this approach — which some already call Cyber RiskOps — rests on three capabilities. The first is continuous cyber risk assessment: instead of an annual assessment that is out of date the next day, risk is recalculated whenever the environment changes — a new asset, a new vulnerability, a new threat, a control that stopped working. The second is continuous cyber risk reduction: treatment stops being a project and becomes a flow, with a prioritised queue, owners and deadlines. The third is continuous risk monitoring: tracking whether residual risk is within what the organisation accepts and detecting when it is not.

The three form a closed loop. Assessment feeds reduction; reduction changes residual risk; monitoring detects the change — or its absence — and sends the result back to assessment. When the loop works, the question "how much risk did we reduce this quarter?" finally has an answer.

How the CROC cycle works

Broken down into operational steps, the cycle has ten. None of them is new on its own; what is new is running them as a connected sequence.

1. Continuous asset discovery. There is no risk management over what you do not know. Discovery goes beyond servers — applications, cloud, APIs, endpoints, identities, data and third parties — and must be continuous, because attackers look precisely for what was left out of the inventory.

2. Business criticality. Every relevant asset must be linked to the process it supports and to the consequence of its failure. This is the step that depends most on conversations with the business, and the one that most separates a risk programme from a vulnerability programme.

3. Exposure and vulnerability. Identifying flaws, insecure configurations, exposed credentials and, above all, attack paths to critical assets.

4. Threat context. Adding threat intelligence: confirmed exploitation, groups active in your sector, tactics and techniques mapped in references such as MITRE ATT&CK. This is what separates the flaw being exploited now from the one nobody exploits.

5. Risk qualification. Turning technical exposure into an understandable risk scenario: who acts, against what, by which path and with what consequence. "CVE on a web server" is a finding. "A ransomware group exploits a flaw in the customer portal and stops invoicing" is a scenario.

6. Prioritisation. Ranking scenarios by the combination of asset criticality, exposure, threat, vulnerability and impact. None of these factors alone defines priority.

7. Treatment. Deciding what to do with each risk. The classic options, found in references such as NIST SP 800-39 and ISO 31000, are to mitigate, transfer (for example through insurance or contract), avoid (stop the activity that creates the risk) or formally accept, with an owner and a review date.

8. Control validation. A control that is documented and never tested is a hypothesis, not protection.

9. Residual risk. Recalculating risk after treatment and validation, and comparing it with what is acceptable.

10. Continuous monitoring. Detecting changes — asset, vulnerability, threat, degraded control — and restarting the cycle for what changed.

Cyber Risk Index: an indicator, not a magic number

To run this cycle, risk has to be tracked over time. A common approach is a Cyber Risk Index (CRI): an indicator that consolidates different risk dimensions into a comparable view. It is not a universal formula; its implementation depends on each organisation's methodology, data and risk appetite. A useful CRI usually combines dimensions such as exposure risk, threat risk, vulnerability risk, security configuration, cloud risk, identity risk, third-party risk, asset criticality and business impact — but the weight of each is a governance decision, not a technical fact.

Nor can a CRI be the sum of CVSS scores or a count of vulnerabilities. The sum grows with the size of the environment, not with risk, and the count treats a flaw exploited on a critical system and a theoretical flaw in a test environment as equivalent. We discussed the pitfalls of building indices — averages that hide the worst asset, false precision, weights nobody can explain — in the article on cyber risk scoring.

Well built, a risk indicator lets management track what really matters: the trend of risk over time, the reduction achieved in each treatment cycle, the residual risk that remains, and where that risk stands against appetite (the level of risk the organisation is willing to take to achieve its objectives) and tolerance (the acceptable variation around that appetite, beyond which someone has to decide). On moving from a generic statement to measurable limits, see risk appetite: from statement to number.

The CROC does not replace the SOC

The relationship runs both ways. The SOC feeds the CROC with what it observes — incidents, detections, telemetry, indicators of compromise, tactics seen in the environment — and that calibrates risk: a threat that has already tried to get in is not hypothetical. The CROC gives the SOC what it rarely has: priority assets, risks above tolerance, the "crown jewels", the threats that matter most to this business and where monitoring needs to be sharper.

Imagine the SOC detects suspicious activity on a server at two in the morning. On its own, the alert has a technical severity. With the CROC's context, the first triage gains other questions. Is the asset critical? Is it internet-facing? Does the vulnerability on it have known exploitation? Does it support a critical process — and what does each hour of downtime of that process cost? Is there a compensating control between it and sensitive data? Was the associated risk already above tolerance?

Depending on the answers, the same alert goes into the next morning's queue or justifies triggering the response plan and leadership immediately. The detection was the same; what changed was the context.

CROC and GRC: from periodic compliance to continuous governance

In many organisations, GRC and technical operations live in parallel worlds. GRC maintains policies, controls, frameworks, acceptances and evidence at the pace of audits; operations deal with vulnerabilities and alerts every day. The two only meet when the audit asks for evidence and someone rebuilds the last year in a hurry.

The CROC is the natural meeting point. From GRC it receives the rules of the game: policies, controls, frameworks, appetite, tolerance and acceptance criteria. From operations it receives the real state of the environment. Connecting the two, treatment produces evidence as a by-product, risk acceptance gets a deadline and an owner, and deviation from appetite shows up when it happens, not in next quarter's report. It is the shift from periodic compliance to continuous risk governance — the subject of a future article in this series.

CROC and cyber resilience: what happens when controls fail

Reducing risk does not mean eliminating it. There will always be residual risk: the unknown vulnerability, the compromised supplier, human error, the attack beyond what was expected. That is why a mature strategy asks: what happens when controls fail?

The answer lies in cyber resilience. The most widely used reference on the subject, NIST SP 800-160 Volume 2, defines resilience as the ability to anticipate, withstand, recover from and adapt to adverse conditions, attacks or compromises. For operational purposes, it is worth making explicit, between withstanding and recovering, a stage that the NIST CSF 2.0 treats as a function in its own right: respond.

1. Anticipate
2. Withstand
3. Respond
4. Recover
5. Adapt

Anticipate is identifying scenarios, threats, dependencies and possible impacts before they materialise — exactly what the CROC cycle produces. Withstand is building the capacity to absorb an attack without interrupting essential functions: segmentation that stops propagation, redundancy, controlled degradation of services. Respond is detecting, containing and making decisions during the incident, with enough information to decide well under pressure. Recover is restoring critical services within the objectives set by the business. Adapt is turning incidents, exercises and failures into structural change — not just an archived lessons-learned report.

The CROC connects these stages to risk: prioritised scenarios feed anticipation, residual risk shows where withstanding must be stronger, business context guides the response, and every incident or exercise flows back into the cycle as data.

CROC, BIA and business continuity

There is one piece of information no technical tool delivers on its own: business impact. That is where the Business Impact Analysis (BIA), the foundation of continuity management in references such as ISO 22301 and NIST SP 800-34, becomes one of the CROC's most valuable sources.

The BIA starts from the business process and works down to the critical services that support it, the assets and their dependencies — systems, suppliers, people, data. When that chain meets cyber risk, prioritisation gains the missing dimension. Two parameters are especially useful. The RTO (Recovery Time Objective) is the maximum acceptable time to restore a process or service after a disruption. The RPO (Recovery Point Objective) is the maximum amount of data, measured in time, that can be lost.

With them, the question during an attack changes. Instead of "which server do we restore first?", the team asks "which service must come back first to avoid unacceptable impact on the business?". The first is answered by whoever knows the infrastructure; the second requires knowing that invoicing has a four-hour RTO and that the corporate website can wait two days. Outside a crisis, the same information changes prioritisation: an exposure on a service with a short RTO weighs more than the same exposure on a service that tolerates days of downtime.

The CROC as an orchestrator, not another department

Seen from above, the CROC sits in an orchestrating position. Above it is the business, which sets the risk appetite. Around it are capabilities the organisation usually already has:

The result of this orchestration is a single view of cyber risk, and the ultimate goal is business resilience.

So that the CROC does not become just another acronym, one point deserves emphasis: it does not need to be a new room or a large structure with its own headcount. In most companies, it starts as an operating and governance model that connects existing capabilities — a weekly prioritisation rhythm, shared criteria, defined risk owners and a common data foundation. The structure can grow later. The model comes first.

Risk-driven Red Team and Purple Team

A traditional offensive exercise starts from the question "what can we exploit?" and produces a list of findings, often valuable, but not always connected to what worries the organisation most.

Driven by risk, the exercise starts from another question: can we compromise the assets and processes that represent the greatest risk to the organisation? The scenarios prioritised by the CROC become Red Team objectives; the Purple Team uses those scenarios to check whether the SOC's detections work against the most relevant techniques; and the findings flow back into the cycle.

1. Risk
2. Attack simulation
3. Control validation
4. Findings
5. Remediation
6. Risk recalculation

The last step is what closes the loop: after remediation, the scenario's risk is recalculated. A test that does not change the risk assessment produced information, but not management.

Metrics that make sense to leadership

A CROC's metrics need to answer executive questions. Some, such as the risk reduction rate or the mean time to assess a risk, are not standardised in the market: each organisation must define them explicitly and keep them stable. None has a universal "good value" — what matters is the trend and the comparison with the appetite defined internally.

How to start a CROC

Nobody needs to buy dozens of tools or create a new structure all at once. The evolution happens in phases, and each delivers value on its own.

The first phase is visibility: a reliable inventory, criticality for the most important assets, a view of exposure and the first threat intelligence sources.

The second phase is context: relating assets, threats, vulnerabilities and impact. This is when the vulnerability queue starts to become a risk queue.

The third phase is risk operations proper: scenario qualification, prioritisation, treatment with deadlines and — hardest of all — risk owners in the business, who decide and answer for the decisions.

The fourth phase is continuous validation: control testing, integration with the SOC, Red and Purple Team driven by the prioritised scenarios, and monitoring of residual risk.

The fifth phase is resilience: integration with the BIA, continuity, incident response and disaster recovery, with metrics that show whether critical services hold up when an attack happens.

The phases overlap. The starting point is what already exists; the goal is to connect it.

Conclusion

The SOC remains fundamental: without detection and response, no company operates securely. But detecting and responding is only part of the equation. The next evolution of security operations lies in connecting threat, exposure, control, business impact, risk and resilience in a single line of reasoning — and doing it continuously, with owners and decisions.

Ultimately, each capability has its role. The SOC responds to the attack. GRC establishes governance. The CROC connects technical signals to risk. Cyber resilience keeps the business operating. None of them solves the problem alone; they need to work as a single system.

The future of security operations will not be measured only by how many attacks we can detect, but by how much risk we can reduce and how resilient the business remains when an attack happens.

At Futture, we advocate this integrated approach across cybersecurity, cyber risk, governance, continuous monitoring, continuity and resilience. It guides the series on Cyber Risk Operations that this article opens; the next pieces go deeper into each connection presented here:

• #1 — CROC and cyber resilience: the evolution of security operations (this article)
• #2 — SOC + CROC: how to integrate threat detection and risk management
• #3 — Cyber Risk Index: how to turn technical signals into decisions
• #4 — Risk-based vulnerability management within the CROC
• #5 — Risk-driven threat intelligence
• #6 — CROC + GRC: from periodic compliance to continuous governance
• #7 — CROC + BIA: connecting cyber risk to business impact
• #8 — CROC + cyber resilience: how to measure recovery capability
• #9 — Cyber-risk-driven Red/Purple Team
• #10 — How to implement a CROC: architecture, people, processes and technology

Frequently asked questions

What is a Cyber Risk Operations Center (CROC)?

It is an operating model for continuously identifying, contextualising, assessing, prioritising, treating and monitoring cyber risk. It turns technical signals from different security domains — vulnerabilities, threats, exposure, controls — into risk context and decisions for the business.

Does the CROC replace the SOC?

No. The SOC detects, investigates, responds to and contains attacks. The CROC uses what the SOC observes to calibrate risk and gives the SOC business context in return: which assets and threats matter most. The two work better together.

What is the difference between severity and risk?

Severity, such as a CVSS score, describes how serious a flaw is in the abstract. Risk also depends on who can exploit it, what it exposes, the controls in place and the impact on the business. A less severe flaw on a critical, exposed system can represent more risk than a critical flaw on an isolated one.

Do you need a new team or new tools to have a CROC?

Not necessarily. In most organisations, the CROC starts as an operating and governance model that connects existing capabilities — SOC, vulnerability management, GRC, continuity — with shared criteria, risk owners and a regular decision rhythm.

How does the CROC relate to cyber resilience?

The CROC reduces risk but never eliminates it. Cyber resilience deals with what happens when controls fail: the ability to anticipate, withstand, respond, recover and adapt. The CROC feeds that capability with prioritised scenarios and business context, and receives the results of incidents and exercises in return.

Conceptual references: NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems (resiliency goals: anticipate, withstand, recover, adapt); NIST Cybersecurity Framework 2.0 (Respond function); NIST SP 800-39, Managing Information Security Risk, and ISO 31000 (risk responses); NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, and ISO 22301 (BIA, RTO and RPO); MITRE ATT&CK (adversary tactics and techniques). The metrics presented are suggested indicators and are not a market standard. This article is educational and does not describe a specific product.

Official references

• NIST SP 800-160 Vol. 2 Rev. 1 — Developing Cyber-Resilient Systems
• NIST Cybersecurity Framework 2.0 (NIST CSWP 29)
• NIST SP 800-39 — Managing Information Security Risk
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
• ISO 22301:2019 — ISO
• MITRE ATT&CK