3.3 Issue Security Schemes, Security Levels & Access Containment

Issue Security Schemes, Security Levels & Access Containment

While permission schemes control access at the project level, organizations frequently require granular, issue-by-issue access containment within a single project. For example, a software engineering project may track routine bugs alongside critical security vulnerabilities that must remain confidential until patched. Similarly, an HR or Legal service desk may handle general inquiries alongside sensitive disciplinary investigations. In Jira Cloud, this granular containment is achieved through Issue Security Schemes.

---

The Architecture of Issue Security Schemes

An Issue Security Scheme defines a collection of Security Levels. Each security level contains an access list specifying which users, groups, project roles, or dynamic actors can view issues assigned to that level.

+-------------------------------------------------------------------------+
|                    Project: Human Resources (HR)                        |
|                    Issue Security Scheme: HR Security                   |
+-------------------------------------------------------------------------+
   |                                                                     |
   +--> Level: General Employee Inquiry (Default)                        |
   |    - Project Role: HR Team                                          |
   |    - Dynamic Actor: Reporter                                        |
   |    - Dynamic Actor: Current Assignee                                |
   |                                                                     |
   +--> Level: Executive Compensation & Grievance                        |
   |    - Project Role: HR Directors                                     |
   |    - Dynamic Actor: Reporter                                        |
   |    - User Custom Field: Legal Counsel Reviewer                      |
   |                                                                     |
   +--> Level: Whistleblower Investigation                               |
        - Group: executive-compliance-officers                           |
        - Dynamic Actor: Current Assignee                                |
+-------------------------------------------------------------------------+

Entities That Can Be Added to Security Levels

Similar to permission schemes, security levels can grant visibility to several entity types:

1. Project Roles: The recommended best practice for project-level flexibility (e.g., Project Role: Security Leads). Project admins can adjust role membership locally without needing Jira Administrator privileges.
2. Groups: Global user groups (e.g., legal-team, compliance-officers).
3. Single Users: Specific user accounts (discouraged due to administrative overhead).
4. Dynamic Actors:
   • Reporter: Crucial for confidential ticketing. Allows the person who submitted a sensitive ticket to track progress while hiding the ticket from other general project members.
   • Current Assignee: Allows the specific investigator or engineer assigned to the ticket to view and update it.
   • Project Lead: Ensures the project lead maintains oversight.
5. User Custom Field Values: Dynamic assignment based on a user picker field (e.g., an "External Auditor" custom field on the issue).
6. Group Custom Field Values: Dynamic assignment based on a group picker field.

Important Architectural Note: Merely assigning an issue to a user does NOT grant that user visibility under an Issue Security Scheme unless the Current Assignee actor is explicitly added as a member of that security level. If an administrator assigns a restricted issue to a developer who is neither in the assigned Project Role nor covered by Current Assignee, the developer will immediately lose access to the ticket upon reassignment.

---

The 'Set Issue Security' Project Permission

A critical distinction on the ACP-120 exam is the interplay between the Issue Security Scheme and the Project Permission Scheme:

• The Issue Security Scheme defines the security levels and who is allowed to view issues at each level.
• The Project Permission Scheme contains the Set Issue Security permission, which dictates who has the right to set or change the Security Level field.

+-----------------------------------+       +-----------------------------------+
|         Permission Scheme         |       |       Issue Security Scheme       |
|                                   |       |                                   |
|  Permission: 'Set Issue Security' | ----> |  Controls visibility of the       |
|  - Project Role: Administrators   |       |  'Security Level' dropdown on     |
|  - Project Role: Security Leads   |       |  Create and Edit screens          |
+-----------------------------------+       +-----------------------------------+

Operational Rules for 'Set Issue Security'

• User HAS Set Issue Security: The "Security Level" field appears on the user's Create Issue and Edit Issue screens. The user can select any security level that they themselves are a member of.
• User LACKS Set Issue Security: The "Security Level" field is completely hidden from their Create and Edit screens. When this user creates an issue, Jira automatically applies the project's Default Security Level (if configured). If no default level exists, the issue is created with No Security Level (making it visible to everyone with Browse Projects).
• Restricted Selection: A user with Set Issue Security can only assign security levels that they belong to. They cannot place an issue into a level they cannot access (which would cause them to immediately lock themselves out).

---

Configuring Default Security Levels & Automated Ingestion

Each Issue Security Scheme can designate exactly one security level as the Default Security Level:

Security Level Name    | Members                              | Default
-------------------------------------------------------------------------
Public Information     | Anyone with Browse Projects          | 
Internal Team Only     | Project Role: Developers, Reporter   |  [X] Default
Executive Restricted   | Group: executive-directors           | 

