{"id":2763,"date":"2025-10-20T10:26:00","date_gmt":"2025-10-20T10:26:00","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=2763"},"modified":"2025-11-18T08:23:48","modified_gmt":"2025-11-18T08:23:48","slug":"jira-issue-security-schemes","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/jira-issue-security-schemes\/","title":{"rendered":"Jira Issue Security Schemes"},"content":{"rendered":"\n

Issue Security Schemes are one of the key features enabling your company to manage projects and tasks visibility. Very often, there are situations when the visibility of Issues within one Jira<\/a> project should be limited to roles forming groups. To do it, just use the solution described in this article. It\u2019s an additional feature that makes it easier to work in bigger teams and helps to avoid costly mistakes.<\/p>\n\n\n\n\n\n\n\n

To effectively manage issue security, it’s important to understand how security levels determine which users can view specific issues and identify which issues should be visible to certain roles or groups.<\/p>\n\n\n\n

The security level of individual Issues can be assigned at any time during the project\u2019s existence by users with the necessary permissions. However, in some cases, it may be more practical to set the security level at the time of Issue creation. In this tutorial, you will learn step by step how to use Issue Security Schemes<\/a> to make the processes supported by Jira more secure<\/a> and efficient. You will learn how to manage who can view issues in your project.\u00a0<\/p>\n\n\n\n

What is the Jira Issue security scheme?<\/h2>\n\n\n\n

An issue security scheme<\/strong> in Jira allows for the limitation of visibility of certain issues based on project roles, user groups, or certain users. The scheme defines security levels<\/strong>, each of which determines which users can view issues assigned to that level. These levels don\u2019t assign users directly but specify which groups or roles can access the issue.<\/p>\n\n\n\n

To configure issue-level security<\/strong>, you generally need to hold administrative permissions, either as a Jira administrator or a project admin with sufficient rights. Once set, sub-tasks automatically inherit<\/strong> the security level of their parent issue and cannot override it.<\/p>\n\n\n\n

When creating a new scheme, you can base it on an existing one \u2013 copy it, define new security levels<\/strong>, and link the scheme to selected projects. It is recommended that each scheme and its levels have clear, meaningful names and descriptions for future clarity and management.<\/p>\n\n\n\n

It\u2019s equally important to set a default security level<\/strong>, especially if visibility control is a priority. This ensures that all new issues automatically follow access restrictions based on the configured defaults\u2014unless explicitly changed by users with permission to do so during issue creation or editing.<\/p>\n\n\n\n

What are the levels in issue security schemes?<\/h2>\n\n\n\n

In Jira, it\u2019s possible to limit the visibility of individual issues by assigning them to specific issue security levels<\/strong>. Each level outlines who is permitted to access a given issue \u2013 whether based on user groups<\/strong>, project roles<\/strong>, or named individuals.<\/p>\n\n\n\n

These levels are organized under a broader configuration called a project issue security scheme, which must first be connected to the appropriate project before it takes effect.<\/p>\n\n\n\n

After linking a security scheme<\/strong> to a project, the defined security levels<\/strong> become selectable for issues within that project. Assigning a level to an issue restricts visibility to users identified in that level\u2019s configuration.<\/p>\n\n\n\n

Note<\/strong>:
Sub-tasks are not exempt – they automatically adopt the security level<\/strong> of their parent issue.<\/p>\n\n\n\n

To enforce access control by default, you can specify a default issue security level<\/strong> within the scheme. This ensures that every new issue, unless otherwise modified, is created with a baseline visibility scope already in place. You\u2019ll find this option under issue security settings in the scheme\u2019s configuration.<\/p>\n\n\n\n

The first step – manage project permissions<\/h2>\n\n\n\n

Before creating level security, it is important to give access to an administrator who can manage those attributes. To do that, follow the steps below.<\/p>\n\n\n\n

    \n
  1. Navigate to the Settings, then select Issue.<\/li>\n\n\n\n
  2. Choose the permission scheme and click on the \u201cPermissions\u201d button.<\/li>\n\n\n\n
  3. Scroll to \u201cSet Issue Security\u201d.<\/li>\n\n\n\n
  4. Grant access to the chosen group, users, or specific project roles.<\/li>\n<\/ol>\n\n\n\n

    Once permissions are set, you can associate an issue security scheme with your project by linking it in the project settings. Editing these associations allows you to update access as project needs change.<\/p>\n\n\n

    \n
    \"Project<\/figure><\/div>\n\n\n

    How to set up Jira Issue Security Scheme?<\/h2>\n\n\n\n

    To create an issue security scheme, follow the steps below.<\/p>\n\n\n\n

      \n
    1. Open Settings and click on Issues.<\/li>\n\n\n\n
    2. Scroll down to the \u201cISSUE ATTRIBUTES\u201d section and open \u201cIssue Security Schemes\u201d.<\/li>\n\n\n\n
    3. Click on the \u201cAdd issue security scheme\u201d button. Note that certain elements, like the \u2018Security Level\u2019 field, cannot be added to a Create Screen but can be included on View and Edit screens.<\/li>\n\n\n\n
    4. Fill in the name and the description. The latter is optional and will help you and admins on your instance in understanding why the Security level was created. Then add the scheme.<\/li>\n<\/ol>\n\n\n
      \n
      \"Jira<\/figure><\/div>\n\n\n
        \n
      1. A new element on the list will appear, which you can then edit and customize.<\/li>\n<\/ol>\n\n\n
        \n
        \"Get<\/a><\/figure><\/div>\n\n\n

        How to configure Jira security levels?<\/h2>\n\n\n\n

        When configuring your issue security scheme, you can choose which screens display the security level field. The security level field cannot be added to the create screen, but it can be added to the view and edit screens. This allows users to view or change the security level of issues directly from the appropriate screens, helping you manage issue security more effectively. To configure security levels, follow the steps below.<\/p>\n\n\n\n

          \n
        1. Go back to the list of issue security schemes and click \u201cSecurity Levels\u201d under the \u201cActions\u201d column.<\/li>\n<\/ol>\n\n\n
          \n
          \"Configuring<\/figure><\/div>\n\n\n
            \n
          1. Add security level names and descriptions.<\/li>\n\n\n\n
          2. New levels will appear on the list.<\/li>\n\n\n\n
          3. After creating levels, you can now configure them using the \u201cAdd\u201d button in the \u201cActions\u201d column.  <\/li>\n<\/ol>\n\n\n
            \n
            \"Configuring<\/figure><\/div>\n\n\n
              \n
            1. Set the level as you wish and click \u201cAdd\u201d.<\/li>\n\n\n\n
            2. On the list view of levels, you can also choose one of them to be the default issue security level by clicking on \u201cDefault\u201d in the \u201cActions\u201d column. Setting the default ensures that new issues are consistently protected with the appropriate security level.<\/li>\n<\/ol>\n\n\n\n

              Managing issue security<\/h2>\n\n\n\n

              Effectively managing issue security in Jira is essential to ensure that sensitive data is only visible to the right people. Below is a practical guide to help you handle issue-level security<\/strong> with clarity and confidence:<\/p>\n\n\n\n

              1. Understand your security requirements<\/strong><\/p>\n\n\n\n

              Before enabling issue security features, it\u2019s essential to map out your internal data sensitivity policies. Identify what types of issues contain confidential or restricted information, and determine which users or project roles<\/strong> should have access to them.<\/p>\n\n\n\n

              2. Set up security levels<\/strong><\/p>\n\n\n\n

              Go to the Issue Security Schemes page<\/strong> to create or modify your schemes. Add security levels<\/strong> with distinct, meaningful names that reflect their purpose (e.g., \u201cManagement Only\u201d or \u201cInternal QA\u201d). This naming clarity helps maintain consistency across projects.<\/p>\n\n\n\n

              3. Assign users, roles, or groups<\/strong><\/p>\n\n\n\n

              For each security level<\/strong>, specify project roles<\/strong>, groups<\/strong>, or individual users<\/strong> who should have visibility into issues using that level. When possible, favor project roles over static groups \u2013 they offer greater flexibility and reduce administrative overhead across company-managed projects<\/strong>.<\/p>\n\n\n\n

              4. Configure a default security level<\/strong><\/p>\n\n\n\n

              Within your issue security scheme<\/strong>, you should also set the default issue security level<\/strong>. This level is automatically applied when new issues are created \u2013 unless changed manually \u2013 helping maintain baseline access control without user intervention.<\/p>\n\n\n\n

              5. Review periodically<\/strong><\/p>\n\n\n\n

              Over time, access needs may evolve. Periodically audit who has visibility into each level. Make updates to the security levels<\/strong>, their members, or even the scheme association<\/strong> at the project level<\/strong> to ensure alignment with current organizational structure and access control policies.<\/p>\n\n\n\n

              By taking a deliberate approach to issue security<\/strong>, you protect critical data while keeping issue visibility aligned with your team structure and access expectations.<\/p>\n\n\n\n

              Best practices – improving the default security level(s)<\/strong><\/h2>\n\n\n\n

              When designing and maintaining your issue security schemes<\/strong>, following these best practices can make the difference between smooth collaboration and accidental data exposure:<\/p>\n\n\n\n