> 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-xsiam/reference-and-developer-docs/role-based-access-control/role-permissions-by-component.md).

# Role permissions by component

Role-Based Access Control (RBAC) restricts system access to authorized users based on their assigned roles. RBAC ensures that user roles have only the permissions and dataset visibility necessary to perform their specific job functions. Custom roles govern not only which components a user can see or edit, but also which underlying datasets they are permitted to query.

You can manage role permissions in Cortex XSIAM under **Settings** → **Configurations** → **Access Management** → **Roles**.

{% hint style="info" %}

### Tip

While Cortex XSIAM provides predefined, out-of-the-box roles, it is highly recommended to make copies of these roles and edit them rather than creating new roles from scratch, ensuring you do not miss any critical underlying permission dependencies.
{% endhint %}

**Custom Role personas**

The following example roles explain the standard responsibilities and baseline permission needs for the security personas referenced throughout this section:

| Role               | Responsibilities                                                                                                                                                                                                                                              |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SOC Tier-1 Analyst | First line of defense responsible for initial issue/case triage and basic investigation (triage). Requires View access to cases, issues, and endpoint data, with limited action capabilities (for example, acknowledging issues) and no configuration access. |
| SOC Tier-2 Analyst | Conducts an in-depth investigation of escalated cases and coordinates response (responder). Requires full View access to security data, with action capabilities for case response (isolate, scan, quarantine), but limited configuration access.             |
| SOC Tier-3 Analyst | Handles complex cases and performs advanced forensic analysis (senior/forensics). Requires comprehensive View access, advanced action capabilities (live response, file destruction), and potential input on policy tuning.                                   |
| Threat Hunter      | Proactively searches for evaded threats using hypothesis-driven techniques. Requires extensive View access across all data, deep query/search capabilities, and visibility into policies/exceptions to identify coverage gaps.                                |
| Security Engineer  | Designs, implements, and maintains security tools and configurations. Requires full View/Edit access to policies, agent deployments, rules, and exceptions, but typically lacks user/role administration access.                                              |

**Best practices**

* Customization: The roles provided are examples. You should customize them based on your specific needs, keeping in mind that role overlap is normal in smaller organizations.
* Least privilege: Follow the principle of least privilege by granting only the minimum permissions necessary.
* Separation of duties: Separate configuration and operational roles to maintain proper controls, and periodically review assignments.
* Dependency priority legend:
  * Required: Feature will not work without it.
  * Strongly recommended: Significantly enhances the feature, and most users will need it.
  * Recommended: Useful but optional.

**Permission categories by function**

Permissions are divided into macro-categories based on functional areas and operational workflows:

* Core Tenant and Administrative permissions: Fundamental system settings, user access controls, and backend infrastructure (data collection, integrations, brokers). Typically reserved for IT and Security Administrators.
* SOC Operations, Investigation & Response permissions: Daily operational tools for triage, investigation, and response (dashboards, cases, playbooks, Live Terminal).
* Agents and Endpoint protection permissions: Features relying on XDR Agent infrastructure (prevention policies, host firewalls, Device Control, and Endpoint DLP).
* Cloud Security and Posture Management permissions: Unifies cloud modules (CSPM, ASPM, DSPM) requiring specific licenses like Cloud Posture or Runtime.
* Exposure and Vulnerability Management permissions: Manages the vulnerability lifecycle from discovery (Attack Surface) to tracking (Vulnerability Management) and prioritization (Exposure Management).
* Inventory Permissions: Foundational visibility into assets and network topology. Controls access to the unified asset inventory and asset groups used for Scope-Based Access Control (SBAC).

**Datasets tab**

Under the Datasets (Disabled) tab, you have the following options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:

* Set the role to have access to all XQL datasets by leaving dataset access management disabled (default).
* Set the role to have limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the datasets under the different dataset category headings.


---

# 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-xsiam/reference-and-developer-docs/role-based-access-control/role-permissions-by-component.md?ask=<question>&goal=<endgoal>
```

`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.