> 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/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-access-control-configuration.md).
# Incident Access Control Configuration
In any SOC team there are a number of different roles and responsibilities. For example, you have specific teams to deal with specific threats, such as threat intelligence researchers, security analysts (Tier 1), senior analysts (Tier 2), SOC leads, SOC manager, SIEM engineers, etc. After you start ingesting incidents into Cortex XSOAR, you should consider how you want to investigate the incidents that are being ingested. You have various options to limit access to incidents and investigations.
{% hint style="info" %}
### Note
If no role is set for the incident, all users with read/write permissions for incidents can access and edit the incident. In order to access an incident, you must be assigned the same role that is assigned to the incident, even if you are the creator of the incident.
{% endhint %}
* [Exclude access to incident actions and investigations](/xsoar-6-administrator-guide/6.12/onboard-cortex-xsoar/onboarding-in-cortex-xsoar/users-and-roles/roles-in-cortex-xsoar.md#UUID-99ede556-4412-56f6-a647-755cf454eb84) according to roles, such as SIEM engineers. This enables you to limit role permission levels in investigations, data and chats in the War Room and restrict batch table actions in the Incidents page.
* [Restrict an Investigation](#UUID-873804ba-858e-8a1a-3af1-0620fddff8ae) to only team members. For example, if an incident contains sensitive data, and you only want specific users to investigate the incident, you can mark the incident as restricted. Other users cannot view or access the incident. Team members are added automatically when you send them a notification in the CLI or add them from the gear button. You can remove the restricted investigation at any time.
Note
When an incident is restricted with a read-only role, existing team members automatically get read-only access. Their permissions are adjusted, allowing them to continue viewing the incident, though they will not have write permissions.
* [Limit Access to Investigations using RBAC](#UUID-6bc274aa-a13e-a0cc-a6cc-8780a982247c).
* **Limit investigations according to specific roles**. By adding a role to the investigation, you restrict access to all roles, other than those you have specifically added. For example, after an investigation is closed, add administrators or those with specialty roles, so only they can reopen or link incidents.
The added roles have read and write permission, but all other roles do not have access (unless you have added them in the read-only field).
You can limit the investigation by either adding a role in the Roles field to the Incident Summary page, use the **`incident_set`** roles command, or run the command in a playbook. If using the Roles field in the Incident Summary page, you need to add the field when you [Customize Incident Layouts](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md#UUID-5cd6db5a-52b4-a3f9-ba81-e9b70feb7c11).
Note
If you add a role, but the incident has been restricted to team members, and the user is not a team member, the user cannot access the incident regardless of the role. For example, if you restrict the incident to User A and User B team members who are Tier 1 analysts but then try to add Tier 2 analysts (none of whom are team members) to the list of roles, a Tier 2 analyst cannot access the incident.
* **Give read-only access to certain roles**. For example, when an incident is in triage (phase 1), you may want all Tier-2 analysts to have read-only access, so that Tier-1 can edit the incident. When the phase changes to phase 2, Tier-1 has read-only access.
You add roles in the XSOAR Read-Only field in the Incident Summary page, use the **`incident_set roles`** command, or add the command to a playbook.
If using the XSOAR Read-Only field in the Incident Summary page, you need to add the field when [customizing incident layouts](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md#UUID-5cd6db5a-52b4-a3f9-ba81-e9b70feb7c11). You can change the XSOAR Read-Only field manually or automate the process by [creating a custom incident field](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md#UUID-404e9da4-6786-a71d-e616-5c39de59710f) using [incident field trigger scripts](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md#UUID-6fd56c99-21a6-ce00-e7ec-76411bfd1181), or create a script and adding a new field button.
When granting read-only access, the user can view the incident but not edit. Adding a team member overrides the XSOAR read only role, so if you add User A, (Tier 1) as a team member, even if you assign Tier-1 as a Read only role, the user still has Read/Write access. You need to remove the user as a Team Member.
Note
If you assign a role (read and write permission) and assign the same role as read only, the user still has read/write permission. You need to remove the assigned role. If you restrict the incident, the read-only role does not override the restriction. In other words, team members permission takes precedence.
### **Limit Access to Investigations using RBAC**
You can limit access to the investigations using RBAC by either assigning a specific role to the incident (read and write access to the investigation) or by assigning a role with read only permission. This procedure uses the **`incident_set`** command to limit investigation permissions but you can also add the **`Role`** and **XSOAR Read Only** rules fields to the Incident Summary page when customizing incident layouts. You can also add these columns to the Incidents table in the Incidents page.
1. In the **Incident** page, select the incident you want to restrict access.
2. Restrict the incident to a role.
1. In the CLI, type the following command:
**`/incident_set roles=`*****`