JIRA: Right to restriction of processing
Introduction
Under limited circumstances, Article 18 of the GDPR allows a data subject to request that the processing of their personal data be restricted, rather than entirely deleted. The right of the data subject under Article 18 is highly contextual and you should seek the advice of legal counsel in processing any such request. If you require the ability to restrict processing specific personal data within an Atlassian product, we suggest you follow the instructions set forth in the Right of Rectification article, replacing any personal data elements with elements that do not identify the individual in order to restrict any further processing until the issue is resolved. When and if the processing may resume, you can replace the non-identifying elements with the original personal data elements.
Description
Personal Data (PD) for a specific user can be spread across multiple components of JIRA. We've detailed these components and areas in the JIRA: Right of access by the data subject article.
The recommended approach of limiting access to a user's PD in JIRA is to anonymize their PD, as described in Jira: Right to erasure. If the data can't be anonymized, we've provided some workarounds in this article to help you:
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.
Workarounds
Deleting a user's account
Please follow the instructions to delete a user here: Create, edit, or remove a user.
Affected PD use
- Other users won't be able to mention the user
- The user will not be presented/suggested in user pickers
- The user will not receive email notifications
Limitations
- The user is deleted, and therefore won't be able to log in or use JIRA.
Move issues to a "restricted" project
Issues that contain PD that needs to be restricted can be moved to a project that can only be accessed by a specific group of people. To do this you need to:
- Create the project (see Defining a project).
- Create a new permission scheme and associate it with project. Modify this permission scheme to restrict the "Browse project" permission to the specific group of people you've decided can still view the issues (see Managing project permissions).
- Create a new notification scheme and associate it with the project. Modify this notification scheme so that the email notifications are restricted to the specific group of people you've decided can still view the issues (see Creating a notification scheme and Configuring email notifications).
- Bulk move the issues that you want to restrict to your new project (see Editing multiple issues at the same time).
Affected PD use
- The user's PD visibility is limited to the specific group of people you've decided can still view the issues
- Limited access to issue/PD via REST API.
- No emails sent to other users that may contain PD from the issues.
Limitations
- Moving the issues to the restricted project will affect their usefulness, as few people will be able to interact with them.
Add issue security to issues
Issue level security lets you restrict access to a certain group of people on a per issue basis. Please read Configuring issue-level security for more information on setting up issue level security.
Affected PD use
- The user's PD visibility is limited to the specific group of people you've decided can still view the issues
- Limited access to issue/PD via REST API.
- No emails sent to other users that may contain PD from the issues.
Limitations
- Complicated configuration.
Bulk edit issues
If PD is used in issues in the form of issue assignee or reporter, or the user has been selected in a user-picker custom field, then you can search for these issues and bulk change the relevant fields to another user, or to a dummy user. This prevents user data being displayed on the view issue page, and prevents the user data from being available via REST API responses. Please read Editing multiple issues at the same time for more information on making large changes.
Affected PD use
PD related to assignee/reporter/custom-field user will not be available in the UI or via the REST API.
Limitations
The fact that these changes were made will still be available in the issue's history tab.
Disable history tab
You can disable the history tab so that any PD held here is no longer available. Please read How to hide the "History" tab in the issue panel for more information.
Affected PD use
- PD in the issue history will no longer be available.
Limitations
- Issue history will not be available for the entire JIRA instance, and therefore all issues.
Additional notes
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.
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.