Jira issues to exclude before a data license: security, HR and legal

Why does Jira need an exclusion pass?#

Jira needs an exclusion pass because it becomes the catch-all system in most software companies. Alongside bugs, stories and epics, it often holds security reports, HR service requests, legal reviews, access requests and procurement approvals, sometimes in the same instance and occasionally in the same project.

The engineering records are worth licensing: an issue linked to the commits that fixed it and the release that shipped it is a complete problem-to-solution record. The exclusion pass protects the people, legal positions and security details that sit beside that history, and it is far easier to do with filters than by reading issues one by one.

Exclusion checklist by category#

Each category below has a default and a set of signals that help find it, even when it sits outside the project you would expect. Project keys, labels and issue types differ in every instance, so translate the signals into your own names before running any filter.

Work in three passes: projects, then labels and security levels, then text#

Three passes catch most sensitive issues with the least reading. Each pass is a JQL query whose results go on an exclusion list, and the queries themselves become part of the preparation record.

Build the final inclusion filter as the inverse of the exclusions. One JQL detail matters here: a clause such as labels not in a list does not return issues with no labels at all, so write labels is EMPTY OR labels not in, followed by your list. The same applies to components and custom fields.

Plan the export in batches as well. Atlassian supports exporting up to 10,000 work items at a time through the asynchronous CSV export in the Jira Cloud issue navigator and recommends splitting larger sets into JQL batches, for example by created date. Add a date range to the final inclusion filter and run it range by range, so every batch applies the same exclusions.

• 1Pass 1, projects: project in (HR, LEGAL, SEC, FIN, IT) removes whole projects; replace the keys with your own.
• 2Pass 2, security levels: level is not EMPTY finds every issue with an issue security level set.
• 3Pass 2, labels and types: labels in (security, vulnerability, pentest, legal, hr, confidential), plus issue types your team uses for vulnerabilities.
• 4Pass 3, text: text ~ "termination" OR text ~ "subpoena" OR text ~ "lawsuit" OR text ~ "salary", extended with your own terms; read the hits rather than excluding automatically.
• 5Final inclusion filter: project in (your engineering projects) AND level is EMPTY AND (labels is EMPTY OR labels not in (your excluded labels)).

What about restricted comments and hidden fields?#

Restricted comments are the most common gap, because Jira lets a comment be visible only to a group or project role while the issue itself stays open to everyone. A support lead may add contract details or a customer complaint as a restricted comment on an ordinary bug. Depending on the export method and the exporting account's permissions, those comments can either be missing or included without any marker, so check comment visibility explicitly and strip restricted comments by default.

Fields need the same attention. Service management projects add reporter email and organization fields, custom fields may hold customer names, and the change history keeps old values of any field someone edited to remove sensitive text. Export the current values of the fields you need, and leave the change history out unless it adds clear value.

Attachments on issues follow the same logic as help desk attachments. Screenshots, log files and customer exports attached to bugs are excluded by default, and only file types that explain a fault and can be cleaned, such as stack traces, are brought back after review.

Can fixed security bugs ever be included?#

Fixed security bugs can sometimes be included, because the story of how a vulnerability was found, fixed and tested has real value for models that help engineers write secure code. The test is whether including the issue could help anyone attack a current system or embarrass a customer.

Include a security issue only if every condition below holds; otherwise exclude it and record the reason.

Illustrative: an e-commerce platform vendor filters Jira#

Illustrative: a fictional e-commerce platform software company runs Jira Cloud with Jira Service Management. Its instance holds engineering projects, an HR service desk, a legal request queue, a security project and an IT project. Engineering bugs that involve vulnerabilities carry a restricted security level.

The CTO's team excludes the HR, legal and security projects in pass one and every issue with a security level in pass two. The text pass finds offboarding tickets in the IT project that name departing employees, so the whole IT project is excluded. A comment visibility check finds restricted comments from support leads quoting customer contract terms, and they are stripped. The final inclusion filter is saved, and counsel reviews a sample of included issues before the CTO approves the scope.

How SourceX approaches Jira exclusions#

SourceX agrees which projects and record types are in scope during the Rights step of the SourceX five-step transaction, and the supplier's team applies the exclusion filters during Preparation, inside its own environment. Nothing is exported during the fit check, which needs only metadata such as project types and years of history.

The saved JQL filters, the categories excluded and the sample review results are recorded in the privacy record of the SourceX Evidence Packet, so the scope can be explained and reproduced later.