Exception management is the day-to-day process of identifying, assessing, approving or accepting, remediating, and closing deviations from policies or controls, with named ownership and time bounds.
In security and compliance programs, exceptions are known gaps: a control that did not run on time, a policy rule that cannot be met yet, temporary elevated access, a vendor without a current report, or a change that bypassed the normal path. Exception management makes those gaps visible and governed instead of informal and forgotten.
In simple terms, exception management answers:
- What broke or was waived, and why?
- Who owns the risk while it remains open?
- When will it be fixed or re-reviewed, and what proof will we keep?
This page defines the operating practice. It is related to, but not the same as, CAPA or a formal corrective action plan.
Why Exception Management Matters
No control environment is perfect. People miss deadlines, tools fail, and business needs sometimes require temporary deviations. The risk is not that exceptions exist. The risk is silent exceptions: no owner, no end date, no evidence, and no escalation.
Exception management matters because:
Auditors often ask how deviations are tracked and whether they were closed.
Type 2 periods accumulate many small misses that need a consistent handling story.
Untracked exceptions become control drift and weak audit evidence.
Customers and insurers may ask how policy waivers are approved.
Clear ownership reduces finger-pointing when something stays open too long.
A healthy program treats exceptions as managed work items, not as embarrassment to hide.
Exception Management vs CAPA vs Corrective Action Plan
Use precise language so teams escalate at the right depth.
| Approach | Primary job | Typical trigger | Depth |
|---|---|---|---|
| Exception management | Govern a known deviation with ownership, risk acceptance, and time bounds | Missed review, temporary access, policy waiver, vendor doc gap | Day-to-day tracking and closure |
| Corrective action plan | Define steps to fix a specific nonconformity or finding | Audit finding, failed control test, incident follow-up | Structured remediation plan |
| CAPA | Investigate causes and put corrective plus preventive actions in place | Recurring issues, significant findings, systemic weakness | Deeper root-cause and prevention structure |
Exception management is the front door for many deviations. Some exceptions close with a simple fix. Others escalate into a corrective action plan or a full CAPA when the issue is systemic, high risk, or repeating.
Types of Exceptions
Common categories in SOC 2-oriented programs include:
- Policy exceptions: A written waiver to a policy rule for a defined scope and period (for example, a temporary allowance while a compensating control is in place).
- Control timing exceptions: A required review, training, or scan that missed its cadence.
- Access exceptions: Standing privileged access, shared accounts, or delayed deprovisioning pending remediation (often tied to access control and user access reviews).
- Vendor exceptions: A critical vendor without a current SOC report, questionnaire, or security review on file.
- Change exceptions: Emergency or break-glass changes that skipped the normal change management path and need retrospective approval and documentation.
Organizations may use other labels (waivers, deviations, variances). What matters is consistent intake, assessment, and closure evidence.
Exception Lifecycle
A practical lifecycle looks like this:
- Identify. Detect the deviation from monitoring, reviews, tickets, audits, or self-report.
- Assess. Rate impact and likelihood in plain terms: systems affected, data sensitivity, exposure window.
- Approve or accept. Route to the right approver for a time-bounded acceptance, a compensating control, or a mandate to remediate immediately.
- Remediate. Assign work, due dates, and verification steps.
- Close. Confirm the fix or that acceptance expired and was renewed consciously. Record closure evidence.
- Retain. Keep the exception record and related audit evidence for the audit period and retention policy.
Skipping assessment or approval turns "managed exception" into unmanaged risk.
Examples
| Exception type | Example situation | Example evidence to retain |
|---|---|---|
| Policy | Laptop disk encryption delayed for a lab device with compensating physical controls | Waiver form, approver, end date, compensating control notes |
| Control timing | Quarterly access review completed two weeks late | Late completion record, population export, sign-off, root note |
| Access | Break-glass cloud admin left enabled after an incident | Ticket, approver, disablement timestamp, review follow-up |
| Vendor | Payment processor SOC report expired pending renewal | Vendor risk decision, outreach log, interim questionnaire |
| Change | Hotfix deployed without prior CAB approval | Retroactive approval, change ticket, post-implement review |
Systems that often hold exception work include Jira (tickets and due dates), GitHub (emergency change history), Okta and AWS (access state), and Google Workspace (policy or sharing cleanup). Use those as context for where records live, not as product integration claims.
Evidence Auditors May Request
The following are illustrative artifacts teams often prepare. They are not a mandatory checklist for every engagement:
- Exception or waiver policy and approval matrix
- Exception log or register for the period
- Samples of open and closed exceptions with owners and dates
- Risk acceptance records for standing deviations
- Tickets showing remediation and verification
- Linkage from exceptions to related controls or findings
- Evidence that expired exceptions were closed or consciously renewed
Evidence quality improves when records show who approved what, for which systems, until when, and what changed at closure. Collection habits are covered in audit evidence collection.
Common Failures
Watch for these patterns:
- Verbal "it's fine" approvals with no written record
- Exceptions without end dates or renewal reviews
- The same exception reopened every quarter with no preventive action
- Risk acceptance by someone who does not own the business impact
- Closing tickets when work was planned, not when it was verified
- Hiding exceptions until audit fieldwork instead of tracking them in-period
- Treating every miss as a full CAPA, or never escalating recurring misses to CAPA
- No tie-back to the control that failed, which weakens control mapping
Framework Notes
SOC 2
SOC 2 examinations commonly explore how organizations detect control deviations, document them, and remediate within the audit period. For Type 2, auditors may sample exceptions related to access, change, monitoring, and vendor topics when those controls are in scope. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?. Exact expectations depend on your system description and control set.
ISO 27001 and related practice
ISO 27001 programs often address nonconformities, corrective action, and risk treatment decisions. Exception-style waivers may appear as documented risk acceptances or deviations from policy. Map your vocabulary carefully to the standard language your assessor uses.
Other programs
HIPAA, PCI DSS, and NIST-oriented programs also expect governed handling of control gaps and compensating measures where allowed. Do not assume one exception register satisfies every framework without mapping.
Cite these as common auditor and assessor expectations shaped by your scoped controls, not as a universal mandate that every company must run an identically named "exception management" module.
Continuous Compliance Bridge
Exceptions are a leading signal of control drift. Continuous compliance means you surface deviations while the period is still open, remediate with evidence, and keep the register current instead of reconstructing history before fieldwork.
That habit supports SOC 2 audit preparation and matches themes in AuditFlo's continuous compliance resource.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for exception records, remediation tickets, and related control proof.
The focus is organizing dated artifacts, preserving ownership, and reducing last-minute reconstruction across common systems such as GitHub, Jira, Okta, AWS, and Google Workspace. AuditFlo is positioned here as evidence and readiness support for the exception process your security program defines, not as an automated risk-acceptance engine that replaces management judgment.
To see the workflow for your stack, request a demo.
Key Takeaway
Exception management is how you govern control and policy deviations day to day: identify, assess, approve or accept, remediate, close, and retain evidence. It differs from CAPA and corrective action plans, which go deeper on investigation and structured remediation when issues are serious or systemic. Clear owners, time bounds, and dated records turn unavoidable exceptions into an auditable control story instead of silent risk.