Restrict Sensitive Bugs in Jira Cloud With Issue Security Levels

A defect report can belong in a shared Jira project without belonging in every project member’s view. An ordinary bug may need broad triage, while another record needs a smaller review group. Jira Cloud issue security lets an administrator define that narrower audience without treating the whole project as confidential.

Use harmless dummy data while designing the restriction. The example below is fictional and unexecuted: no Jira tenant was accessed, no permission was changed, and no viewer test or move was performed. A security level controls native record visibility. It does not establish permission to execute a testing app or prove that external copies are protected.

Check the Project Type, Plan, and Permission Layers

This procedure is for a paid, company-managed Jira Cloud project. Current Atlassian documentation often calls a project a “space” and an issue a “work item.” Those newer terms appear in the documented controls below; the title retains the familiar issue-security wording.

Confirm the plan before looking for configuration controls. Free Jira sites cannot configure work item security schemes. If a site was downgraded from paid Jira, or migrated from Data Center to Free, existing permission schemes, space roles, and work item security schemes are preserved but cannot be edited. Atlassian names Standard, Premium, and Enterprise upgrades as the route to changing them. Do not interpret a missing configuration option as proof that existing restrictions have disappeared.

The native visibility rule has two parts: a person needs Browse spaces permission and must belong to the security level applied to the record. Browse alone does not open a restricted bug. Membership of a level does not supply access to its project.

Separate that viewing decision from administrative authority:

• Set Work Item Security controls changing an individual record’s security level. The relevant level must already exist in the project’s scheme; Atlassian’s learning guidance also says a setter can select only a level that includes them.
• Administer Jira is required by the dedicated procedures for creating schemes, granting level membership, and associating schemes with company-managed spaces.
• Permissions in an installed testing app or external runner need their own review. Neither Browse nor level membership is an execution entitlement.

Team-managed projects use a different workflow. Atlassian documents restricting a work type to nominated project roles for newly created work, with previously created items unaffected by that default restriction. If the project is team-managed, use its role-based restriction guidance rather than following the shared company-managed scheme procedure unchanged.

Configure the Scheme Before Touching Sensitive Records

Start with the data owner’s intended audience and an authorized Jira administrator. Write down which project, bug types, creation paths, and existing records are in scope. A scheme can be shared across projects, so inspect its associations before changing a level that other teams may already use. Keep the first exercise limited to a controlled dummy record rather than a real confidential defect.

Define the Level and Its Audience

The documented administration path is Settings, then Work items, then Work item security schemes under Work item attributes. Select Add work item security scheme, name the scheme, and add it. Open its Security Levels action to define a clearly named level and description.

A useful description states who should see the record and who owns membership review. “Sensitive defect review” communicates more than “Level 2,” but the name itself grants nothing. Configure the actual allowed entries, such as a project role, group, or named user, using the scheme’s Add action. Review the members behind each entry, not only the label in the scheme.

Reporter and Current assignee are available membership choices. They are not automatic exceptions that should be assumed for every level. If the intended policy includes the reporter, configure and verify that choice explicitly; otherwise a creator may report a bug and then be unable to open it. An empty level can lock everyone out of the affected records.

Administrator access also needs careful wording. An administrator outside the applied level is not automatically an included viewer under an unchanged membership snapshot. However, Atlassian explicitly notes that Jira administrators can add themselves to a security level. Do not present issue security as an immutable confidentiality boundary against administrators who can reconfigure it.

Choose a Creation Default and Check the Field

A scheme default gives newly created work a starting security level unless a permitted user selects another one. Work created by someone without permission to set a level still receives the default. If no default exists, new work has None: the Security Level field is empty and users with Browse spaces can see it.

Choose that default deliberately. A narrowly restricted default can prevent an accidental broad starting audience, but it can also hide a newly created report from its creator or legitimate responders. A broad default leaves classification dependent on another action. Review the intended creation paths and approved audience before deciding, then verify the behavior with dummy records. A default value is not proof that every existing bug has been reviewed or restricted.