Implications for Email Handlers and Automation

Setting a default security level is essential for projects that ingest tickets via automated channels:

1. Mail Handlers (Incoming Email): When Jira Cloud creates issues from incoming emails, the email handler does not specify a security level. If a Default Security Level is configured, the newly created issue is immediately protected by that level. Warning: If the email sender is not included as a member of that default level (e.g., via the Reporter dynamic actor), the sender will be unable to view their issue or receive email updates.
2. Jira Automation Rules: When automation rules trigger on Issue Created or use the Create Issue action, issues will inherit the Default Security Level unless the action explicitly specifies an alternative Security Level value.
3. Absence of Default Level: If no default level is set and an issue is created by a user without Set Issue Security (or via email), the issue is created with Security Level = None. This means the issue has no containment and is visible to all users with Browse Projects.

---

Associating Schemes with Projects & the Migration Wizard

Attaching an Issue Security Scheme to a project (or switching from one scheme to another) requires navigation to Project settings > Issue security (or via the project administration sidebar).

When an administrator associates an Issue Security Scheme with a project that already contains existing issues, Jira initiates the Issue Security Migration Wizard:

+---------------------------------------------------------------------+
|                 Migrate Project Issue Security                      |
|                                                                     |
|  The project 'Core Engineering' contains 850 existing issues.       |
|  Please map existing security levels to the new scheme:             |
|                                                                     |
|  Issues with No Security Level (800 issues):                        |
|  [ Map to: Internal Team Only                                   v ] |
|                                                                     |
|  Issues with 'Old Level: Confidential' (50 issues):                 |
|  [ Map to: Executive Restricted                                 v ] |
|                                                                     |
|  [ Acknowledge Reindex & Begin Migration ]                          |
+---------------------------------------------------------------------+

Migration Steps

1. Identify Unsecured Issues: Jira prompts the administrator to select a security level for all issues that currently have no level (or keep them as None).
2. Map Existing Levels: If replacing an existing scheme, Jira requires mapping each legacy security level to a corresponding level in the new scheme.
3. Background Reindexing: Once confirmed, Jira updates all issue records and triggers a background search reindexing process so that JQL indexes immediately reflect the new containment boundaries.

---

Absolute Access Containment: Search, Boards & Notifications

Unlike traditional permission systems that display "Access Denied" placeholders, Jira's Issue Security provides complete, silent containment across all product interfaces.

1. JQL Search & Filter Integrity

When a user executes a search (e.g., project = SEC AND statusCategory != Done):

• Jira filters out any issue assigned to a security level the user is not a member of before returning the result set.
• The user is not informed that issues were omitted. The total count returned reflects only the issues they are authorized to see.
• Two users executing the identical JQL query in the same project will receive different total issue counts if one user has access to restricted security levels.

2. Agile Boards (Scrum & Kanban)

Agile boards run on saved JQL filters. If a board's filter encompasses issues with restricted security levels:

• Unauthorized team members will not see restricted cards on the Kanban board, Active Sprint board, or Backlog.
• Burndown charts, velocity charts, and cumulative flow diagrams seen by that user will only calculate metrics based on the visible tickets.
• Team leads with access to the security level will see the complete board including the confidential issues.

3. Email Notifications

Issue Security acts as an upstream filter for the project's Notification Scheme:

• When an event occurs (e.g., Issue Commented, Issue Updated), Jira evaluates the Issue Security Level first.
• If a user on the notification list (such as a watcher, component lead, or group) is not a member of the issue's security level, Jira suppresses the notification entirely.
• This prevents data leakage through automated notification emails.

---

Inheritance and Team-Managed Restrictions

Blueprint 1.5 also covers two behaviors outside the scheme itself.

Sub-tasks inherit the parent's security level

A sub-task always takes its project, issue security level, and sprint from its parent. You can't give a sub-task a different security level. Change the parent's level and every sub-task follows. Atlassian's documented workaround for "parent visible to one group, sub-task to another" is to design the security level around user or group custom fields, not to set levels on sub-tasks.

Team-managed projects use restrictions, not security schemes

Team-managed projects have no issue security schemes. Instead, in team-managed software projects, a user creating an issue can restrict it to specific project roles. The rules to remember:

Exam angle: If a question asks how to hide a sensitive issue from most members of a team-managed project, the answer is a restriction to specific roles, not an issue security scheme. For a company-managed project, you need an issue security scheme, the Set Issue Security permission for whoever chooses the level, and a security level whose members include the right people.