Data Masking in Jira: How to Mask, Redact and Anonymize Issue Fields
Last reviewed: 18 August 2026.
Jira has no built-in field masking. There are three ways to achieve it, and they are not interchangeable. You can restrict who sees a field using issue security levels and field configurations, which hides data rather than removing it. You can use a field-level app that masks values at entry, which protects new data going forward. Or you can scan and remediate data already stored in issues, comments, attachments and issue history. The right choice depends entirely on whether the sensitive data is already in Jira. If it is, only the third approach removes it.
What Jira can and cannot do natively
Jira offers two relevant native controls, and it is worth being precise about what they actually do.
Issue security levels restrict which users can see an entire issue. Field configurations can hide a field from a screen. Both are access controls. In both cases the data remains stored in the database exactly as entered, and it remains visible to anyone with sufficient permission, to administrators, in exports, and in the audit trail.
That distinction matters for compliance. Hiding a field from a screen does not mean the personal data has been removed, and it does not answer a right-to-erasure request. If your reason for masking is regulatory rather than merely tidy, access control alone will not satisfy it.
The three approaches
1. Native permissions and field configurations
Good for: limiting day-to-day visibility of a field to a smaller group. Free, built in, no app required.
Not good for: anything compliance-driven. The data is still stored, still exportable, still in issue history.
2. Field-level masking apps
Apps such as Secure Fields and Protected Fields mask or encrypt values at the point of entry, so sensitive data is never stored in the clear in that field.
Good for: preventing new exposure in a specific, known field. If you have one custom field that collects something sensitive and you want it protected from now on, this is the right and simplest tool.
Not good for: data that is already there. Entry-time masking is forward-looking by design. It does nothing about the eighteen months of issues, comments and history behind it, and it only protects the fields you configured, not free text where people actually paste things.
3. Scan and remediate
Tools in this category search existing content by pattern and then redact, replace or anonymize what they find.
Good for: cleaning up what is already stored, answering erasure and access requests, and finding sensitive data in the places nobody thought to protect.
Not good for: preventing entry. A scanner finds a credit card number after somebody has pasted it into a comment, not before.
The part teams underestimate: issue history
Jira records every change to an issue. Edit a description to remove a customer’s phone number and the previous value remains in the issue history, visible to anyone who can view the issue.
This is the single most common gap in Jira data-masking projects. Teams mask a field, clean the current values, produce a report, and remain exposed because the original values are still in the change log. Any approach that claims to remove personal data from Jira has to address history explicitly, and it is a fair question to put to any vendor.
The same applies to attachments. A masked field does not help when the sensitive data arrived as a spreadsheet attached to the ticket.
Most regulated teams need two of the three
In practice the common pattern is a field-level app on the specific fields that routinely collect sensitive data, plus a scanning tool for everything else: comments, free-text descriptions, attachments and history. The two solve opposite halves of the problem, and neither substitutes for the other.
If you have to choose one first, work out which risk is live. If sensitive data is already in your instance and you have a regulatory obligation attached to it, start with remediation. If your instance is clean and you are designing a new intake process, start with field-level protection.
How Data Protection Toolkit handles it
Data Protection Toolkit sits in the third category. It scans Jira issues, comments, custom fields, attachments and issue history against 62 built-in detection patterns covering 27 countries, including 32 national identification formats and 20 country-specific phone formats, plus credit cards, IBANs, email addresses and IP addresses.
You can add your own RegEx rules for internal identifiers such as customer or contract numbers, and Actonic will write, test and hand over custom patterns free of charge if you would rather describe the requirement than write the expression.
Matches can then be redacted, replaced, commented on or reported in bulk, and scans can run on a schedule so exposure is caught as it appears rather than at audit time. The same app handles user and project anonymization for right-to-erasure and data subject access requests. It runs on Jira Cloud and Jira Data Center, and on Cloud the calculation happens in the user’s browser rather than on Actonic infrastructure.
To be clear about the boundary: Data Protection Toolkit does not mask values at entry. If your requirement is that a particular custom field must never store a readable value in the first place, a field-level app is the correct tool and the two are complementary.
Frequently asked questions
Does Jira have built-in data masking?
No. Jira has issue security levels and field configurations, which control who can see a field. The underlying data is still stored and still appears in exports and issue history. There is no native pattern-based masking or redaction.
How do I mask a custom field in Jira?
Natively you can hide it from a screen or restrict the issue, but the value remains stored. To genuinely mask it at entry you need a field-level app. To remove values already stored in it you need a scanning and remediation tool.
Does masking a field remove the data from issue history?
No, and this is the most common misunderstanding. Historical values remain in the change log. Removing them requires a tool that scans and remediates history specifically.
Is hiding a field enough for GDPR?
Generally not. GDPR obligations such as the right to erasure concern whether personal data is held, not merely who can see it. Restricting visibility while continuing to store the data does not discharge an erasure request. Take your own legal advice on your specific situation.
What about data in attachments?
Field-level masking does not apply to attachments at all. If sensitive data arrives as a file, you need a tool that scans attachment contents.
Can I mask data in bulk across existing issues?
Not with native Jira and not with entry-time masking apps. Bulk remediation of existing issues requires a scanning tool that can apply redaction or replacement across many issues at once.
In short
Ask one question first: is the sensitive data already in Jira? If yes, you need to find and remove it, and hiding a field will not do. If no, and you want to keep it out of a specific field, entry-time masking is simpler and cheaper. Most teams under real regulatory pressure end up doing both.
See Data Protection Toolkit for Jira or compare the options in our Jira data protection apps comparison.
Request