Check the Security Level field across the relevant screens, field configuration, and work-item layout. The current overview refers to Work item security on the Layout page; other guidance uses Security Level. Atlassian distinguishes omitting the field from screens from hiding it through field configuration, and notes that previously stored values can remain when a field is hidden later. Do not treat all hidden-field configurations as equivalent. Confirm the actual value and creation behavior instead of relying on a visible form alone.

Associate the Scheme and Update One Dummy Bug

For the selected company-managed project, open Space settings, then Work items and Security. The documented Actions menu offers Select a scheme for a first association or Use a different scheme for a replacement. Choose the scheme and continue. When changing schemes, review the mapping of existing restrictions to levels in the new scheme. Selecting None removes restrictions; it is not a harmless way to dismiss an unfamiliar mapping.

For an individual existing dummy bug, confirm that the acting account has the required Set Work Item Security permission and is included in the target level. Atlassian’s current view guide describes Set Security level next to Watchers; its Cloud update knowledge base describes the padlock icon. Use the control documented for the tenant’s current view, select the intended level, and confirm the displayed selection. These are documentation-backed instructions, not an account of a screen tested here.

Treat bulk restriction as a later, separately approved task. The Cloud knowledge base documents searching for records, choosing Bulk change work items, selecting Edit work items, and updating Security level. Before using that route, verify the actor’s required bulk permissions and the exact selected population under current bulk-edit guidance. Do not begin with every bug: first reconcile the existing-record inventory, intended audience, and dummy-record results. Creating a default or seeing a padlock is insufficient evidence for a bulk rollout.

Predict Access With a Frozen Fictional Policy

Access Policy v1 fixes the assumptions for the following matrix. The names, role, projects, and bug are invented. Allowed, Denied, Unknown, and Blocked are local teaching labels, not Jira statuses or observed permission-test results.

The modeled scope is the paid, company-managed Jira Cloud space ART and the dummy bug ART-42, Synthetic color token mismatch. The bug already has the explicit security level Sensitive defect review. All accounts are active site users; no other native visibility restrictions are modeled. Browse spaces is granted to Avery, Blair, Drew, and Ellis; it is denied to Casey and unknown for Frankie. Sensitive defect review includes only the Defect reviewers role. Its members are Avery, Casey, Ellis, and Frankie. Set Work Item Security is granted only to Drew and Ellis. Drew is a Jira administrator but is not included in the selected level.

Native visibility is Allowed only if Browse spaces and selected-level membership are both true; it is Denied if either is false, otherwise Unknown. A permission grant is a policy input, not an observed access check. App execution grants and external-copy access are unknown for every persona. No actor is authorized to execute an app or change Jira in this exercise. Public Review has no security scheme, with Browse spaces granted to Blair. Restricted Review has a security scheme, but its default level and membership are unknown. Validation requires approved dummy-record checks by the intended viewer, denied viewer, and security member without Browse; the data owner must approve the actual results before any rollout. None of those accounts or approvals is available here.

Persona	Browse Spaces	Member of Sensitive Defect Review	Set Work Item Security	Native Visibility Prediction
Avery	Yes	Yes	No	Allowed, unexecuted
Blair	Yes	No	No	Denied, unexecuted
Casey	No	Yes	No	Denied, unexecuted
Drew, Jira administrator	Yes	No	Yes	Denied, unexecuted
Ellis	Yes	Yes	Yes	Allowed, unexecuted
Frankie	Unknown	Yes	No	Unknown, unexecuted

Avery satisfies both viewing conditions without being allowed to set security. Blair lacks membership, while Casey lacks Browse, so each fails a different part of the conjunction. Drew’s administrative position and Set permission do not change the frozen membership facts. Ellis satisfies the viewing conditions and has a separate Set grant, but no edit has been performed. Frankie remains Unknown because membership cannot resolve missing Browse information.

