JIRA: Right of access by the data subject
Under Article 15 of the GDPR, individuals have the right to understand what personal data is being processed about them and the lawfulness of the processing. The GDPR requires that you take reasonable steps to provide this information to the individual, where requested. Whether or not you need to provide the individual with access to personal data stored within the product and the lawfulness of the processing will vary on a case-by-case basis, and is a determination you should always make with the assistance of legal counsel. Once you have determined you have an obligation to provide an individual with access to personal data processed through the product, we have provided the following instructions on how to do so within certain Atlassian products.
Personal Data (PD) for a specific user can be spread across multiple components of JIRA. In this article, we'll detail how to locate and access this data, and we'll also provide workarounds for you, to ensure that you can access all personal data for a specific user if required.
JIRA Core and JIRA Software
Below is a list of key data held by JIRA Software and/or JIRA Core versions 7.0 and above, in a default configuration:
|Where JIRA can store PD||Storage|
|1||Issue Assignee and Reporter Fields||Database|
Issue Summaries, Descriptions, and Comments
|7||Saved JQL Filters||Database|
External Systems (Gravatar)
|20||Plugins / integrations||Database / file system / Other|
|21||Group names||Database / External directory|
|25||Data pipeline exports||File system|
JIRA Service Desk
In a default JIRA Service Desk configuration, the following data is stored in database listed below:
|Where JSD can store personal data||Version compatibility||Accessible via||Purpose|
|1||Canned responses||3.7.x and above|
No personal data is logged in the file system for canned responses.
You can view this page for more details on canned responses.
|2||Organization||3.3.x and above|
|3||Approvals||3.2.x and above|
If a specific request type has the approval process enabled, requestors can:
|4||Automation||3.0.0 and above|
|5||Customer portal request view|
No sensitive data is logged as part of adding/removing/fetching subscription information.
|6||Customer satisfaction feedback|
|7||Customer notifications and invite emails|
|8||Knowledge base integration|
|10||JIRA Service Desk Reports|
|13||Service Level Agreements (SLAs)|
Handling "structured" PD
Obtain PD from a User profile
Before you begin
You must have the JIRA Administrator or JIRA System Administrator global permission to be able to manage users in JIRA applications.
- Select > User Management.
- Find the user in the user list using the filter form at the top of the page.
- Click on user Full name in the "Full name" column.
- Store data from "Account information" section for later usage:
- Full name
- Obtain user "user_key"
Using REST API https://docs.atlassian.com/software/jira/docs/api/REST/latest/#api/2/user-getUser and obtain "key" from the response
curl -u admin:admin http:
example user key has value
Using an SQL query
SELECT user_key FROM app_user WHERE lower_user_name = LOWER(
Check data in user properties:
- Choose Actions > Edit Properties. The Edit User Properties screen will be displayed. Check if any PD is defined there.
Handling "free-text" PD
Handling PD in JIRA issues
You'll only get search results for entities you have the right to view. Make sure you have full admin rights is you want to scan for all instances of PD.
There may be some fields that you don't have access to. If "none" is selected for custom field Search Templates, then JQL searching will omit this field. Such fields have limited processing and nobody will be able to perform the search by this field's value.
- Go to issue search and search for sensitive data. From top menu, choose Issues > Search for issues.
- Click Advanced.
- Type JQL: "text ~ 'clause to search'" and click the search icon. It should search in: comments, description, summary, environment, worklogs + text searchable custom fields.
- Check or update the required data.
Handling PD in the audit log
Go to the audit log page, and search for PD.
For more information, please view Auditing in Jira.
Handling PD in other entries
Dealing with free-text:
You have to modify the provided SQL file - replace <OLD_VALUE> with the PD that you are searching for.
Execute the "Select" script from the SQL file manually table by table, each table description should contain additional information on the purpose of the table. We recommend (if possible) to view and amend data using the UI.
Use these SQL scripts for JIRA Core and JIRA Software:
If you have JIRA Service Desk, you'll need to run the JIRA Core scripts above, and then run these JIRA Service Desk specific SQL scripts:
Handling PD in Logs
As an administrator, you would need to manually search each log as detailed on the JIRA Server: Right to erasure page for PD.
Handling PD in backups
JIRA can generate backups of it's data, and this is performed by the administrator. How these backups and the data they contain is governed is up to each administrator and their respective organizations to decide.
- If you have stored PD inside attachments, this article will not help surface that PD as we have no way of reading what is stored in each attachment.
- Access to the database is required to run any SQL scripts.
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.