Exceptions and exclusions
Create narrow, expiring policy exceptions and distinguish suppression from disabled enforcement.
Exceptions change a specific policy decision for an approved target and interval. They preserve the original rule and reason so a temporary business need does not silently become a permanent coverage gap.
At Policies → Exceptions → Create, select the policy family, rule, asset IDs or group, match conditions, owner, reason, and expiry. Preview the resulting target set and whether the exception changes monitoring, blocking, alert routing, scan scope, or access. Those effects are distinct; a notification suppression must not be described as disabling enforcement.
Review and activate
Exceptions require the configuration authority for every target. Access and risk-acceptance exceptions also require their respective approval grant. A broad hostname, subnet, or process-directory exception can suppress unrelated activity; use the smallest stable identity supported by the rule.
An exception becomes effective only when the relevant published revision is adopted. Exception → Adoption shows pending and failed targets. Offline devices can retain a prior policy. Emergency response deadlines do not make configuration delivery instantaneous.
Expire and remove
At Policies → Exceptions → Expiring, review upcoming expirations with their owners. Extending an expiry requires a new recorded review.
Check local expiry support under Endpoint → Capabilities or Access → Gateways → Gateway → Capabilities. An executor with this support ends an adopted exception at its recorded expiry. Other targets need the updated policy delivered after expiry. If such a target is offline, restore management connectivity and confirm its applied revision under Exception → Adoption before treating enforcement as restored.
To end an exception early, select Exception → Revoke, then check Exception → Adoption for pending or failed targets. Repeat the affected policy test after adoption. A scan check skipped during the exception needs a new authorized scan; revocation does not run it retroactively.
Accepted vulnerability risk, a quarantine restoration, and an access-policy exception require separate decisions. Do not use one exception type as implicit authorization for another operation. Audit records retain the reviewer, scope, revisions, and actual expiry.