How do you deal with sensitive/PII data that gets added to Jira/Confluence by mistake?

[Emma Phillips]

I was reading about the CareCloud breach, where data belonging to 3.75 million patients was reportedly exposed, including medical records, payment information, addresses and government IDs.

It got me thinking about something that feels easy to overlook in day-to-day work.

People put all kinds of information into Jira and Confluence like customer details, IDs, payment information, logs, credentials, internal documents, attachments, etc. Usually there's no bad intention behind it. Someone is troubleshooting an issue, helping a customer, sharing a log, or just trying to get something done quickly.

But what happens when sensitive data ends up there by mistake?

The problem I see is that you might not even know it's there. A sensitive value could be sitting in an old ticket comment or attachment for years without anyone noticing it.

And by the time someone discovers it, it may have already been accessed, exported, backed up, or picked up by another integration.

So I'm curious — how are you guys actually dealing with this problem?

Do you have anything that regularly checks Jira/Confluence for sensitive data, or is it mainly based on user awareness and permissions?

And when something is found, who is responsible for dealing with it? Do you have a process to remove or redact it, or does it usually become a manual cleanup exercise?

I'm especially interested in how teams handle the old data problem. It's relatively easy to tell people “don't put PII here” — but what about everything that's already sitting in the system?

Would be interested to hear what others are doing here.

[Arsh Sabharwal]

 @Emma Phillips, the old data part is probably the trickiest piece here. Even if you put the right guidelines and controls in place going forward, there’s still a lot of existing data sitting in Jira and it’s not always obvious where PII has ended up, especially in older issues, comments or attachments.

We’ve been working on this from the DLP side with a PII Scanner for Jira & Confluence. It can scan existing Jira and Confluence data for PII and other sensitive information, including attachments, and then flag or redact anything it finds. You can also define your own patterns if there are specific types of data you need to catch.

The idea is less about waiting for someone to report a problem and more about periodically checking the old data and cleaning things up as you go.

Might be worth looking at if the old data part is the main concern.

[Aditya_miniOrange]

Hi @Emma Phillips 

This is a very real concern, especially in Jira and Confluence environments where thousands of issues, pages, comments, and attachments are added every day.

One thing we often overlook is that once sensitive data is stored, the exposure has already started. It may be visible to project members, searchable, included in exports/backups, or passed to connected systems before anyone notices it.

For this reason, we look at DLP as an ongoing process rather than a one-time cleanup:

• Scan continuously or on a schedule to identify newly added and historical sensitive data.
• Detect PII, PHI, PCI data, passwords, API keys, tokens, and other custom patterns using predefined or custom regex rules.
• Remediate the finding by redacting, encrypting, masking, or deleting the sensitive information rather than simply reporting it.
• Scan page history and attachments as well, since sensitive information doesn't necessarily exist only in the current version.
• Maintain centralized reporting and audit logs so security teams can track what was detected and what action was taken.
• For Cloud environments, real-time scanning can help detect sensitive content as Jira issues or Confluence pages are created or updated.

This is the approach we've taken with the miniOrange DLP Sensitive Data Scanners for both Jira and Confluence:

• Jira Data Center: DLP – Sensitive Data Scanner & Cleaner for Jira
• Confluence Data Center: DLP – Sensitive Data Scanner for Confluence
• Jira Cloud: Data – PII Scanner (DLP) for Jira
• Confluence Cloud: Data – PII Scanner (DLP) for Confluence

The goal isn't just “find PII.” It's to shorten the time sensitive data remains exposed: Detect → Review → Remediate → Audit.

Curious how other teams are approaching this — do you run scheduled DLP scans, real-time detection, or a combination of both?

[Natalia_Kovalchuk_SaaSJet_]

Hi @Emma Phillips !

I think it is probably the most difficult aspect to deal with the old data problem; although permissions and user awareness can help stop sensitive data from being added, they won't inform you about what is already concealed in the old Jira work items or comments.

With Jira Cloud, you can try the Security Scanner available in Issue History for Jira (Work Item History) app by SaaSJet. It checks Jira work items and their change history for sensitive data, including credentials, credit card numbers, SSNs, email addresses, phone numbers, IP addresses, and physical addresses.

The results include the findings, the work items where they were found, and the extent of the problem, enabling teams to swiftly determine what requires review or cleaning. Moreover, sensitive values can be masked, and access to the scanner can be restricted to admins or specific groups.

We also intend to include scheduled scanning, which will allow regular checks to be run automatically rather than having them started manually.

This relates to the Jira Cloud aspect of your question and can be particularly useful when you are looking for sensitive data that has been there unnoticed for a long time.