Exceptions
Exceptions allow you to formally accept the risk of certain vulnerabilities while still tracking them for audit purposes. Cloudaware models these as separate records linked to one or more Vulnerability Scan records.
Use this guide to understand how vulnerability exceptions are registered and governed in Cloudaware, including their scope, lifecycle, and impact on suppression, SLA tracking, and reporting.
Vulnerability Exception Records
Key characteristics:
- Represent a documented risk acceptance decision.
- Linked to one or more Cloudaware Vulnerability Scan records.
- Contain metadata such as:
- Scope (which assets, CVEs, or findings are covered).
- Reason/justification.
- Owner and approver.
- Start and expiry dates.
- Any compensating controls in place.
When an active exception exists for a finding:
- The related Vulnerability Scan record is marked as suppressed (e.g., via
Is Suppressed). - Suppressed findings are excluded from standard SLA calculations and most remediation queues.
- They remain visible in exception‑specific reports and audit views.
Fields
The object: Vulnerability Exception Vulnerability_Exception__c
| Field Label | Field API Name | Data Type |
|---|---|---|
| Created By | CreatedById | Lookup(User) |
| Crowdstrike Host | Crowdstrike_Host__c | Text |
| CVE | CVE__c | Text |
| Host ID | hostId__c | Text |
| Host IDs | hostIds__c | Long Text Area |
| Host IDs to Exclude | hostIdsToExclude__c | Long Text Area |
| Host IDs to Skip | hostIdsToSkip__c | Long Text Area |
| Hostnames | hostnames__c | Long Text Area |
| Hostnames to Skip | hostnamesToSkip__c | Long Text Area |
| Last Modified By | LastModifiedById | Lookup(User) |
| Organizational Unit | Organizational_Unit__c | Picklist |
| Owner | OwnerId | Lookup(User) |
| Source | source__c | Picklist |
| Suppression Expiration Date | Suppression_Expiration_Date__c | Date |
| Suppression Justification | Suppression_Justification__c | Long Text Area |
| Vulnerabilities Count | countOfVulnerabilities__c | Number |
| Vulnerability Exception Expired | Vulnerability_Exception_Expired__c | Formula (Checkbox) |
| Vulnerability Exception ID | Name | Auto Number |
Lifecycle and Governance
Recommended lifecycle:
- Request – owner requests an exception with clear justification and proposed end date.
- Review & Approval – security or risk committee reviews, may require compensating controls.
- Active – exception is active; affected findings are suppressed.
- Expiry/Renewal – exception either expires (and findings return to normal queues) or is renewed with updated justification.
Best practices:
- Avoid open‑ended exceptions; always include an expiry date.
- Require higher‑level approval for Critical or High‑risk exceptions.
- Periodically review active exceptions by OU and application.
Relationship to Processes and Reporting
- Exceptions feed into the broader Vulnerability Management processes, especially escalation reports.
- Dashboards should differentiate between:
- Open vulnerabilities with no exception.
- Vulnerabilities covered by active exceptions.
See SLA Tracking for how exceptions affect SLA metrics.