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. 

Description

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
location
Accessible Via Purpose
1 Issue Assignee and Reporter Fields Database
  • UI
  • REST API
  • Database
  • Tracks the initial reporter of an issue and the current assignee.
  • These fields contain the username, display name and email address of users.
2

Issue Summaries, Descriptions, and Comments


Database
  • UI
  • REST API
  • Database
  • These are free-text fields that users can populate with any arbitrary information, including personal data.
  • Users can '@mention' other users in the system to notify them, which will reveal the display names for those users.
3 Issue Worklogs Database
  • UI
  • REST API
  • Database
  • Worklog descriptions are free-text fields intended for users to annotate their work.
  • Users can populate the worklog description field with any arbitrary information, including personal data.
  • More information in Logging work on issues
4 Issue History Database
  • UI
  • REST API
  • Database
  • Tracks changes to fields and who made them.
5 Issue Activity Database
  • UI
  • Database
  • Tracks changes to fields and who made them.
  • Includes comments, which may contain further personal data.
6 Custom Fields Database
  • UI
  • REST API
  • Database
  • Text fields and third-party fields can contain any arbitrary information, including personal data.
  • User picker fields can contain usernames and full names.
  • Custom field data can be included in Jira's index.
7 Saved JQL Filters Database
  • UI
  • REST API
  • Database
8 Lucene Documents Filesystem
  • Filesystem
  • When an issue is created or modified in JIRA, a Lucene document is created that contains the contents from the fields from that issue.
  • Lucene documents are added to Jira's index on a per-issue basis during a reindexing operating.
  • More information in JIRA Indexing FAQ.
9 Attachments Filesystem
  • UI
  • REST API
  • Filesystem
  • Attachments are documents, images, or screenshots that are attached to issues.
  • Attachments may contain any arbitrary information, including personal data.
  • More information in Attaching files and screenshots to issues.
10

Application Logs

  • atlassian-jira.log
  • atlassian-jira-security.log
  • access_log
  • catalina.out
Filesystem
  • Filesystem
  • Logs various aspects of JIRA operations for troubleshooting purposes.
  • May contain any arbitrary information, including user information.
  • More information in Logging and profiling
11 Audit Logs Database
  • UI
  • REST API
  • Database
12 Backups Filesystem
  • Filesystem
  • Contains the entire contents of the JIRA database for archival purposes.
  • Backups contain entire suite of personal data provided to Jira.
13 Support Zips Filesystem
  • Filesystem
  • Collects configuration information from JIRA and various logs for transmission to Atlassian Support.
  • Logs may contain personal data.
  • More information in Create a Support Zip.
14 Emails

Database

Mail Server

Client Systems

  • Database
  • External Systems
  • Notifications to users about changes to issues, including comment and status changes.
  • Comments are free text fields and may include any arbitrary information, including personal data.
  • Emails are stored internally in Jira, and contents will be stored on email server and/or email clients.
15 Webhooks

Database

External Systems

  • Database
  • HTTP POSTs to external URLs containing details of issue changes, depending on configuration.
  • More Information in Webhooks.
16 Avatars

Filesystem

External Systems (Gravatar)

  • Filesystem
  • External Systems
  • Images selected by users to represent themselves in Jira.
  • In the case of Gravatars, these images may be stored in external systems.
17 User Profile Database
  • Database
  • Stores user details including username, full name, email address, and avatar.
  • User accounts can be created by mail handlers when "Create User" checkbox is checked during incoming mail handler configuration Creating issues and comments from email
18 Application Cache

Memory

Filesystem

  • Filesystem
  • Memory
  • Store data in memory to speed-up lookups (no expensive DB access needed)
19 Mentions

Database

Email

  • Database
  • Effective collaboration between users (sending emails to mentioned users)
20 Plugins/integrations Database/filesystem/Other
  • UI
  • REST API
  • Different type of plugins - any functionality can be implemented in plugin.
21 Group names Database/External directory
  • UI
  • REST API
  • Used for categorizing users. There is possibility to store PD in group names if eg. group name contains reference to religion/race/gender and there are some uses assigned to that group.
22 Dashboards Database
  • UI
  • Could contain personal data e.g. report grouped by some user field in issue eg. assignee
23 JIRA reports Database
  • UI
  • Could contain persoanl data e.g. report grouped by some user field in issue eg. assignee
24 User key Database
  • REST API
  • Could contain personal data
  • System entry with a unique value representing the user, and is based on their original login details. The user key is only accessible in the system and through APIs, and cannot be altered.

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
  • UI
  • Database
  • Provide a free-text field that agents can populate with any arbitrary information, including personal data.
  • Stores:
    • users that have created/updated canned response
    • canned response title and text
    • canned response usage (e.g. which user have used canned response)
    • audit trace
    • when variables are used in canned responses (e.g. mentioning a reporter), these are stored as free-text in our database

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
  • UI
  • Database
  • REST API
  • A way to group users into organizations.
  • We store the members of an organization and the name of the organization.
