Exceptions

The Exceptions module is where your organization records every deliberate departure from its standard governance posture: a waiver from a control, a temporary deviation during a project, a compensating control taking the place of an expected one, a customized approach to a framework requirement.

Exceptions are different from gaps. A gap is something broken that needs to be fixed (see Findings). An exception is something the organization has decided should depart from the norm, with an approval chain, a stated rationale, and an expiry date. Auditors examine exceptions closely because they’re the most likely place for governance theater to hide: an unjustified, unapproved, never-reviewed exception is a serious finding.

When you would reach for this

You set up exceptions when:

• A control cannot be applied to a specific subject for a documented reason, and the organization wants to record the formal waiver.
• A team needs a temporary deviation from a standard (during a migration, a renovation, a special project) and the deviation needs an approval trail.
• An organization uses a compensating control in place of an expected one (typically because the original isn’t feasible) and wants the compensation to be tracked.
• A customized approach is taken to a framework requirement (PCI DSS’s customized approach, similar provisions in other frameworks) and the customization needs to be documented and approved.
• A risk-based acceptance is being made that doesn’t rise to the level of a formal managed risk record but still needs an audit trail.

You don’t reach for this when capturing a gap that needs to be fixed (that’s Findings) or a formal risk treatment decision (that’s Risks). Exceptions are the middle ground: deliberate departures with approval, not gaps and not strategic risks.

What lives in an exception

A single record type:

Exception carries:

• A title and a stable key you pick, plus a description.
• An exception kind (waiver, deviation, compensating-control, customized-approach, temporary-exception, risk-based-acceptance, etc.; free text).
• A subject reference identifying what the exception applies to (a control, an obligation, a policy, an asset, a process, a scope node).
• A status: proposed, approved, active, expired, superseded, revoked, archived.
• A justification: the reasoning, captured as encrypted text.
• A compensating-position: when a compensating control replaces an expected one, what the compensating control is and how it provides equivalent assurance.
• An approver (a responsibility assignment).
• A valid-from and valid-until date (expiry is the norm; perpetual exceptions are a red flag).
• A review-due date for reconfirmation.
• Optional links to evidence claims that support the exception.

Exception kinds

Common kinds the product supports as free-text labels:

A worked example: a global hotel group manages brand-standard exceptions

A global hotel group operates several brands across many properties. Each brand has detailed brand standards covering guest experience, security, food safety, accessibility, and operations. A few properties cannot meet specific standards because of historic building constraints, regional supply realities, or temporary renovations. Each non-compliance has a documented exception with an approver, a rationale, and an expiry.

The brand-standards program manager, Beatriz, sets up Exceptions like this.

Step 1: identify the standards. Each brand standard is captured as a control in the workspace. There are about 200 controls covering all brand-standard topics.

Step 2: register exceptions per property. For each property that cannot meet a particular brand standard, Beatriz creates an exception:

• Property A is a historic building with no service elevator; the brand-standard control back-of-house-service-route-separation cannot be met fully. Exception kind compensating-control: a staffing schedule and a procedural workaround is the compensating control. Approver: the regional operations VP. Valid-until: 5 years (the building has heritage protection).
• Property B is undergoing a year-long renovation. Several brand standards are temporarily deviated. Exception kind temporary-exception. Approver: brand standards director. Valid-until: estimated renovation completion plus 90 days.
• Property C’s local supply market does not stock the brand’s preferred coffee supplier. Exception kind waiver for the supplier control. Approver: F&B director. Valid-until: indefinite, with annual review.

Step 3: link to controls. Each exception is linked to the specific control(s) it modifies. From the control’s detail page, you can see every property with an exception against it, with approver and expiry.

Step 4: review cadence. Quarterly, Beatriz filters Exceptions by approaching expiry. For each, she contacts the approver to confirm the exception is still warranted or to plan for the property to return to standard. Expiries don’t lapse silently; the workflow forces a decision.

Step 5: audit story. When the brand-standards auditor visits a property, the property’s record in Novantra shows every active exception against it, with the audit-grade approval trail. The auditor reviews the exceptions, samples the compensating-control evidence, and signs off.

After a year:

• The exception register has hundreds of records spanning every brand and property.
• Expiring exceptions are surfaced ahead of time.
• The audit committee can ask “show me all unjustified exceptions” or “show me every exception expiring this quarter” and get clean answers.
• Properties returning to standard close their exceptions; properties needing extensions have the conversation, with an audit trail.

Status lifecycle

The standard walk:

What you’ll see in the product

Exceptions lives under Governance → Exceptions in the workspace.

The Exceptions list is the exception register: every exception with kind, status, approver, validity window, and subject. Filter by status, kind, approver, subject, and validity. This is the page audit reviewers spend the most time on.

Inside an exception, you see:

• The full title, kind, justification, compensating-position.
• The subject (with deep link).
• The approver and the approval timestamp.
• The validity window and the review-due date.
• Linked evidence claims supporting the exception.
• Linked controls, obligations, or other subjects affected.
• Linked findings or risks for context.
• The audit trail of any changes.

Inside the affected subject (control, obligation, asset, etc.), you see every active exception against it without having to navigate to Exceptions separately.

Every change is captured in the workspace Audit Log.

Why expiry matters

A standing exception with no review and no expiry is a governance smell. It usually means the organization stopped thinking about the underlying departure long ago.

The Exceptions module surfaces approaching expiries so they’re not silently extended. The review-due field allows long-term exceptions (with valid reasons) to be reconfirmed periodically without expiring entirely. Audit reviewers look for the pattern: how many exceptions have been renewed many times? Those are flags worth examining.

Common workflows

Requesting a new exception

1. Exceptions → New exception. Subject is the control, obligation, or other governed object being deviated from.
2. Pick the exception kind.
3. Provide a justification and (if applicable) a compensating-position.
4. Submit for approval; route to the designated approver.
5. Approver approves or rejects with a reason.
6. Once approved, the exception is active from validFrom to validUntil.

Renewing or extending an exception

1. As the exception approaches validUntil, create a replacement exception.
2. The replacement supersedes the original.
3. The approver re-approves; the audit trail captures both records.

Revoking an exception early

1. From the exception, transition to revoked with a reason.
2. The subject is back to standard immediately; the team needs to be informed.
3. The audit trail captures the revocation actor, time, and rationale.

Quarterly review

1. Filter Exceptions by review-due date approaching.
2. For each: confirm with the approver that the exception is still warranted, document the confirmation in the exception’s audit history, set a new review-due date.
3. For exceptions no longer needed: revoke them.

Looking for the API?

See Exceptions API reference for the v1 REST endpoints to list and inspect exceptions from an external system.

Related

• Findings - gaps that get fixed, not deliberately accepted.
• Risks - formal risk treatment decisions including risk acceptance.
• Controls - the most common subject of an exception.
• Obligations - exceptions can apply to obligations.
• Evidence - evidence supports exception justifications.