Notifications
Clear all
Topic starter
01/08/2026 8:56 pm
TL;DR: Security teams often close tickets after patching or rescanning, but a survey of 750 practitioners found only 30% patch and then test whether risk was actually remediated, while 22% said verification of fixes is their biggest challenge, according to Horizons.ai. The real control gap is proof of outcome, not proof of work.
NHIMG editorial — based on content published by Horizons.ai: Verification Closes the Loop
By the numbers:
- The article cites a survey of 750 security leaders and practitioners.
Questions worth separating out
Q: What breaks when security teams rely on patching without verification?
A: Teams can close tickets and still leave the attacker’s objective achievable.
Q: Why do remediation metrics often overstate security improvement?
A: Metrics such as mean time to remediate and ticket closure show that work happened, not that risk disappeared.
Q: How can security teams tell whether a fix actually reduced exposure?
A: They should test whether the original attack outcome can still be reproduced after remediation.
Practitioner guidance
- Retest every remediated weakness against the original attack path Replay the same-scope scenario after patching so you can confirm the attacker’s objective is no longer achievable, not just that the finding disappeared from the scanner.
- Replace ticket closure with outcome-based success criteria Define completion as the inability to reproduce domain compromise, credential compromise, host compromise, or data exposure from the original weakness set.
- Extend verification into identity and privilege paths Check whether standing privileges, delegated access, service accounts, or exposed credentials still allow the same impact even after the technical fix is applied.
What's in the full article
Horizons.ai's full blog covers the operational detail this post intentionally leaves for the source:
- The retesting workflow used to prove that the original attack path no longer worked after remediation.
- The survey breakdown behind the 30% patch-and-test figure and the 22% verification challenge finding.
- The before-and-after pentest evidence showing how impacts fell from 251 to zero.
- The operational context for why verification must become part of continuous security assurance.
👉 Read Horizons.ai's analysis of why verification closes the loop on remediation →
Remediation is not risk reduction: how do teams prove exposure is gone?
Explore further
01/08/2026 9:04 pm
Verification is now the missing control between remediation and risk reduction. Security programmes that stop at patch completion are measuring work, not security outcome. The article’s core point is that a scanner clean state can coexist with attacker success if the exploit path, privilege path, or downstream impact condition was never disproved. For identity teams, that means verification must extend to credentials, entitlements, and access paths, not just software versions. The practical conclusion is straightforward: if you cannot demonstrate that the attack outcome is impossible, you have not finished remediation.
A question worth separating out:
Q: Who is accountable when exposure remains open after a vulnerability is disclosed?
A: Accountability should sit with the asset or service owner, but only if ownership records are current and tied to privileged access paths. In practice, that means IAM, infrastructure and security teams need a shared operating model for assigning remediation, approving exceptions and proving closure. Otherwise, gaps linger because no one can act decisively.
👉 Read our full editorial: Verification closes the loop on vulnerability remediation
