Managing Exceptions
Not every compliance control failure represents an actual risk to your organisation. Some controls may not apply to your specific context, others may have compensating controls in place, and some failures may represent accepted risks that have been reviewed and approved by your team.
Guardian Pro's exception management feature allows you to formally document these situations, keeping your compliance score accurate and your audit trail clean.
What Is a Compliance Exception?
An exception is a documented declaration that a specific control failure is understood and accepted. When you create an exception for a control, you are stating that:
- You are aware the control is not passing
- You have evaluated the risk
- You have a documented reason for accepting the deviation
Excepted controls are tracked separately from failing controls and do not count against your compliance score. However, they remain visible in reports and on the dashboard with an exception badge, ensuring full transparency.
When to Create an Exception
Exceptions are appropriate in several common scenarios:
Accepted Risk
Your security or compliance team has reviewed the finding, assessed the risk, and determined that it is acceptable given your specific context.
Example: A CIS benchmark control recommends rotating IAM access keys every 90 days. Your organisation uses short-lived credentials via IAM roles for all workloads, and the few remaining access keys are used by tightly controlled CI/CD pipelines with additional compensating controls. You create an exception noting the compensating controls.
Compensating Control
You have an alternative control in place that addresses the same risk through a different mechanism.
Example: A control requires VPC flow logs on all VPCs. Your organisation uses a third-party network monitoring solution that provides equivalent or superior visibility. You create an exception documenting the compensating control.
Not Applicable to Your Context
The control evaluates a service or pattern that, while present in your environment, is not relevant to the compliance requirement in your specific context.
Example: A GDPR control flags an unencrypted S3 bucket, but the bucket contains only public marketing assets and no personal data. You create an exception noting that the bucket does not contain data subject to GDPR.
Temporary Deviation
You are aware of the gap and have a remediation plan, but the fix cannot be applied immediately due to change management constraints, dependency on a vendor, or a scheduled maintenance window.
Example: A control requires encryption at rest for an RDS instance. Enabling encryption requires a migration to a new instance, which is scheduled for next month's maintenance window. You create a temporary exception with a target resolution date.
Creating an Exception
To create an exception:
- Navigate to the Compliance Dashboard.
- Find the failing control you want to except.
- Click on the control to open its detail view.
- Click Create Exception.
- Fill in the exception form:
| Field | Description | Required |
|---|---|---|
| Justification | A clear explanation of why this exception is being created | Yes |
| Exception type | Accepted Risk, Compensating Control, Not Applicable, or Temporary | Yes |
| Approver | The person who approved this exception | Yes |
| Expiry date | When the exception should be reviewed or expires (optional but recommended) | No |
| Notes | Additional context, references to tickets, or links to compensating control documentation | No |
- Click Confirm to create the exception.
Exceptions should be reviewed periodically. Setting an expiry date ensures that exceptions do not become stale. Guardian Pro will flag expired exceptions on the Compliance Dashboard so they can be re-evaluated.
How Exceptions Affect Compliance Scores
When an exception is active on a control:
- The control is marked with an exception badge in the controls list
- The control is excluded from the compliance score calculation -- it does not count as either passing or failing
- The exception is included in compliance reports with its justification, providing full audit transparency
- The underlying checks continue to run -- if the issue is resolved, you can remove the exception to let the control count as PASS
Score Calculation Example
| Scenario | Total Controls | Passing | Failing | Excepted | Score |
|---|---|---|---|---|---|
| Without exceptions | 100 | 85 | 15 | 0 | 85% |
| With 5 exceptions | 100 | 85 | 10 | 5 | 89.5% (85/95) |
Excepted controls are removed from both the numerator and denominator of the score calculation. This prevents organisations from artificially inflating scores by excepting large numbers of controls -- auditors can see exactly how many exceptions exist.
Managing Existing Exceptions
Viewing Exceptions
To see all active exceptions:
- Open the Compliance Dashboard.
- Filter the controls list by looking for the exception badge, or filter by status to find excepted controls.
Each excepted control shows:
- The original justification
- Who approved the exception
- When it was created
- When it expires (if an expiry date was set)
Removing an Exception
To remove an exception (for example, after remediating the underlying issue):
- Click on the excepted control.
- In the control detail view, locate the active exception.
- Click Remove Exception.
- Confirm the removal.
The control will return to normal evaluation. If the underlying checks are now passing, the control will be marked as PASS. If the issue persists, it will be marked as FAIL and count against your compliance score again.
Expired Exceptions
When an exception reaches its expiry date:
- The exception badge changes to indicate it has expired
- The control remains excepted until you explicitly remove or renew the exception
- Expired exceptions are highlighted on the Compliance Dashboard as items requiring review
Review expired exceptions promptly. An expired exception signals that the justification may no longer be valid and the control should either be remediated or the exception renewed with updated justification.
Exceptions in Compliance Reports
When you export a compliance report, exceptions are included with full transparency:
- Excepted controls appear in a dedicated section of the report
- Each exception includes the justification, approver, and creation date
- The report clearly shows how many controls are passing, failing, and excepted
- Auditors can see the complete picture, including your documented rationale for each exception
Best Practices for Exception Management
Document Thoroughly
Write clear, specific justifications. "Accepted risk" alone is not sufficient. Explain why the risk is acceptable, what compensating controls exist, and who approved the exception.
Set Expiry Dates
Even for permanent exceptions, set a review date (for example, annually). This ensures that exceptions are periodically re-evaluated as your environment evolves.
Keep Exceptions Proportional
A large number of exceptions relative to your total controls may raise concerns during audits. Aim to remediate issues where possible and reserve exceptions for genuinely justified cases.
Link to External Documentation
Use the notes field to reference external documentation such as risk register entries, Jira tickets, or security review records. This creates a traceable audit trail.
Review After Changes
When your environment changes significantly (new services, new accounts, architecture changes), review existing exceptions to ensure they are still valid.
Permissions
Creating and managing exceptions requires appropriate permissions. Typically, this is restricted to users with compliance or administrative roles to prevent unauthorised exception creation. See Users and Permissions for details on permission configuration.