In the last blog, we introduced the question that is reshaping the security landscape: not ‘do you have tools?’ but ‘what evidence do you have that your controls are working?’ Today, we go deeper – into the architecture of the problem itself. 

We are going to talk about something that rarely appears in vendor presentations, because no vendor who sells detection-centric security wants to draw your attention to it. 

It is called the Evidence Gap. 

How Detection Actually Works – The Part Nobody Explains 

Every endpoint detection and response (EDR) system is, at its core, a classification system. The process starts executing. The EDR collects telemetry – behavioral data, system calls, and file operations. It extracts features from that data. It runs those features through a classifier – a combination of signatures, heuristics, and machine learning models. The classifier returns a verdict: malicious or benign. 

If the verdict is malicious, the process is blocked. An alert is generated. Your SOC team responds. 

If the verdict is benign – for whatever reason – the process executes normally on your production system. 

This is the architecture. It works extremely well against known threats. The problem is what happens when it doesn’t work. 

The False Negative Is Not a Bug – It’s a Feature of the Architecture 

Every classification system has a false negative rate. This is not a failure of engineering – it is a mathematical certainty. Alan Turing proved in 1936 that no algorithm can determine, for every possible program and input, whether that program will halt or execute maliciously. Applied to cybersecurity: perfect detection accuracy is provably impossible. 

In practice, this means every EDR – no matter how sophisticated – will periodically classify a malicious process as benign. When this happens:  

What Happens on a False Negative The process executes fully on the live system. System state is mutated – files written, registry keys modified; network connections established. No alert is generated. No log is produced. No evidence exists that the execution occurred. From your security stack’s perspective, nothing happened.

This is the Evidence Gap. It is not the gap between ‘detected’ and ‘blocked.’ It is the gap between ‘everything that is executed’ and ‘everything that produced a security record.’ 

What Your Audit Trail Actually Shows 

Your SIEM aggregates logs. Your EDR produces alerts and detections. Your GRC platform documents your policies and controls. Combined, these systems produce what most organizations call their ‘security evidence.’ 

But look closely at what that evidence tells you: 

• EDR evidence: ‘These are the threats we detected.’ It says nothing about the threats it did not detect. 

• SIEM evidence: ‘These are the events we logged.’ Events only exist in the SIEM if something generated them. False negatives produce no events. 

• GRC evidence: ‘These are the policies we documented.’ Administrative evidence that controls exist – not operational evidence that they function.

None of these – individually or combined – can answer the question: ‘What was the complete set of things that executed on our endpoints in the last 30 days, and how was each one controlled?’  

“You cannot prove that nothing harmful ran. You can only prove what you detected. That is the gap every regulator, insurer, and plaintiff’s attorney is now asking about.”

The Regulatory Frameworks Have Already Noticed 

It would be convenient if the Evidence Gap were purely a technical concern. It is not. Regulators have independently converged on the same insight and written it into frameworks: 

• NIST SP 800-137: Controls must be assessed ‘at a frequency sufficient to support risk-based security decisions’ – not based on alerts alone. Absence of alerts does not constitute assessment. 

• NIS2 Article 21: Organizations must have ‘policies and procedures to assess the effectiveness of cybersecurity risk management measures.’ A detection log that is silent on false negatives does not assess effectiveness – it documents what was caught. 

• HIPAA §164.312: Organizations must ‘implement hardware, software, and/or procedural mechanisms that record and examine activity.’ If malicious activity goes undetected, it also goes unrecorded. The audit control has failed by design. 

• DORA Article 5: The management body ‘bears the ultimate responsibility for managing ICT risk.’ Managing risk requires understanding what executed – not just what triggered an alert.

The frameworks do not require ZeroDwell or any specific technology. But they require evidence that your controls operate. Detection logs only provide evidence for the portion of execution that detection succeeded on. For everything else, the record is silence. 

The Two Types of Evidence – and Why the Difference Matters 

There are two fundamentally different types of security evidence, and confusing them is the root cause of most compliance and governance risk:  

 The distinction is not academic. In a regulatory challenge, an insurance claim, or a board inquiry, these two types of evidence have materially different weights. Observational evidence says, ‘we were watching.’ Enforcement evidence says, ‘we were controlling.’ 

What This Looks Like in Practice 

In Xcitium’s 30-day Governance Risk Evaluations conducted with enterprise clients, a consistent pattern emerges: when you measure what executed – not just what was detected – organizations discover that a meaningful percentage of unknown processes ran with full, unconstrained access to production systems. 

These were not necessarily malicious. Many were legitimate, unsigned applications. Some were PUAs. And some – in every assessment to date – were confirmed malware that EDR classified as benign. 

In one evaluation framework of the unknown processes that were executed without constraint under existing EDR, a subset was subsequently confirmed malicious by Xcitium’s Verdict Cloud. Every one of those files had been executed with full system access. No alerts have been generated. No logs had been produced. No evidence existed. 

Under Execution Governance, those same files were contained from the moment of execution. File system writes were redirected to a virtual layer. Registry changes were isolated. Network access was denied. And a documented enforcement record existed for every single one. 

The Governance Risk Evaluation: Seeing Your Own Gap 

The most effective way to understand the Evidence Gap is not theoretical – it is empirical. Xcitium’s Governance Risk Evaluation measures it in your environment, with your workloads, over 30 days. 

The output is not alert metrics. It is an execution gap analysis: what percentage of unknown processes executed without constraint under your existing stack, and what that percentage becomes when an execution governance layer is added. 

That data – from your own environment – is the answer to the question your board, your regulator, and your insurer is asking. 

Please give us a star rating based on your experience.

(0 votes, average: 0.00 out of 5, rated)