JIRA: Data protection by design and by default
Article 25 of the GDPR sets forth the principle of data protection by design and by default. This is a broad principle with varying meaning and application depending on the context and type of personal data being processed. This principle is unique to each organization, and should always be evaluated with the assistance of legal counsel to determine all efforts required to comply. These efforts may include ensuring certain third party applications you use to process personal data are configured to default to the most privacy-friendly settings available whenever personal data is input. Below is a summary of relevant settings and configurations available through certain Atlassian products, and a discussion of any limitations.
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
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 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
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 server.
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.
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:
In addition to permission schemes, issue-level security can be set up to further restrict access to some issues:
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.
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 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 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.
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 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.
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.
- There is no functionality that allows restricting access to a single profile.
There may be limitations based on your product version.
Note, the above-related GDPR workaround has been optimized for the latest version of this product. If you are running on a legacy version of the product, the efficacy of the workaround may be limited. Please consider upgrading to the latest product version to optimize the workarounds available under this article.
Third-party add-ons may store personal data in their own database tables or on the filesystem.
The above article in support of your GDPR compliance efforts applies only to personal data stored within the Atlassian server and data center products. To the extent you have installed third-party add-ons within your server or data center environment, you will need to contact that third-party add-on provider to understand what personal data from your server or data center environment they may access, transfer or otherwise process and how they will support your GDPR compliance efforts.