Study guide
3.3 Issue Security Schemes, Security Levels & Access Containment
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
3.3 Issue Security Schemes, Security Levels & Access Containment
Key Takeaways Explain This Topic AI
Issue Security Schemes restrict visibility of individual issues within a project to specific security levels.
The Set Issue Security project permission controls who can view, set, or change the Security Level field on create and edit screens.
Issues protected by a security level are completely invisible to unauthorized users across JQL search, board backlogs, dashboard gadgets, and email notifications.
Designating a Default Security Level ensures that new issues—including those created via automated email handlers or automation rules—are secured immediately upon creation.
Sub-tasks always inherit the parent's security level, and team-managed projects use role-based restrictions instead of issue security schemes.
Last updated: September 2026
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:
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.
Groups: Global user groups (e.g., legal-team , compliance-officers ).
Single Users: Specific user accounts (discouraged due to administrative overhead).
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.
User Custom Field Values: Dynamic assignment based on a user picker field (e.g., an "External Auditor" custom field on the issue).
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:
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.
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.
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
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 ).
Map Existing Levels: If replacing an existing scheme, Jira requires mapping each legacy security level to a corresponding level in the new scheme.
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:
- Behavior Company-Managed (Issue Security Scheme) Team-Managed (Restrictions)
- Configured by Jira admin creates the scheme and levels Chosen per issue, based on the project's roles
Who can view Members of the selected security level (roles, groups, users, reporter, assignee, user/group fields) People in the selected roles
Sub-task behavior Inherits the parent's level Inherits the parent's restrictions and can't be changed individually
Default for new issues Optional default security level None unless the creator sets a restriction
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.