Notifications
Clear all
Topic starter
20/08/2026 5:35 pm
TL;DR: Vulnerability exceptions management is not about eliminating every exception, but about making each one documented, owned, time-bound, and compensating-controlled, according to ArmorCode. Without that governance, exceptions become hidden risk that scales faster than remediation, and AI-assisted development only widens the gap between code velocity and security oversight.
NHIMG editorial — based on content published by ArmorCode: Vulnerability Exceptions Management, Why the Goal Isn’t Zero Exceptions
By the numbers:
- At scale, ArmorCode says its customers process over 40 billion findings across 325+ integrated tools.
Questions worth separating out
Q: What breaks when vulnerability exceptions are not governed like lifecycle objects?
A: When exceptions are not governed as lifecycle objects, they drift into hidden risk.
Q: Why do unmanaged exceptions create more risk in fast-moving engineering programmes?
A: Fast-moving engineering programmes create more exceptions because remediation windows are shorter than release cycles.
Q: What do security teams get wrong about compensating controls?
A: Teams often treat compensating controls as proof of safety once they are deployed.
Practitioner guidance
- Enforce exception lifecycle ownership Assign a named business owner, security reviewer, and expiry date to every exception, and block approval if any field is missing.
- Tie approval to compensating control evidence Require the requester to show how exposure will be reduced during the exception window, including segmentation, monitoring, or narrowed privilege.
- Automate expiration and escalation Set auto-expiration for all exceptions and route overdue items to both the business owner and security leadership.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- The exception workflow fields and approval stages used to document ownership, compensating controls, and expiry.
- How ArmorCode structures audit-ready reporting across application, infrastructure, cloud, and container findings.
- The specific risk scoring inputs used to prioritise exceptions by business context and exploitability.
- The AI-assisted development angle, including how exception governance changes when code velocity increases.
👉 Read ArmorCode's analysis of vulnerability exceptions management and governance →
Vulnerability exceptions management: where governance breaks down?
Explore further
20/08/2026 6:21 pm
Zero unmanaged exceptions is the only defensible goal. Security programmes do not fail because exceptions exist. They fail when exceptions are scattered across tickets, spreadsheets, and email threads with no enforced lifecycle. That is a governance collapse, not a tooling gap. For identity-led organisations, the same principle applies to NHI and human access exceptions: anything without ownership and expiry is unmanaged risk.
A question worth separating out:
Q: Who should own the risk when a vulnerability exception is approved?
A: The business or engineering team that requested the exception should own the accepted risk, while security owns the governance process, tracking, and enforcement. That division keeps accountability with the team that controls the roadmap and resources. Security can advise, but it cannot own a risk it cannot remediate on its own.
👉 Read our full editorial: Vulnerability exceptions management works only when zero is governed
