> 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-cloud-runtime-security/cases-and-issues/overview-of-cases/case-initiatives.md).
# Case initiatives
Learn how initiatives extend cases to track long-term, strategic security programs.
{% hint style="info" %}
#### Required licensing, scope, and permissions
* To create an initiative manually, you must have View/Edit permission for **Cases and Issues** selected under **Settings** → **Configurations** → **Access Management** → **Roles** → **Components** → **Cases & Issues**.
* Your access scope must include both the **Initiative** and the **Posture** case domains under **Settings** → **Configurations** → **Access Management** → **Scope** → **Case domain**. If either is missing, you can view initiatives but you cannot create them.
{% endhint %}
An **initiative** is a type of case for tracking a long-term security programs, where progress is measured as a trend over weeks or quarters. For example, you can use an initiative to reduce critical vulnerabilities on internet-facing hosts by the end of the quarter, or to eliminate publicly readable storage buckets across your cloud accounts.
Initiatives differ from standard cases in the following ways:
* **Filter-based:** Issues are added by association with a filter that you define, not linked manually.
* **Posture issues only:** Only Posture issues can be added to an initiative.
* **Higher issue limit:** An initiative can hold up to 10,000 issues.
* **Snapshot-based progress:** Snapshots track progress over time.
{% hint style="info" %}
#### Note
An initiative is a case in the **Initiative** domain. As with any case, you can create it under a single domain only, and you cannot change the domain after creation.
{% endhint %}
#### Filter-based association
An initiative does not hold a fixed list of issues. Instead, you define a filter when you create the initiative, and Cortex Cloud associates every Posture issue that matches it within your SBAC scope (see [Access scope and initiatives](#access-scope-and-initiatives) for more information). The filter continues to apply for the life of the initiative:
* Open issues that begin to match the filter are added automatically. Issues that are already resolved when they first match are not added.
* Issues that no longer match the filter are removed automatically, whether they are open or resolved.
* Issues that are resolved while they belong to the initiative remain counted, as long as they still match the filter, so that you can measure how much work has been completed.
As a result, an initiative reflects the current state of the risk you are tracking, without anyone maintaining the list by hand. Because the filter controls membership, you cannot curate the issues in an initiative: you cannot manually link an issue into an initiative, and you cannot manually unlink one.
{% hint style="info" %}
#### Note
Because issue membership is controlled entirely by the filter, the **Create an issue** and **Select from existing issues** options not available for initiatives.
{% endhint %}
{% hint style="warning" %}
#### Editing the filter resets the resolution cutoff
An initiative includes resolved issues only if they were resolved after a cutoff time. The cutoff is set when you create the initiative and resets to the current time whenever you edit the filter. When you save a filter edit, any issues that were resolved before the edit are removed from the initiative. As a result, the resolved count and progress drop at that point, but earlier snapshots are not changed.
{% endhint %}
An initiative can legitimately contain zero issues. An initiative with no matches is not an error; it usually means either that the filter is too narrow, or that the risk you are tracking has been fully remediated.
#### Access scope and initiatives
Initiatives are restricted to the Posture domain, and the issues they can reach are restricted by your own access scope (SBAC).
When you save an initiative, Cortex Cloud applies your access scope to the filter. From that point on, every recalculation applies the same scope, so the initiative only ever contains issues that were within the permitted scope at the time it was saved.
If a user edits the filter, the original scope is replaced by the access scope of the user who made the edit. If that user's scope differs from the creator's, the initiative is rescoped accordingly.
Consider the following information before you plan a program around an initiative:
* **You cannot create an initiative that reaches outside your own scope.** The domain is fixed to Posture and cannot be edited in the filter, and your permitted asset groups are always applied.
* **Two users can build the same filter and get different initiatives**, because each one is scoped to the user who saved it.
* **Editing the filter can change the initiative's scope**, because the scope of the user who saved the edit replaces the previous one.
For more information about how the issues are scoped, see [Create an initiative](/cortex-cloud-runtime-security/cases-and-issues/create-an-initiative.md).
#### Snapshots and progress
Cortex Cloud re-evaluates each initiative's filter every 12 hours and records the result as a **snapshot**: an immutable, timestamped record of the initiative at that moment. A first snapshot is taken as soon as the initiative is created.
Each snapshot captures the number of open and resolved issues, what changed since the previous snapshot, the assignee breakdown, the initiative SLA, and the initiative's progress and trend. Because snapshots are never modified after they are written, the sequence of snapshots forms a reliable history that drives the progress and velocity charts on the initiative.
You can also take a snapshot if you need an up-to-date picture. Editing the filter triggers a fresh snapshot automatically. For details, see [Review an initiative](/cortex-cloud-runtime-security/cases-and-issues/create-an-initiative/review-an-initiative.md).
#### Target dates and SLA
Each initiative has a target completion date. The **Initiative ETA** is required when you create an initiative, and the earliest date you can select is the day after creation. Cortex Cloud attaches a dedicated Resolution SLA rule to each initiative to help you to track its progress.
{% hint style="info" %}
#### Note
The SLA timer continues to run after an initiative is resolved.
{% endhint %}
#### Statuses and resolutions
Initiatives use the standard case statuses. When you resolve an initiative, select one of the following resolution types, which reflect program outcome rather than threat containment:
* **Completed**: the goal was met.
* **Missed**: the target date passed without meeting the goal.
#### Initiative and snapshot limits
The following limits control how many issues an initiative can track, how many initiatives a tenant can have open at once, and how often snapshots are taken.
Limit
Value
Issues per initiative
10,000
Open initiatives per tenant
500
Automatic recalculation interval
Every 12 hours, for open initiatives only
Minimum interval between manual snapshots
2 hours after a successful snapshot
If a filter matches more than 10,000 issues, Cortex Cloud displays a warning while you build the filter. Narrow the filter before you save: if you save anyway, the initiative is created, but its snapshot fails and no issues are associated until you narrow the filter. If a later recalculation exceeds the limit, that snapshot also fails and the initiative keeps its previous state. For more information, see [Review an initiative](/cortex-cloud-runtime-security/cases-and-issues/create-an-initiative/review-an-initiative.md).
The 2-hour minimum interval applies only after a successful snapshot. If the last snapshot failed, you can take a manual snapshot immediately.
Scheduled recalculation runs for open initiatives only. After an initiative is resolved, no more snapshots are taken, and you cannot take a manual snapshot.
---
# 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/cortex-cloud-runtime-security/cases-and-issues/overview-of-cases/case-initiatives.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.