Detecting national ID and passport numbers in Jira attachments
Identity documents are among the most sensitive things a person can hand over, and service desks ask for them constantly — to verify an account, process a claim, or satisfy a know-your-customer step. The result is predictable: scans of passports, national ID cards, driving licences, and tax numbers pile up as attachments on Jira issues, often as photos or scanned PDFs. Each one is a high-value target and a serious compliance exposure. If you need to find national ID or passport numbers in Jira attachments, the structured nature of these identifiers makes them detectable — provided you can read the scanned documents they arrive in.
Why identity data is especially risky
National identifiers are the keys to identity theft and fraud, which is why regulators treat them as a special category and why a leak carries outsized consequences. A passport scan in a support ticket isn’t just personal data — it’s a document that can be reused to impersonate someone. The exposure compounds over time: identity documents uploaded for a one-off verification stay attached long after the need has passed, accessible to everyone with permission to the issue, and invisible to any search that only reads issue fields.
The reason normal scanning fails here
Identity documents arrive almost exclusively as images or scanned PDFs — a photo of a passport, a flatbed scan of an ID card. That makes them the worst case for text-based tools. Jira’s search indexes fields, not file contents. Malware scanning sees a clean image. Text-reading DLP has nothing to read, because the document is pixels, not text. The only way to detect an ID number on a scanned passport is to perform OCR on the image first — which is precisely the gap Attachment Scanner for Jira is built around.
Patterns for structured identifiers
Most national identifiers follow a defined format, which makes them good regex candidates once you’ve decided which countries you care about. A passport number, a German tax ID, a UK National Insurance number, a US Social Security Number (\b\d{3}-\d{2}-\d{4}\b as a starting point) — each has a recognisable structure you can express as a pattern. Because formats are country-specific, the right approach is to build a small library of patterns for the jurisdictions you operate in rather than chasing a universal rule. You can also anchor on labels that accompany these numbers — Passport No., ID, Tax ID, SSN — to improve precision. Attachment Scanner lets you supply exactly these patterns, simple text or regex, scoped with JQL to the projects most likely to hold identity documents.
Running the scan where it matters
Identity documents concentrate in customer-facing and HR-adjacent projects, so scope there first. Because the files are overwhelmingly images and scanned PDFs, this is a case for a full scan — the mode that runs OCR on images and all PDF types — rather than document-only. Each scanned page consumes OCR credits, so a tight JQL scope (a single verification queue, a date range) keeps both runtime and cost in hand while still covering the high-risk files.
Review and remediate with care
Each match returns the issue key, file name, extraction type (here, almost always OCR), the matched identifier, and surrounding context, so you can confirm a genuine passport or ID number before acting. Given the sensitivity, remediation should be prompt: bulk-select the matches and delete the offending attachments, an explicit and admin-confirmed action that’s written to the audit log, with nothing removed automatically. If your process requires retaining a verification record, replace the full document with a minimal, properly controlled note rather than leaving the scan in place. The audit log gives you a defensible record that identity documents were found and removed.
Privacy, limits, and a starting point
Handling identity documents demands a trustworthy scanning model, and this is where the app’s design is most relevant: OCR runs on dedicated EU/EEA GPU hardware managed by Actonic, with nothing sent to a public AI service such as OpenAI, Google, or Anthropic. Attachment binaries are processed in memory and discarded immediately; only matched snippets are stored, in Atlassian’s Forge storage, isolated per site. Honest limits: regex per country is a strong aid but not perfect, OCR quality depends on the scan, scanning is on-demand rather than continuous, and the app is Jira Cloud only for now. Within that scope, it’s one of the few practical ways to surface identity numbers hiding inside scanned documents. You can start a free 30-day trial from the Atlassian Marketplace.
