> 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/application-security/application-security-posture-management-aspm/service-lead-agreements-sla.md). # Service Lead Agreements (SLA) Application Security SLA defines deadlines for fixing security issues based on severity, ensuring timely remediation and improving team performance. Cortex Cloud Application Security SLA defines remediation timeframes for security issues based on their severity, ensuring timely fixes and improving team performance. It sets clear expectations for how quickly threats must be addressed and provides a measurable metric for tracking responsiveness, identifying bottlenecks, and strengthening overall security posture. Cortex Cloud Application Security SLAs apply to issues detected during periodic code scans. Each severity level has an assigned remediation timeframe to support consistent issue management. The default target remediation timeframes are: * **Critical**: 7 days * **High**: 14 days * **Medium**: 30 days * **Low**: 90 days You can modify these values as required. #### SLA status and monitoring SLA status provides immediate risk context for prioritization of issues. The system automatically calculates and updates each issue’s SLA status based on periodic scans and the configured timeframes. There are three SLA status values: * **On Track**: The issue is within its assigned remediation timeframe * **Approaching**: The issue's SLA will be breached in a configurable number of days (the Approaching threshold). This status alerts you before an issue becomes overdue * **Overdue**: The issue has breached its SLA #### Roles and responsibilities * **AppSec practitioners**: * Define and configure the SLA targets for each severity level * Track the SLA status for all Cortex Cloud Application Security issues across the organization * Generate reports and dashboards to measure team performance and identify trends * **Developers** / **DevSecOps**: * Be aware of and adhere to the SLA commitments for all assigned issues * Actively monitor and prioritize issues that are nearing or have exceeded their SLA #### Use cases and features * **For AppSec practitioners**: * **Overdue dashboard**: Get a clear overview of all **Approaching** and **Overdue** issues. This allows you to quickly identify problematic areas and contact the relevant teams * **Centralized SLA tracking**: The SLA status for each issue is displayed directly in the Cortex Cloud Application Security issues tables * **Categorized overdue issues**: Filter overdue issues by domain (such as SAST, SCA, IaC, Secrets) to understand which areas require additional attention * **Detailed issue information**: A side panel on each issue provides a comprehensive view of its SLA details, including the configured time and how many days have passed, helping you understand its priority * **For developers** : * **SLA visibility**: See the specific SLA you need to follow for each issue, ensuring you are always aware of your commitments * **Overdue issues**: Easily identify and filter issues that are past their SLA, so you can prioritize and fix them immediately * **Upcoming overdue issues**: Anticipate and prepare for issues that will become overdue in a configurable number of days, allowing you to take preventative action --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cortex-docs.paloaltonetworks.com/application-security/application-security-posture-management-aspm/service-lead-agreements-sla.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.