Description

The following document describes how user Personal Data (PD) may be accessible in JIRA by the individual, JIRA administrators, authenticated users, and non-authenticated users (if the JIRA instance is publicly accessible).

There can be multiple sources of PD in JIRA, such as a user profile, issues/comments etc. For a more comprehensive list please refer to Jira: Right to erasure

Version Compatibility

The information on this page relates to JIRA Core and JIRA Software 7.0 and later, and JIRA Service Desk 3.0 and later.

JIRA mode

JIRA can operate in two modes:

• Private - Only administrators can provide new users with access to an instance.
• Public - Anyone can access the instance upon sign up.

Public means that anyone can sign-up and create an account, and by doing so they potentially gain the ability to browse user profiles, depending on how the JIRA permission schemes are set. To check and/or disable public mode, follow this guide: Configuring Jira application options. 

Access for "Anyone" group

JIRA can be configured in such way that "Anyone" can access and browse issues and projects, and create issues with the browse user permission (which means they can see a list of the current JIRA users). An administrator would need to check for any occurrence of a permission granted to the "Anyone" group. Review the following documentation for more information on:

• Global permissions - Managing global permissions
• Permission schemes - Configuring permissions
• Permission schemes REST API - API docs

Shared filters

Similar to the "Anyone" group described above, a filter can be shared with publicly when the filter owner decides to add a share of "Public". This means the filter is available to users who are not logged in, and is accessible publicly. For more information on public filters, review this guide: Anonymous users able to see shared filters, dashboards, or project issues in Jira.

Third party

JIRA is extremely flexible and has a large ecosystem of integrations provided by third party vendors. JIRA administrator may need to pin-point any plugins, add-ons or integrations that are processing PD or can disclose PD to other systems, for example:

• Webhooks - any information regarding an issue (including PD) can be sent in the webhook request, you should check how the recipient of this information is processing it.
• Plugins and add-ons - think about any integrations on the instance e.g. the HipChat plugin may be displaying some issue information (possibly containing PD) to some HipChat rooms.
• Workflow post-functions, custom scripts, any sort of additional functionality set up to automatically send information elsewhere.

There is currently no way to automatically list these areas.

Emails

Users have little control over the emails that they're sent by JIRA, or that they generate to other users as a result of their actions, for example adding a comment to an issue, or transitioning an issue between statuses. JIRA administrators have full control over the notification schemes, which control notifications and emails, and for more information on notification schemes, review this guide: Configuring email notifications.

Restrict viewing profiles

There is no way to restrict a user who is logged in from viewing another user's profile and the information it contains.

The JIRA administrator may:

• Restrict a user's email address from being displayed on the profile page by using the global property "User email visibility": Configuring Jira application options
• Disable the "Details" web panel on a user's profile page, however the display name and avatar will still be displayed in the page header. This can be done by navigating to the "Atlassian JIRA - Plugins - User Profile Plugin" on your Add-ons page, and disabling it's "custom-user-details" module. This will also remove the user's ability to edit their own profile if you're using JIRA's internal user management.

Restrict viewing issues

JIRA administrators can restrict access to JIRA issues and their associated data by assigning proper permissions to users/groups:

• Configuring permissions

In addition to permission schemes, issue-level security can be set up to further restrict access to some issues:

• Configuring issue-level security

Restrict viewing project data

Project administrators can:

• control access to project details view (along with some global entities)
• maintain components/versions for project
• assign users to project roles

The process of revoking the "Administer project" permission can depend on the configuration of the permission scheme used by project, but it's usually performed through project roles.

Disable the history tab

The Issue history tab can contain information about changes on an issues fields and custom fields, and these changes can contain PD. For information on how to disable this tab, please review How to hide the "History" tab in the issue panel.

JIRA Service Desk specific information

User profiles in JIRA Service Desk are stored and categorised by JIRA, and can be split across two roles:

• Customers / Help Seekers - During customer creation, a user is created in JIRA with customer privileges.
• Agents - During agent creation, a user is created and then elevated to agent.

Access to PD can be restricted via the permission scheme and user roles in JIRA. 

By design, project administrators can restrict share and manager fields to their organisation in JIRA Service Desk project settings. For more information, review this guide: Set up customer permissions.

There are several areas in JIRA Service Desk that may contain PD if it's been inadvertently added in the form of free text. These areas are: 

Queues

Queues are essentially JQL searches. The queue name or the JQL search could contain personal data. Queues are set up and maintained by project administrators, and can be viewed by agents and JIRA users, but not by customers.

Service Level Agreements (SLAs)

Access to SLA data is restricted based on the user's roles/permission level. By default, only project admins can configure SLAs and Calendars. If there is any personal data in the text fields, this will be viewable by agents. Project administrators are also allowed to import SLAs from another project, and if there is any personal data in the original SLA, the information will be imported to the new SLA.

Request types

Request types have various text fields where customers and agents can add personal data. Request types are configured by JIRA administrators and project administrators, and the configuration could contain PD if it's added.

Invite and General Emails

Email content and data is stored for email batching and sending emails to customers. Sent emails are purged after 30 days. There are free text fields that may contain PD in notification templates and emails stored. When a user is invited to JIRA, we store the email address of the invited user and the username of inviter. The username of a user that changes the supported language for translated customer notifications is also stored.

Automation

There are some free text fields such as name, description, comment contains matcher etc. that can contain personal data. Only project administrators can see the usernames/emails of users involved in automation rules. The user doesn't have control over their PD if it's used in automation modules.

Canned responses

Canned responses are not available for customer use, only for agent and project administrator use. However, once a Canned Response is used by adding it to a comment, it is treated as any other comment content and can be viewed by any user who has access to comments. An agent who creates a Canned Response doesn't have any control over who can see that Canned Response since it is automatically available to all agents. There is no permission schema in place for Canned Responses. 

Approvals

Access to the approver list is automatically given to anyone who has access to a request, both on the agent view and the customer portal. It is not possible to restrict access to the approvers list, other than restricting access to the request itself.

Knowledge Base integration with Confluence

By design, JIRA Service Desk preserves the permission or restriction level of Confluence pages. When an anonymous or unlicensed user from the customer portal views a knowledge base article hosted in Confluence, and if the proper permissions are in place, the user profile macro will not be rendered. Actual data about the article (title, content, author) is stored in Confluence.

Project administrators are the only type of user that has access to fields that may potentially hold PD. There is no way to restrict access to a specific user's personal data since data is stored in a non-structured way/free text form.

Limitations

• There is no functionality that allows restricting access to a single profile.

Additional notes

If you are a server or data center customer, Atlassian does not access, store, or otherwise process the personal data you choose to store within the products. For information about personal data Atlassian processes, see our Privacy Policy.