The quarterly board report says the controls are in place. The EDR (endpoint detection and response) agent is deployed, the SIEM (the system that collects security logs and raises alerts) has its rules switched on, and the managed service is under contract. What the report rarely says is when anyone last watched one of those rules fire against real attacker behavior.
The gap is easy to miss because both facts look the same on a slide. "We have a detection for credential theft" and "we proved last month that our credential-theft detection fires" sit in the same row of the same table. Only the second one is evidence.
Closing that gap has a name. Analysts call it AEV (Adversarial Exposure Validation): running real attack behavior against your own defenses and recording what they catch. It sits inside CTEM (Continuous Threat Exposure Management), the wider framework many security programs already use to prioritize exposure.
You don't need a new program to start. Five questions, asked at your next security review, will do.
1. When did we last prove our detections fire?
A rule that exists and a rule that fires are separate facts. Rules break quietly: a log source stops sending, a field gets renamed, a threshold gets tuned for noise and never tuned back. None of that raises an alarm, because the alarm is the part that broke.
A good answer is a date and a result for each detection that matters. "We ran the behavior on the 12th and the alert fired in four minutes" is evidence. A count of deployed rules says nothing about which of them work.
HackerFlow (C7 Attack) runs real adversary procedures against your environment and ties each run to the alert it should have raised, so every test produces that date and that result.
2. What has changed in our environment since then?
This one belongs to the CTO as much as the CISO. Engineering teams ship changes every day: a new cloud account, a migrated workload, an updated agent, a log pipeline rerouted to save cost. Any of them can remove the telemetry a detection depends on.
Nobody gets paged. You find out during an incident.
A good answer ties validation to change. When the systems a detection relies on change, the detection gets tested again. Teams that manage detections as code (versioned, reviewed, and tested like software) can put that retest in the same pipeline that ships the change.
Crimson7 validates continuously, so a detection that stops firing after a change shows up as a failed test.
3. Which threat actors targeting our sector can we actually detect?
"Are we covered against ransomware?" has no testable answer. Narrow it to the groups that target your sector, and it does.
Public threat intelligence makes this practical. MITRE ATT&CK, a free public catalog of attacker techniques, documents known threat groups and the techniques each one uses (MITRE ATT&CK Groups).
A good answer is a short, named list: the handful of actors most relevant to your business, their techniques, and which of those techniques you've proven you can detect. Whatever isn't proven goes on the backlog.
C7 Attack turns that intelligence into repeatable attack runs: a new adversary technique becomes a validated detection and an active hunt within 72 hours. 7Hunter (C7 Hunt) answers the next question, whether one of those actors is already inside.
4. When a test finds a gap, who fixes it, and how long does it take?
A finding with no owner is worse than no finding. Now there's a documented weakness sitting in a shared drive.
The fix usually crosses teams. Security knows what's missing, the platform team owns the log source, and the SOC owns the rule. Without a named owner and a target date, the finding waits for the next test to rediscover it.
A good answer has an owner per finding, a time-to-fix you measure, and a retest that closes it. Regulators expect the same loop. DORA, the EU's digital operational resilience regulation for financial entities, requires procedures to prioritize and remedy the issues testing reveals, and validation that they're fully addressed (Regulation (EU) 2022/2554, Article 24).
Crimson7 delivers the fix as detection-as-code: a working, tested rule your team can deploy.
5. What evidence can we show the board?
Regulators already ask for proof. DORA requires financial entities to test the ICT systems supporting critical or important functions at least yearly (Article 24(6)). NIS2 requires essential and important entities to have policies and procedures to assess whether their cybersecurity risk-management measures are effective (Directive (EU) 2022/2555, Article 21(2)(f)).
A good answer is a record anyone can trace: what was tested, when, what fired, what didn't, and what was fixed. If an auditor picks one detection at random, your team should be able to show its last three test results.
Crimson7's validation output is documented, repeatable, and aligned with DORA and NIS2.
From finding to fix
A finding only helps once someone fixes it. Crimson7 validates continuously and delivers the fix, from a validated finding to a working detection.
Start with question 1. Pick the three detections your team considers most important, and ask for the date each one last fired in a test. If nobody knows, that's your first finding.
To see how C7 Attack and C7 Hunt answer these five questions, book a demo.