Answering GDPR data-subject requests: finding one person’s data in Jira attachments
A data-subject access request arrives, and the clock starts. Under Article 15 of the GDPR you generally have a month to tell a person everything you hold about them; under Article 17, the right to erasure, you have to be able to delete it. For the structured parts of Jira — issues, comments, fields — that’s tractable. The hard part is the attachments: the screenshots, scanned forms, and exported spreadsheets where that person’s data might be sitting, completely invisible to a normal search. If you need to handle a GDPR data-subject request in Jira, the attachments are where completeness either holds up or quietly breaks.
Why completeness is the whole game
A DSAR or erasure response is judged on completeness. Missing one comment is bad; missing a spreadsheet that contains the person’s email, or a scanned form with their signature, undermines the entire response — and for an erasure request, a single overlooked attachment means the data wasn’t actually erased. The regulator’s question isn’t “did you look?” but “can you show you found everything?” Attachments are the most likely place for that completeness to fail, because they’re the part nobody can search by default.
Why the attachments are the blind spot
Jira’s search and JQL index issue fields and comments, not file contents. So if a person’s data lives inside an attached PDF, spreadsheet, or screenshot, no query will find it. Permission schemes don’t help — they govern access, not discovery. And because that data often arrives as scanned documents or images, even text-based tools miss it. To answer a DSAR honestly, you have to be able to read inside every attachment, including the ones that are really pictures of text.
A targeted scan is exactly the right tool
This is the use case where pattern matching is at its most reliable, because you already know who you’re looking for. You take the subject’s identifiers — name, email address, customer ID, phone number — and define them as patterns, then scope a scan with JQL. Attachment Scanner for Jira reads every supported attachment, including images and scanned PDFs via OCR, and reports every file where those identifiers appear, with full context. Instead of guessing which tickets might involve the person, you get a concrete, evidenced list of exactly where their data lives in attachments — the email address being the most dependable anchor, with name and other identifiers filling in the rest.
From findings to a defensible response
Each match gives you the issue key (click straight through to Jira), the file name, the extraction type, the matched text, and the surrounding context — everything you need to confirm a genuine hit and document it. For an access request, this becomes your evidence of what you hold. For an erasure request, you can bulk-select the relevant matches and delete those attachments, an explicit, admin-confirmed action that’s written to the audit log. That audit log is the quiet hero of a DSAR: it lets you demonstrate not just that you deleted the data, but when, by whom, and from where — the proof of completeness regulators increasingly expect.
Making it repeatable
DSARs aren’t one-offs; they recur, and each one is easier if the last one left a template behind. Save the scan definition — your identifier patterns plus the scope — and the next request becomes a matter of swapping in the new person’s details and running it again. Over time this turns a dreaded, error-prone scramble into a routine, documented procedure, which is exactly the posture an auditor or DPO wants to see.
Honest scope, privacy, and a related option
Two honest notes. First, no tool makes you GDPR-compliant on its own; Attachment Scanner is one technical control — strong for the attachment portion of a DSAR — inside a broader process that also covers structured fields, other systems, and legal review. Second, scope matters: the app scans the JQL range you give it on demand, so define the scope deliberately to cover the projects in play. Its privacy model fits regulated work: EU/EEA OCR, no public AI service, in-memory processing, and matched snippets stored only in Atlassian’s Forge storage. If your need is instance-wide discovery across Jira and Confluence — including non-attachment content — that’s a broader job than this app targets, and worth evaluating alongside Actonic’s Data Protection & Security Toolkit. For the attachment blind spot specifically, you can try Attachment Scanner for Jira free for 30 days from the Atlassian Marketplace.
Request