Security Scanner View

Security Scanner View (PII & DLP) helps teams detect sensitive data in Jira work items and their change history. It scans current content and past changes to highlight potential risks in one clear view.

This makes it easier for companies to reduce data exposure, stay compliant, and keep control over sensitive information stored in Jira.

Note: Security Scanner View is available during the trial period and included in the Advanced plan of Issue History for Jira app. After the trial ends, it is available only in the Advanced plan.

You can try the Advanced plan for 30 days free or upgrade at any time.

Sensitive Data Types and Severity Levels

Security Scanner View (PII & DLP) automatically scans Jira work items to find sensitive data, including:

Data type	Severity	Score
Password	🔴🔴🔴🔴🔴	5 (Critical)
Credentials	🔴🔴🔴🔴🔴	5 (Critical)
Credit Card	🔴🔴🔴🔴🔴	5 (Critical)
Social Security Number	🔴🔴🔴🔴🔴	5 (Critical)
Document ID	🔴🔴🔴🔴🔴	5 (Critical)
AWS Client ID	🔴🔴🔴🔴🔴	5 (Critical)
AWS MWS Key	🔴🔴🔴🔴🔴	5 (Critical)
AWS Secret Access Key	🔴🔴🔴🔴🔴	5 (Critical)
Google API Key	🔴🔴🔴🔴🔴	5 (Critical)
Google OAuth Client ID	🔴🔴🔴🔴🔴	5 (Critical)
Google OAuth Access Token	🔴🔴🔴🔴🔴	5 (Critical)
GitHub Token	🔴🔴🔴🔴🔴	5 (Critical)
Generic API Key	🔴🔴🔴🔴🔴	5 (Critical)
Generic Secret	🔴🔴🔴🔴🔴	5 (Critical)
Stripe API Key	🔴🔴🔴🔴🔴	5 (Critical)
SendGrid API Key	🔴🔴🔴🔴🔴	5 (Critical)
Slack Token	🔴🔴🔴🔴🔴	5 (Critical)
Slack Webhook URL	🔴🔴🔴🔴🔴	5 (Critical)
Azure Storage Access Key	🔴🔴🔴🔴🔴	5 (Critical)
Mailgun API Key	🔴🔴🔴🔴🔴	5 (Critical)
Mailchimp API Key	🔴🔴🔴🔴🔴	5 (Critical)
Shopify Secrets	🔴🔴🔴🔴🔴	5 (Critical)
Shopify Partner API Access Token	🔴🔴🔴🔴🔴	5 (Critical)
Square Access Token	🔴🔴🔴🔴🔴	5 (Critical)
Square OAuth Secret	🔴🔴🔴🔴🔴	5 (Critical)
SSH Private Key	🔴🔴🔴🔴🔴	5 (Critical)
SSH Public Key	🔴🔴🔴🔴🔴	5 (Critical)
RSA Private Key	🔴🔴🔴🔴🔴	5 (Critical)
PKCS8 Private Key	🔴🔴🔴🔴🔴	5 (Critical)
PGP Private Key	🔴🔴🔴🔴🔴	5 (Critical)
EC Private Key	🔴🔴🔴🔴🔴	5 (Critical)
Password in URL	🔴🔴🔴🔴🔴	5 (Critical)
Phone Number	🔴🔴🔴🔴	4 (High)
Email Address	🟡🟡🟡	3 (Medium)
IP Address	🟡🟡🟡	3 (Medium)
Physical Address	🟡🟡🟡	3 (Medium)
Username / Login	🟡🟡	2 (Low)
ZIP Code	🟡	1 (Minimal)

Detected findings are displayed in a structured table, making it easy to review and prioritize work items that need attention.

How does it work?

