Appearance
Policy Exceptions & Governed Deviations
Where to find it: Policy Governance, select any policy, then Exceptions tab (/governance/exceptions).
A Policy Exception (EXC-YYYY-NNNN) is an authorized, time-bound, and strictly governed temporary deviation from a corporate policy statement or regulatory requirement.
Requires the compliance_core entitlement.
A policy exception is NOT compliance
An approved policy exception is not compliance, not the removal of a requirement, and not a permanent policy amendment.
An active exception explicitly records:
"This policy requirement remains applicable and binding upon the organization, but a governed temporary deviation has been accepted for an approved duration under defined compensating safeguards."
What a Policy Exception Must NEVER Do
OrviQ enforces strict systemic boundaries around policy exceptions:
- It NEVER modifies the source policy: An exception cannot alter the underlying
PolicyStatementor draft new wording in aPolicyVersion. - It NEVER closes a policy gap: An active exception links to a
PolicyGap, but does not close it. The gap remains visible as an unresolved risk until permanent compliance is achieved. - It NEVER marks a control effective: An exception acknowledges that a control cannot currently be satisfied; it never marks the control as passing or effective.
- It NEVER satisfies a requirement: Auditors see the deviation plainly in the assurance ledger; the requirement remains unsatisfied.
Status Model: Raw Persisted vs. Derived Labels
To balance database consistency with real-time operational urgency, OrviQ maintains a clear distinction between raw persisted statuses and derived runtime labels:
1. Raw Persisted Statuses (Database)
| Raw Status | Meaning |
|---|---|
draft | Exception request being drafted by the applicant |
requested | Formally submitted by applicant; awaiting compliance review |
in_review | Compliance and risk teams actively evaluating compensating controls |
approved | Granted by designated executive authority; awaiting start date |
active | Currently active and within its approved validity window |
rejected | Denied by compliance or executive authority with documented reason |
cancelled | Withdrawn by applicant prior to approval |
closed | Expired, voluntarily surrendered, or superseded by full remediation |
2. Derived Lifecycle Labels (User Interface)
The platform evaluates the calendar date, expiration thresholds, and review milestones in real time to present dynamic operational labels:
| Derived UI Label | Evaluation Criteria |
|---|---|
DRAFT | Status is draft |
SUBMITTED | Status is requested |
UNDER_REVIEW | Status is in_review |
APPROVED | Approved but start date is in the future |
ACTIVE | Currently valid and active |
DUE_FOR_REVIEW | Active, but periodic review date has elapsed |
EXPIRING | Within 14 days of expiration date; triggers renewal alert |
EXPIRED | Expiration date has passed without formal renewal or closure |
CLOSED | Formally retired and closed |
REJECTED | Request denied |
CANCELLED | Request cancelled |
Exception Types & Compensating Controls
When submitting an exception request, the applicant must categorize the deviation and supply compensatory measures:
| Exception Type | Common Use Case |
|---|---|
temporary_deviation | Operational delays in deploying approved technology |
phased_implementation | Enterprise-wide rollouts spanning multiple quarters |
compensating_control | Technical limitation mitigated by secondary detective controls |
risk_accepted_temporary | Business decision to temporarily accept residual exposure |
legacy_constraint | Legacy core banking platforms unable to support modern ciphers |
other | Exceptional circumstances requiring Chief Risk Officer sign-off |
Compensating Control Evaluation
Every policy exception requires at least one Compensating Control (CTL-...):
- Compensating controls are evaluated independently by Line 2 Risk.
- If a legacy system cannot enforce Multi-Factor Authentication (MFA), compensating controls might include isolated network segmentation, continuous session recording, and daily log review.
- If compensating controls fail during the exception window, the exception is subject to immediate revocation.
Expiry, Renewal, and Maker-Checker Approval
- Time-Bound Validity: Exceptions cannot be granted in perpetuity. Maximum validity is strictly governed (typically 90 to 365 days depending on risk severity).
- Expiring Alerts: At 14 days before expiry (
EXPIRING), automated alerts notify the owner to submit a renewal request or complete permanent remediation. - Maker-Checker Segregation of Duties: An exception applicant (
requested_by) cannot approve their own exception (approved_by != requested_by). Approval requires executive authority (tenant_adminorcompliance_manager).
Permissions Reference
| Action | Permission Key | Required Role(s) |
|---|---|---|
| View exceptions and compensating controls | exception.read | All roles |
| Request a new policy exception | exception.create | Tenant Admin, Compliance Manager, Compliance Officer, Risk Manager, Control Owner |
| Update, edit, or withdraw draft exceptions | exception.manage | Tenant Admin, Compliance Manager, Compliance Officer |
| Review exception and evaluate compensating controls | exception.review | Tenant Admin, Compliance Manager, Risk Manager |
| Grant or reject formal exception approval (Maker-Checker) | exception.approve | Tenant Admin, Compliance Manager (never applicant) |
| Formally close or retire an exception | exception.close | Tenant Admin, Compliance Manager |