3 Approvals 3.2.x and above
  • UI
  • Database
  • REST API
  • Tracks and explicitly provides the approvers required for incoming requests.

If a specific request type has the approval process enabled, requestors can:

  • Select one or multiple members in the organisation through a drop-down menu. This will reveal their display names and emails.
4 Automation 3.0.0 and above
  • UI
  • Database
  • Tracks who made the rule, and if the THEN handler involves alerting another user, we also store who this automation rule applies to (e.g. alert a user on THEN handler).
  • Stores:
    • executor user key
    • user keys and emails of users part of a rule (e.g. alerting a user on THEN handler)
    • name and description on free textfield that may contain personal information
    • JQL and other matchers used in querying and executing automation
5 Customer portal request view
  • UI
  • Database
  • Allow users to subscribe request via customer portal, which store the user key (e.g. this user has subscribed to this request).

No sensitive data is logged as part of adding/removing/fetching subscription information.

6 Customer satisfaction feedback
  • UI
  • Database
  • REST API
  • Allow help seekers to evaluate the quality of the service via a 5 star rating system.
  • We store a token that is later sent via email to the requester, and we also store comments made by the requestor. The comment is free text and may contain PD if the requestor adds it.
7 Customer notifications and invite emails
  • UI
  • Database
  • 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, we store the email address of the invitee and the username of the inviter.
  • We store the username of the user that changed the supported languages for translated customer notifications.
8 Knowledge base integration
  • UI
  • Database
  • A way to integrate JIRA Service Desk with Confluence to give help seekers access to knowledge base articles.
  • We store the application link name, space URLs, labels of Confluence pages, statistics about knowledge base search and usage (e.g. how many times being viewed), and whether it's helpful or not.
9 Queues
  • UI
  • Database
  • REST API
  • Store queue name and this may contain PD.
10 JIRA Service Desk Reports
  • UI
  • Database
  • Store name of report, or the label of series.
11 Request channels
  • UI
  • Database
  • When your customers send a request through your support email, we automatically create an account for that customer.
12 Request type
  • UI
  • Database
  • REST API
  • Similar to issue type in JIRA, but conceptually different.
  • Store configurations about the request type - name, descriptions, general configurations.
13 Service Level Agreements (SLAs)
  • UI
  • Database
  • REST API
  • Service level agreement (SLAs)
  • Store configurations about SLAs, description, calendar name, holiday names, audit SLA data, SLA breaches, SLA goals (JQL queries that define goals). This could all contain PD.

Workaround

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.

  1. Select User Management.
  2. Find the user in the user list using the filter form at the top of the page.
  3. Click on user Full name in the "Full name" column.
  4. Store data from "Account information" section for later usage:
    1. Username
    2. Full name
    3. Email
  5. Obtain user "user_key"
    1. 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: //localhost:2990/jira/rest/api/latest/user?username=example_username
      {
      "self" : "http://localhost:2990/jira/rest/api/2/user?username=example_username" ,
      "key" : "user_key" ,
      "name" : "example_username" ,
      "emailAddress" : "johndoe@example.com" ,
      "avatarUrls" :{ "48x48" : "" , "16x16" : "" },
      "displayName" : "John Doe" ,
      "active" : true ,
      "timeZone" : "Australia/Sydney" ,
      "locale" : "en_AU" ,
      "groups" :{ "size" : 2 , "items" :[]},
      "applicationRoles" :{ "size" : 2 , "items" :[]},
      "expand" : "groups,applicationRoles"
      }

      In  this example user key has value  "user_key"

    2. Using an SQL query

      SELECT user_key FROM app_user WHERE lower_user_name = LOWER( '[username]' )

  6. Check data in user properties:

    1. 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.

  1. Go to issue search and search for sensitive data. From top menu, choose Issues > Search for issues.
  2. Click Advanced.
  3. Type JQL: "text ~ 'clause to search'" and click the search icon. It should search in: comments, description, summary, environment, worklogs + text searchable custom fields.
  4. 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 applications.

Handling PD in other entries

Dealing with free-text:

  1. You have to modify the provided SQL file - replace <OLD_VALUE> with the PD that you are searching for.

  2. 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.

    1. Use these SQL scripts for JIRA Core and JIRA Software:

      Scripts

      select oracle • mysql • postgresql • mssql

    2. 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:

      Scripts

      SELECT oracle • mysql • postgresql • mssql

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.

Limitations

  • 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.

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.

Last modified on May 15, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.