Exception Management Abuse

A technology company's security governance programme included a formal exception management process , a structured workflow for requesting, reviewing, and approving exceptions to security baseline requirements. The process had been designed with appropriate rigour: exceptions required a documented business justification, a risk assessment confirming the residual risk was acceptable, a time limit with mandatory review, and an approving authority at the CISO level. During a security programme review, an analyst examined the exception register and found forty-one active exceptions, of which thirty-seven were for MFA on administrative access accounts. The business justification for all thirty-seven was a variation of 'MFA implementation on this system requires engineering work that has not been scheduled.' The time limits on the exceptions ranged from three months to twelve months, but four had been approved, expired, re-approved, and were now in their second or third annual cycle. The exception process was functioning correctly , each exception had a business justification, a risk assessment, a time limit, and CISO approval. The exceptions were not being used for genuine operational constraints. They were being used to defer engineering work that was inconvenient to schedule. The exception process had become the path of least resistance for security baseline avoidance.

What is Exception Management Abuse, Really?

Exception management is the governance mechanism for acknowledging that specific operational circumstances create genuine constraints that prevent implementation of a security baseline requirement, and for formally managing those situations with compensating controls, documented residual risk acceptance, and defined timelines for either resolving the constraint or formally accepting it as a permanent limitation. It exists to handle the real-world complexity of security implementation , legacy systems with authentication limitations, vendor-managed tools that cannot be configured to meet every baseline requirement, and operational scenarios where strict baseline enforcement would create unacceptable operational risk.

Abuse occurs when the exception process is used not to handle genuine constraints but to defer implementations that are technically feasible but organisationally inconvenient , where the real reason for the exception is competing engineering priorities, resource scarcity, or management reluctance to prioritise the implementation work, rather than a genuine technical or operational constraint. An exception for MFA on a legacy authentication system that architecturally cannot support modern authentication methods is a genuine constraint exception. An exception for MFA on a modern system where implementation requires a sprint of engineering work that has not been scheduled is a deferral exception , using the exception process to bypass a baseline requirement that is difficult to meet rather than genuinely impossible to meet.

The normalisation problem is what transforms individual exception abuse into systematic baseline erosion. When multiple teams observe that the exception process produces approved deferrals for technically feasible but inconvenient implementations, the exception becomes the expected path for requirements that are difficult to meet on schedule. Engineering teams learn that requesting an exception is faster than implementing the control. The exception register fills with deferrals. The baseline exists as a documented standard. The implementation rate reflects whichever requirements were easy to meet without exceptions. The exception process has not failed , it has been learned and exploited.

• Deferral exceptions , technically feasible implementations deferred through exception process
• Exception register filling with engineering deferrals , pattern of same justification across multiple exceptions
• Recurring exceptions , same exceptions re-approved through multiple cycles without remediation
• Baseline erosion , percentage of in-scope systems actually meeting baseline requirements declining
• Exception process normalised as alternative to implementation for inconvenient requirements

Why this matters

Exception management abuse matters for TPRM because vendor security baselines confirmed through questionnaires may have extensive exception registers that systematically carve out significant portions of the environment from baseline requirements. A vendor whose security baseline requires MFA for all administrative access and who has thirty-seven active exceptions for MFA deferrals has a baseline that applies to some administrative accounts. The questionnaire confirmation that MFA is required by policy is accurate. The operational reality of how many administrative accounts are actually MFA-protected may be significantly narrower.

The recurring exception pattern is the specific signal that exception abuse produces. An exception that was granted with a six-month time limit, renewed, granted again, and is now in its third approval cycle has effectively become a permanent exception through procedural repetition rather than formal acceptance. Each renewal was approved with the expectation that the implementation would occur in the next cycle. Two or three cycles later, the implementation has not occurred and the exception has become a de facto permanent baseline exclusion. Identifying recurring exceptions in a vendor's exception register surfaces the implementations that have been systematically deferred through the exception mechanism.

Where most teams get this wrong

The most consistent failure is accepting the exception register count and formal process quality as evidence of sound exception governance without reviewing the exception justifications and recurrence patterns. A well-governed exception process with abuse produces the same governance documentation as a well-governed exception process used appropriately , the difference is in the patterns of justification and recurrence.

• Accepting exception register documentation as sound governance without reviewing justification patterns
• Recurring exceptions not identified , same exceptions approved in multiple cycles not flagged
• Deferral justifications not distinguished from genuine constraint justifications
• Baseline coverage rate not calculated , percentage of in-scope systems meeting baseline without exceptions
• Exception remediation tracking absent , whether exceptions lead to implementation or perpetual renewal

