> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-agentix/configure-cortex-agentix/cases-and-issues-configuration/create-issue-exceptions.md). # Create issue exceptions {% hint style="warning" %} ### Prerequisites * To create issue exception rules, delete or disable exception rules, and view the **All Exception Rules** page you must have at least **View** permissions for the following roles under **Exception Configurations**: * **Exception Management Admin** * **Exception Approver Admin** * You must have **Exception Approver Admin** permission to add or delete issue exception approvers and to turn off and on approver functionality. {% endhint %} ### **What is an issue exception?** An issue exception is a formal, documented, and time-bound decision to defer the remediation of a confirmed security issue. It is an active decision to accept the risk associated with a known issue, rather than remediating it within the standard timeline dictated by corporate policy. Issue exceptions are configured with Exception Rules that pause specified issue Service Level Agreement (SLA) timers for a defined grace period of up to one year. Issue exceptions help reduce issue fatigue and allow you to focus on high-priority, actionable threats while acknowledging unavoidable delays. ### **Common use cases for issue exceptions** * **Vendor Dependency:** The vulnerability exists within a third-party commercial product or library. Remediation is technically blocked until the vendor releases an official patch. * **High Risk of Disruption:** The technical difficulty or potential operational downtime caused by remediation outweighs the security risk itself. For example, applying a required patch would break a critical legacy application. * **Compensating Controls:** Alternative security measures are deployed and actively mitigate the vulnerability's threat. For example, a vulnerable web server is shielded by a strictly configured Web Application Firewall (WAF) that blocks specific exploit techniques. * **Planned Remediation (Grace Periods):** Remediation is approved but delayed due to a scheduled maintenance window, or the issue exists in a newly deployed environment requiring a temporary grace period before standard production SLAs are enforced. * **Asset Decommissioning:** The affected service or asset is in the process of being decommissioned, rendering standard remediation efforts unnecessary. ### **Issue Exceptions vs. Exclusions** An issue *exception* is a temporary acceptance of a known, real vulnerability due to a business or technical constraint. An *exclusion* is permanent acceptance of an issue with no intention of ever resolving it. ### **Issue exception approval workflow** To maintain strict security governance, the issue exceptions rely on a structured, automated approval workflow. When an exception rule is created, an exception rule request is sent to an authorized approver via email. The approver has up to seven days to evaluate the risk, review any compensating controls, and formally approve or reject the request. An exception rule does not go into effect until the approver has approved it. Once the exception rule request has been approved, the rule becomes active, the relevant issue SLA timer is paused. And the status of the rule is Approved. If an approver rejects the exception rule request, the status of the rule will be Rejected. If an approver does not approve or reject an exception rule request within seven days, the request expires. Every step of the approval process, from the initial request to the final decision, is recorded in the system's audit logs to ensure full compliance and accountability. ### **Issue exception behavior** * **Issue Status**: When an exception rule is approved, the underlying status of the impacted issues do not change, for example, an excepted issue in the New state will stay in the New state. The system identifies excepted issues in the Issues list in the Excepted field, so you can easily filter for Excepted = YES to find excepted issues. * **Issue creation:** Issue exceptions do not prevent new issues from being created. New issues that match exception rules will have service-level agreement (SLA) timers paused and will indicate Excepted = Yes in the Issues list. * **SLA Impact**: The primary operational effect of an active exception is that it pauses the Service Level Agreement (SLA) timer for the affected issues. This prevents the system from triggering SLA breach alerts while the organization is managing the known business constraint. * **Exception expiration**: When an issue exception expires, the issue loses its excepted status. In the Issues list, the value of the Excepted field will change to No, and the SLA timer will automatically resume. {% hint style="info" %} ### Note * Issue exceptions apply specifically to issues, not individual findings. * Issue exceptions do not automatically update standard dashboards, reporting widgets, or compliance reporting profiles. To view the aggregate impact of exceptions, you must manually filter the issues table. * Exceptions do not alter Attack Path policies. * Exceptions do not bypass any preventative blocking actions executed by XDR or AppSec agents. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-agentix/configure-cortex-agentix/cases-and-issues-configuration/create-issue-exceptions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.