Notifications
Clear all
Topic starter
02/08/2026 11:53 am
TL;DR: Security teams often run 30+ controls, yet default configurations only cover roughly 70% of known threats, leaving a proof gap between expected protection and demonstrated resilience, according to Cymulate. The practical shift is from static coverage and dashboards to continuous validation, remediation, and re-testing against real attacker techniques.
NHIMG editorial — based on content published by Cymulate: Security Spent a Decade Finding More. It Should Have Been Proving More
By the numbers:
- The average enterprise runs 30+ security controls.
- Default configurations protect against roughly 70% of known threats.
Questions worth separating out
Q: How should security teams prove that GRC controls are actually working?
A: They should tie every control to a specific evidence source such as access reviews, approval records, privileged activity, or change logs.
Q: Why do coverage reports often fail to reflect actual security risk?
A: Coverage reports show that a control exists, not that it blocks the techniques an attacker would use.
Q: What breaks when teams rely on periodic assessments alone?
A: Periodic assessments go stale as soon as identities, services, or attack paths change.
Practitioner guidance
- Define a control-proof loop Map one high-value threat scenario to the exact controls that should stop it, then validate, remediate, and re-test until the result is repeatable.
- Prioritise techniques over inventories Choose attack techniques that matter to your environment, then test whether IAM, PAM, NHI, EDR, or email controls actually block them.
- Instrument identity controls for proof Add recurring validation to access reviews, privileged access paths, and NHI secret handling so you can see whether enforcement still holds after change.
What's in the full article
Cymulate's full article covers the operational detail this post intentionally leaves for the source:
- How to structure a validate, improve, prove loop across prevention, detection, and compensating controls
- Examples of threat-led testing starting points for recent campaigns, control investments, and unpatched exposures
- The operational logic behind using evidence trails for leadership and auditor reporting
- How to translate findings into control tuning without expanding tool sprawl
👉 Read Cymulate's analysis of how security teams can prove controls work →
Security control proof gaps: what practitioners need to act on?
Explore further
02/08/2026 1:01 pm
Proof, not coverage, is the new operating requirement. Security programmes that optimise for finding more issues but cannot prove control performance are measuring activity, not resilience. The article correctly separates visibility from effectiveness, which is the distinction many teams still miss. For identity security, the same problem appears when access reviews, secret inventories, and entitlement reports are treated as assurance even though they do not prove blocking power. Practitioners should treat proof as a control objective, not a reporting feature.
A question worth separating out:
Q: Who is accountable for proving security controls are effective?
A: Accountability should sit with the control owner, the programme owner, and the leadership team that accepts residual risk. In practice, this means resilience evidence should be part of governance reporting, not left as an informal technical exercise. If a control cannot be proved, its risk should be visible at decision-making level.
👉 Read our full editorial: Security teams must prove controls work, not just find more gaps
