Suppressions and exceptions
Understand when to hide a violation and when to acknowledge it.
Suppressions and exceptions solve different problems, even though both reduce compliance noise.
Use a suppression to stop matching violations from surfacing at all.
Use an exception to acknowledge risk while keeping the violation visible.
This distinction matters because it changes both what appears in the posture dashboard and how criterion health is calculated.
For the admin workflows behind both rule types, see Compliance controls. For the day-to-day triage flow, see Compliance posture.
Choose the right action
Use a suppression when the criterion should not apply to some or all of your environment.
Use an exception when the violation is real, but the risk is understood and accepted.
In short:
suppressions hide,
exceptions acknowledge,
and only exceptions stay visible in posture.
Suppressions
Suppressions stop matching violations from appearing in posture.
Admins manage suppressions in Settings → Compliance → Suppressions.
The full setup flow is covered in Compliance controls.
Suppressions apply at the criterion level, and can be blanket or scoped.
Blanket suppressions
A blanket suppression hides every violation for one criterion.
Use this when the criterion does not apply.
A blanket-suppressed criterion shows as Fully Suppressed.
This is the broadest suppression type. It removes the criterion from active posture for all matching entities.
Scoped suppressions
A scoped suppression hides only matching entities.
Use this for targeted carve-outs.
Scoped suppressions use an entity filter. If you need a refresher on filter syntax and behavior, see Filters and Working with filters.
This lets you exclude specific slices of your environment without hiding the criterion everywhere else.
For example, you might suppress a criterion for resources tagged env=dev while keeping production violations visible.
Use scoped suppressions when you want to reduce noise without losing production signal.
Exceptions
Exceptions acknowledge a violation without hiding it; excepted violations stay visible in Compliance posture, but appear separately from active violations.
A fully excepted criterion (i.e., a framework criteria for which all violations have been marked as exception) shows as Passing with Exceptions.
Exceptions always require an entity filter — there is no concept blanket exception. They are meant to be used in a targeted manner.
This keeps accepted risk visible and reviewable, while preventing it from being treated the same way as unresolved active violations.
Global exceptions
Admins create rule-based exceptions in Settings → Compliance → Exceptions.
The admin workflow is covered in Compliance controls.
Use these when the same exception applies repeatedly. Global exceptions are useful when a known condition affects many similar entities and should be handled consistently.
Inline exceptions
Admins and risk managers can add quick exceptions from the violations table. Use these when reviewing a specific violation.
Inline exceptions are useful when the right decision becomes clear during triage and does not require broader configuration work. Note that inline exceptions persist across compute runs until and unless removed.
When to use each
Use a suppression when
The criterion does not apply to your environment.
A compensating control makes the check irrelevant.
You want to remove known noise from posture counts.
Use an exception when
The violation is real.
You accept the risk (for now).
You still want an audit trail in posture.
What changes in posture
After a suppression
Matching violations disappear from the dashboard.
Matching violations do not count as active.
Blanket-suppressed criteria show Fully Suppressed.
After an exception
Matching violations stay visible.
Matching violations move to Excepted Violations.
The exception reason appears on the Excepted badge tooltip.
This makes exceptions better for auditability and ongoing review, while suppressions are better for removing inapplicable or intentionally excluded checks.
Both suppressions and exceptions are logged with details of who created them, and when, and are retained in a read-only state with similar details on deletion. You can review these records from the Suppressions tab and Exceptions tab.
Last updated
Was this helpful?