Drowning in Security Data While Missing Actual Risk

Editorial note: Names, company references, introductions, conversational filler, repeated statements, and sponsor-specific product discussion have been removed. The dialogue below preserves the substance and progression of the practitioner discussion. 

How teams are separating real risk from findings

Participant 1

For us, prioritization begins with the data. If a system contains regulated or highly sensitive information, it becomes a priority. Severity scores still matter, but the sensitivity of the data drives the decision. Whether that system is externally or internally exposed is another important layer.

Participant 2

We take a similar approach. We scan the environment to understand where sensitive data sits and how exposed it is. External penetration testing and internal testing both help us understand that exposure.

Participant 3

The way we articulate risk has changed. It is not enough to know where the crown jewels are. We also need to understand external exposure and how quickly a vulnerability could become relevant. Data security and vulnerability exposure are converging into the same risk conversation.

Participant 4

We classify assets that contain sensitive information so we can prioritize vulnerability remediation. Correlation helps us analyze the environment more quickly and get the right remediation work to engineering. It is improving, but it is still a work in progress.

Participant 5

One thing I am realizing is that vulnerabilities do not equal business risk. There are simply too many to remediate at the same speed. What I want to identify is what is actually exploitable, where those endpoints are, and what data they can reach. The challenge is communicating that distinction to leadership when they are looking at a very large vulnerability count.

Attack paths change prioritization

Participant 6

In a large environment, more data is not necessarily better. We ingest so much that it can become unmanageable. We are trying to answer a smaller set of questions: Which adversaries target us? Which techniques are they using? Which behaviors create business risk? Do we have the telemetry to detect them? Where are the gaps?

Participant 6

We use threat intelligence to drive hunting, then adversary simulation, red teaming, and purple teaming to test whether our controls actually work. We cannot patch everything, especially in legacy environments. The goal is to prioritize critical business assets and the threats most relevant to them.

Participant 3

There is also a cost problem. Everyone would like unlimited visibility, but logging, retention, and investigation can become expensive quickly. Security leaders have to balance the visibility they want with what the business can reasonably support.

Participant 6

That is why we have moved from asking, “What is happening everywhere?” to “What matters most?” Critical assets, known adversary behaviors, exploit likelihood, control effectiveness, and attack coverage give us a practical scope for the resources we have.

Turning cyber risk into a business case

Participant 2

Have you seen better executive response by focusing on that narrower, business-oriented view?

Participant 6

Absolutely. It tells a complete story. When we can show an attack path to a critical business asset, we will inevitably find control gaps. Closing those gaps costs money, but now we can explain what the investment mitigates and what operation it protects. That has made it easier to secure resources.

Participant 1

That is the maturity gap I struggle with. I can describe the business or data at risk, but I cannot always quantify it. I cannot reliably say that spending a certain amount protects a specific amount of business value. Without that connection, the discussion can still sound anecdotal.

Participant 6

The cyber team does not have to create those numbers alone. We demonstrate the threat and test whether the scenario is possible. Enterprise risk, business continuity, and the business owner already understand what an outage means financially and operationally. The business-impact number comes from that partnership.

Participant 3

That is essentially a business impact analysis. A strong BIA program lets you connect technical exposure to business consequences and makes risk quantification much more credible.

Making quantification credible

Participant 4

The difficult part is choosing a scenario the business will believe. If we use a catastrophic ransomware scenario, leaders may dismiss it as unlikely. If we use something too moderate, we may understate the risk. How do you connect a particular vulnerable system to a credible impact number?

Participant 6

We test the scenario. If a threat is relevant to a critical asset, adversary emulation helps determine whether the attack can actually happen. Cyber proves the path. Business continuity and the business owner determine how long the process would be disrupted and what that disruption would cost.

Participant 4

So the testing is also helping prove likelihood. Instead of saying a scenario could happen and asking the business to believe us, you are showing that the path exists.

Participant 6

Exactly. If we can reproduce the behaviors that real attackers are using against our industry, the conversation is no longer theoretical.

Participant 7

Simple calculations such as dividing annual revenue into a per-minute outage number can be misleading. Impact changes by time of day, peak season, business process, and system dependency. The harder work is associating important systems with the business processes executives care about most.

Participant 7

The framing also matters. A security control can be positioned as an investment that protects or enables revenue rather than as another unavoidable technology cost.

Participant 2

Framing it as money saved rather than money lost changes the conversation as well.

When qualitative risk still needs to feel real

Participant 8

If you cannot quantify a risk precisely, you can still make the impact tangible. Bring business owners into tabletop exercises or immersive scenarios and put them in the situation: their system is down, it was attacked, and now they have to decide what happens next.

Participant 8

There is an emotional and ownership component. When someone sees that the affected application is theirs and that the disruption affects the business, they are more likely to engage in building resilience. It is not about embarrassing anyone. It is about making the consequence real enough to create ownership.

Exposure can turn remediation into incident response

Participant 3

When meaningful exposure is present, vulnerability remediation starts to look like incident response. For a serious zero day, the normal patch-management cadence may not be enough. The response plan has to support rapid action as if the exposure itself were a cyber incident.

Participant 8

We are also beginning to change the conversation around lower-severity findings. Historically, teams had more time to address medium and low issues. The concern now is that increasingly capable automated systems may chain several lower-level weaknesses together and create a high-impact path.

Participant 8

That means we may need to educate system owners that medium and low findings cannot always be deferred simply because their individual severity looks modest. The context and the combinations matter.

Testing should produce learning, not just reports

Participant 8

After a penetration test, do not stop with the report. We build a readout into the engagement so the SOC can spend time with the testers asking how they approached the environment, what they noticed, and how they got around controls. That attacker mindset is often more valuable than simply handing the team a list of findings.

Participant 2

We use purple teaming in parallel. The red team performs the attack while the blue team looks for the corresponding telemetry and detections. That lets both sides validate the finding, the logs, and the controls at the same time.

Participant 8

Our teams respond very well to that. Instead of being told to fix another finding, they understand how the attacker thought and why the weakness mattered. It makes the exercise much more engaging and useful.

Participant 5

That is a takeaway I can use immediately. Adding that direct tester-to-defender discussion to our penetration-testing program would make the exercise more valuable than receiving the report alone.

What came out of the discussion

• The group converged on the idea that vulnerability counts are a poor proxy for business risk. Prioritization needs to combine sensitive data, asset criticality, exposure, exploitability, attack paths, and control effectiveness.
• Threat-informed testing can bridge the credibility gap between theoretical risk and executive action. Demonstrating that an attack path is achievable helps prove likelihood and gives leaders a clearer reason to fund mitigation.
• Cybersecurity teams do not need to own financial quantification by themselves. The stronger model is a partnership among security, enterprise risk, business continuity, and the business owner of the affected process or system.
• When precise dollar quantification is not available, tabletop exercises and immersive scenarios can still make risk concrete and create business ownership.
• For materially exposed or fast-moving vulnerabilities, the operating model may need to shift from routine remediation to incident-style response and containment.
• The usefulness of penetration testing increases when it includes purple-team validation and direct knowledge transfer between testers and defenders, rather than ending with a static report.
• A practical takeaway was identified during the session: one participant planned to add post-penetration-test discussions between testers and internal teams to improve understanding of attacker behavior and remediation context.

This information is a summary of a Cyber Security Tribe video roundtable. It was produced by ChatGPT-6 Sol after providing it the meeting transcript from the Cyber Security Tribe video roundtable. Dorene Rettas reviewed the output for accuracy before publication. 

The meeting transcript was uploaded without names, company references, introductions, conversational filler, repeated statements, or sponsor-specific product discussion.