Open the app in Jira and go to Security Scanner View.
Select what to scan using filters. You can filter work items by space, sprint, JQL, and more.
Set the date range to specify the time period to scan (current content and history within that range).
Review the generated report. It shows work items (Jira work items where sensitive data was detected), type of finding (category of detected sensitive data (for example, password or API key), security finding (detected sensitive data), severity score (indicates how much attention the finding may need).

Security Scanner View helps users quickly see where sensitive data appears in Jira work items and their history. Instead of manually checking work items one by one, you can get a clear list of findings in one place.

Historical finding (not present in the current state of work item)

Historical mark in the Field column indicates that the security finding is no longer present in the current content. It means sensitive data (such as a password, API key, or card number) appeared in a past change, for example, in an earlier comment or description, and was later removed or updated.

Why this matters:

Sensitive data may still exist in the work item history.
Historical exposure can be relevant for audits and compliance.
Teams can identify and address past data risks, not just current ones.

Who can access the Security Scanner View?

Access to the Security Scanner View is controlled at the group level in the app’s Permissions settings.

Admins can define which user groups are allowed to view Security Scanner results and access sensitive data detection (PII & DLP findings)

Permissions are configured per group via checkboxes in the app’s Permissions page:

Open the app, click the More (⋮) menu in the top-right corner, and select Permissions.

Locate the Security Scanner column, select the groups that should have access, and click Save changes.

Only selected groups will be able to use the Security Scanner View.

Questions & Answers

1. Where sensitive data is stored and how it is protected?

Data is stored in Jira work items and their change history. Security Scanner doesn't modify or move this data. Access is controlled by Jira and app permissions.

2. Where sensitive data comes from and how it enters Jira?

Sensitive data enters Jira through user input (fields, comments) or automated integrations that write data into work items.

3. How Security Scanner in Issue History for Jira app gets the data?

Security Scanner in Issue History for Jira app reads Jira work item data at runtime directly from Jira.

Data is processed inside Atlassian Cloud infrastructure
Jira remains the single source of truth for all work item data
The app doesn't write data back into Jira databases
The app doesn't store, copy, or persist Jira work item data in an external database

Issue History for Jira reads the full work item history on the fly, analyzes it, formats the results, and displays them to the user.

4. What data is read and how it is processed?

Issue History for Jira app reads Jira work item data and its change history at runtime.
This includes work item fields, comments, and historical values.

The data is processed on the fly inside Atlassian Cloud to:

detect potential sensitive data patterns
identify the data type
assign a severity level
and present the results to the user

The app doesn't modify Jira data and doesn’t store or persist work item content outside Jira.

5. How data is categorized by sensitivity?

Detected data is categorized based on its type and potential impact. Examples include credentials and secrets, personal data, and financial information.

This categorization is used to assign a severity level, helping users understand how sensitive the data is and how urgently it should be reviewed.

Severity is rated from 5 (highest) to 1 (lowest) to make it easy to spot the most important findings first. Higher numbers indicate more sensitive data and greater potential impact, while lower numbers indicate less sensitive data.

This scale helps users quickly prioritize review, starting with the highest-severity findings.

6. Does Issue History for Jira app read and store sensitive data found in Jira work items and their history?

Issue History for Jira can read Jira work item data and their history at runtime to detect sensitive data. It doesn't store, copy, or persist sensitive data (or any Jira work item content) in its own database.

Issue History for Jira doesn't maintain a separate customer data database.

The app:

Doesn't pull full work item histories into an external DB
Doesn't store work item fields, comments, or change history outside Jira
Uses Atlassian-provided Forge storage only for minimal operational metadata, not customer work item data.

7. What to do after sensitive data is detected in work item history?

If the sensitive data is only in history, there is a safe and practical way to handle it.

✅ Recommended approach:

Clone the work item. Create a new work item based on the current state only, with no sensitive data.
Verify the cloned work item. Ensure descriptions, comments, and fields are clean and do not contain any secrets or personal data.
Delete the original work item. This eliminates the historical versions where the sensitive data was stored.

This approach helps you:

Delete sensitive data in Jira entirely.
Maintain the work item in a clean, safe state.
Reduce audit and compliance risks.

Act fast without complicated clean-up processes.

Haven't used Issue History for Jira app yet? 👉 Then you’re welcome to try it 🚀