1. Content of the newsletter

This newsletter describes the Data Privacy improvements that have been implemented in Jira to support compliance with the GDPR (General Data Protection Regulation).

Some of the changes have been released earlier, but updated functionality have recently been introduced. This newsletter/guide covers all functionality related to handling personal information data in JIRA – not only the recent changes.

2. Privacy considerations

Jira is designed as an activity management system and should be used as such. Therefore, minimize the personal information in Jira, and be extra aware in situations, where it is necessary to store personal information. In such cases, ensure to restrict access to the personal information as much as possible.

IMPORTANT: For all engagements/JIRA projects, please keep in mind that the data processor agreement with the client must define for how long issues should be kept in the JIRA system before being deleted, and that you need to handle data accordingly



Figure 1

2.1 Restricting access at Issue level

The following Project Role can be used to restrict access to specific Issues:


This role is added to the “Users and roles” in Project Admin, and is primarily meant to be used for external users – see description below.

The following two Security Levels are to restrict access to specific Issues:

  • “Sensitive information – In Progress” and
  • “Sensitive information – Closed”

”Sensitive information – In Progress”
This security level is for open Issues containing personal data.
Issues with this security level are accessible by:

  • reporter of the ticket,
  • all CGI users in the Jira project team, and
  • users with the Project role:“SENSITIVE INFORMATION – ACCESS”.

This way, all CGI users in the project can contribute to solving the issue in question, and it is possible for specific, named external users to have access. This must be agreed with the Cli-ent.

”Sensitive information - Closed”
This security level is used for closed Issues containing personal data. If possible, remove the personal data, when the issue is resolved.
Issues with this security level are accessible by:

  • all users in the Project Admin group, and
  • users with the Project role: “SENSITIVE INFORMATION – ACCESS”.

2.2 Where to store the personal data in JIRA

There are two places to store personal information in JIRA:

  • the field “Sensitive information” as shown in Figure 1, or
  • enter the personal information data in a comment.

Using “Sensitive information” field: Using this field, you must be aware that all personal information data will remain in Jira, until the issue is deleted. Even if the personal data is removed from the field, the History log in Jira will retain the entered personal information data, until the issue is deleted.

Using “Comment”: There is no History log for comments. Hence all personal information data stored in a comment, will disappear from Jira, when the comment is deleted.

It will depend on an individual assessment for each engagement, which will be the best way to store personal information data. One factor to consider, is whether JIRA issues could be delet-ed right after they are closed, or if the client and/or project need to have them stored for a longer period.

If using comments, it is also possible to restrict a comment to be viewable only by users with project role “Sensitive information – Access”.

3. Closing Issues

When closing Issues containing personal data, delete the personal data before closing.

If the personal information data was stored in a Comment, just delete the comment. If the personal information was stored anywhere else, there will still be a History log entry containing the personal data information. In such cases, restrict access to the closed Issue, as described in section 2.1.

If you cannot delete the personal information data due to client requirements, restrict the access as described in section 2.1.

4. Deleting Issues

As a rule, JIRA issues with personal information data must be deleted as soon as:

  • they are closed, and
  • CGI obligations regarding the issues (reporting, statistics, invoicing etc) are over

4.1 Who can delete Issues?

By default, it is only the project lead, who is able to delete issues in JIRA. The project lead can delegate this right to other users, This delegation can be requested via a support ticket to JIRA 1. Line support.

However, if agreed with the client – and documented in the Data Processor Agreement – CGI are entitled to keep the data in JIRA for the period agreed with the client.

5. Managing old Issues

For engagements where old Issues are stored as agreed with client, it is important to ensure that access to any personal information data is restricted as much as possible (the least privi-lege principle).

If possible, delete the personal information from such Issues or restrict access, same guide-lines as when closing a new Issue (see section 3).

In projects with many old Issues, where the process of going through them and checking individually for personal information data will be extremely time-consuming, the guideline is to restrict access to all potential Issues with personal information data by setting Security Level to “Sensitive Information – Closed”. This will not require, that the Issue is re-opened and there-fore does not impact the statistics data.

5.1 How to identify potential Issues

In order to help engagements identify potential Issues with personal information data, a tool in CGI.NET is being developed. This will assist in listing Issues where CPR-numbers are identified. The tool is currently being tested, and more information about this will follow . The tool will also support the ability to bulk-change the security level to “Sensitive Information – Closed”.

Another way of identifying potential Issues with personal data, can be identifying Issues with attachments, where attachments may have been used for storing personal data. To find a list of all issues with attachments, you can use the below JQL query (replace “ITKO Projects” with your project name)