Skip to main content

Exceptions & Risk Acceptance

Not every violation can or should be fixed immediately. Exceptions (risk acceptance) allow you to record where a control is intentionally not met, under what conditions, and for how long.

When to Use Exceptions​

Exceptions are appropriate when:

  • A control conflicts with a business requirement or legacy constraint.
  • A fix is planned but cannot be implemented until a future window.
  • A control is being replaced or redesigned, and the current violation is tolerated temporarily.

Exceptions should not be used as a permanent substitute for adjusting policy scope or logic.

What an Exception Records​

An exception typically captures:

  • The finding(s) it applies to (policy and asset).
  • The reason for the exception.
  • The approver (for example, risk owner, security lead).
  • The start date and expiration date (or review date).
  • Any compensating controls in place.

These fields allow auditors and stakeholders to understand why a violation remains open and who accepted the risk.

Lifecycle and Reviews​

Exception processes usually include:

  • Request – an owner requests an exception for a specific violation or set of violations.
  • Approval – an authorized approver reviews and either approves or rejects the exception.
  • Review – periodic checks to ensure exceptions are still valid and not forgotten.
  • Expiry – exceptions expire after a defined period and must be renewed or closed.

Exceptions and their lifecycle can be modeled using Cloudaware objects, workflows, and tasks, and can be integrated with ITSM if desired.