The matrix predicts only native visibility within its stated scope. It does not certify the configuration. Actual validation is Blocked because the approved accounts and data-owner acceptance are unavailable. Do not turn a consistent policy table into a green access-test report.

Verify Intended and Denied Viewers Before Rollout

An authorized team should translate the predictions into controlled checks using a harmless dummy bug and approved account access. Define the record, project, selected level, role membership, account identity, and expected result before checking. The person configuring the scheme should not substitute their own administrator session for the intended and denied viewers.

1. Confirm that the dummy record carries the intended security level and that its project uses the intended scheme. Review the actual Browse grant and effective membership for each approved viewer.
2. Have the intended viewer open that exact dummy record through an approved session. Record the observed result separately from the expected Allowed prediction. Permission assignment alone does not complete this check.
3. Have an approved viewer with Browse but without level membership try the same record. The expected result is denied access. Do not share confidential content or use another person’s credentials to perform the check.
4. Check the complementary case with an approved level member who lacks Browse. That viewer must not gain record access merely through membership. Where an approved account is unavailable, retain Blocked rather than inventing a pass.
5. Compare all observations with the intended policy and obtain the data owner’s acceptance before expanding to real records. Any unexpected access, missing intended access, unknown configuration, or unavailable approved check keeps rollout on hold.

Keep the check record specific enough to repeat after a membership or scheme change. Include the actual record identity, relevant configuration state, viewer identity, time, expected result, and observation. If a denied viewer can open it, stop the rollout and investigate the effective grants. If an intended viewer cannot open it, inspect both Browse and level membership before granting broader access to make the symptom disappear.

Recheck Security Before and After Moving a Bug

Moving a restricted bug is a new visibility decision. Atlassian’s current security-scheme overview says a work item moved between spaces receives the destination’s default security level. If the destination has no security scheme, the record is visible to anyone with access to that space. Do not assume that a source level travels with the bug because another project contains a level with the same name.

Access Policy v1 makes the consequence concrete. In Public Review, Blair has Browse and there is no security scheme. The predicted native visibility is therefore Allowed, which conflicts with the source policy’s exclusion of Blair. The policy decision is Hold, not approval to move the bug. In Restricted Review, the default level and its membership are unknown. The prediction remains Unknown and the policy decision is also Hold.

Before an approved move, inspect the destination scheme, default, intended audience, and relevant permissions. Move work items and Create work items in the destination are distinct documented move prerequisites; they do not establish that the resulting audience is acceptable. A destination without a verified suitable default, including an unresolved no-default configuration, needs review rather than an assumed confidentiality guarantee.

Use a controlled dummy move first when the authorized change plan permits it. Afterward, inspect the destination record’s actual level and repeat the intended and denied viewer checks there. An administrator completing the move successfully does not prove that the destination visibility is correct. No move, reset, or post-move observation has been performed for this example.

Keep App Execution and External Copies Outside the Visibility Claim

A tester may be able to open a bug while lacking permission to execute a test run. An installed app may use its own roles, data stores, or account context. Verify the particular app’s documented authorization model and approved execution account separately; do not infer run rights from the persona matrix. All app execution access remains unknown in Access Policy v1.

Apply the same caution to copied evidence. A native security-level change is not evidence of encryption, recall of earlier copies, or an access change in email, exports, chat, screenshots, or an external attachment store. Review those destinations and their owners separately. Even within Jira, Atlassian documents aggregated-data permissions that can expose some information despite work-level restrictions, so avoid promising that every related fact becomes invisible.

The practical next step is a data-owner-reviewed audience and a controlled dummy-record validation plan, followed by actual approved checks. Keep real confidential defect content out of the exercise until that evidence exists. Here, the design remains unexecuted and rollout remains Blocked; the article supplies a procedure and explicit predictions, not an accepted security configuration.