What good looks like

Mature exception management programmes distinguish between genuine constraint exceptions and deferral exceptions in their design , requiring different justification standards and different treatment for each. Genuine constraints receive appropriate long-term management. Deferral exceptions receive escalating scrutiny and mandatory escalation at each renewal cycle.

• Justification type distinction , genuine constraint vs deferral exceptions treated differently
• Escalating approval requirements for recurring exceptions , second renewal requires senior executive approval
• Baseline coverage rate tracked , percentage of in-scope systems meeting baseline without exception
• Exception age reporting , exception committee reviewing exceptions sorted by age
• No renewal without implementation progress evidence , re-approval requires evidence that implementation is actively progressing

Tooling

GRC with Exception Workflow , ServiceNow GRC, Archer

GRC platforms with exception management workflows support escalating approval requirements for recurring exceptions and exception age reporting for governance committee review. For TPRM practitioners, asking whether the vendor's exception management platform tracks exception recurrence and escalates approval for renewals provides a specific abuse prevention question.

Security Baseline Compliance , Qualys, Tenable

Security baseline compliance tools report the percentage of in-scope systems meeting each baseline requirement , surfacing the actual coverage rate that exception registers reduce. For TPRM practitioners, asking for the baseline compliance rate for critical security requirements (MFA, encryption, patching) rather than the exception register provides the implementation coverage metric that exception register counts obscure.

Governance challenges

The governance challenge with exception management is the approval incentive. CISO-level approval creates a high-stakes decision for each exception. When the decision is between approving a deferral exception and blocking a business process waiting for implementation, the approval path produces approved deferrals. Governance that creates pressure toward implementation rather than deferral , requiring implementation roadmaps with quarterly milestone tracking as a condition of exception approval , converts the exception process from a deferral mechanism into an implementation commitment mechanism.

• Ask for baseline compliance rate, not exception register , percentage of systems meeting baseline without exception
• Ask about exception age and recurrence , how many active exceptions are in their second or third approval cycle
• Require implementation roadmaps as condition of deferral exception approval
• Review exception justification patterns , whether the same justification type recurs across multiple exceptions
• Ask what percentage of exceptions ultimately lead to implementation versus perpetual renewal

If you are a small team

Ask your highest-risk vendor two questions about their exception register. First: of your currently active exceptions, how many have been renewed at least once , meaning this is their second or later approval cycle? Second: for exceptions related to MFA, encryption, or access control specifically, what is the average age, and what percentage have a defined implementation target date with active engineering work in progress? Those two questions will distinguish a well-managed exception register from one that has become a systematic baseline bypass mechanism.

• Ask how many active exceptions are in their second or later approval cycle
• Ask for exception age and implementation target dates for critical security control exceptions
• Ask for baseline compliance rate for highest-risk requirements , not exception register count
• Ask whether implementation roadmaps are required for deferral exceptions

What to require

Ask directly:

"For your active exceptions to your security baseline , specifically MFA, encryption, or access control requirements , what is the average age of the exceptions and how many are in their second or later renewal cycle? And what percentage of the systems in scope for those requirements are meeting the requirement without an exception?"

Expect as evidence

• Exception age distribution and recurrence count
• Baseline compliance rate for critical requirements
• Implementation roadmaps for deferral exceptions
• Exception justification type breakdown , genuine constraint vs deferral

A vendor whose exception process is formally governed should be asked for the baseline compliance rate that the exceptions reduce and the recurrence count for exceptions in multiple approval cycles. The process is governed. The patterns reveal whether it is being used appropriately.

How to evidence it

• Exception justification pattern review records
• Baseline compliance rate tracking
• Recurring exception identification
• Implementation roadmap requirement for deferral exceptions

Key Takeaway

The exception process is governed. Each exception has documentation, risk assessment, CISO approval, and a time limit. Thirty-seven of forty-one active exceptions are for MFA implementations that require engineering work that has not been prioritised. Four are in their second or third approval cycle. The process is working as designed. The security baseline is being systematically avoided through it. Exception management exists to handle genuine constraints. When it is used to defer difficult implementations, the exception register grows and the baseline coverage rate shrinks. Track the baseline compliance rate, not the exception register quality. Identify recurring exceptions. Require implementation roadmaps as a condition of deferral approval. The exception is the governance mechanism for constraints. Implementation is the obligation. The process should create pressure toward the obligation, not a pathway away from it.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations