Redacting screenshots for GDPR: what actually has to come out

A screenshot pasted into a ticket feels like a throwaway artefact. Under GDPR it is a record containing personal data, stored in a system with a retention policy, discoverable in an audit, and disclosable in a subject access request.

This is a practical guide, not legal advice — if you are handling a live DSAR or a breach, talk to your DPO or counsel. What follows is the operational part that engineers and support teams actually have to get right.

Why screenshots are the awkward case

Structured data is easy to reason about. You know which column holds an email address, and you can query it, export it and delete it.

A screenshot is an opaque blob. Nothing in your database knows that the PNG attached to ticket #4417 contains a customer’s full name, home address and the last four of their card. So it survives every process built around structured data:

• Retention policies delete the ticket record and leave the attachment, or delete neither because nobody classified it.
• Subject access requests are answered from the database, and miss the images.
• Deletion requests clear the row and leave the screenshot in object storage.
• Access control is per-ticket, so anyone in the support tool sees everything in it.

Audits find this reliably, because it accumulates quietly. A published example describes 847 Jira tickets holding unredacted personal data built up over eighteen months, only discovered during a GDPR audit.

Reversible redaction is a compliance problem, not just a security one

This is the part specific to redaction technique.

If you blur a customer’s address in a screenshot before attaching it to a ticket, you have not removed the personal data. You have applied a reversible transformation to it. The data is still in the file, recoverable by anyone who wants it — the mechanics are here.

That distinction matters legally, because “we redacted it” is a claim about what the file contains. If the original characters can be reconstructed from what you shipped, then:

• The disclosure still contained personal data, and any lawful basis you relied on for redacted disclosure does not cover it.
• In a DSAR where you redacted third-party data to protect their rights, that protection did not happen.
• If the file was shared externally, you may be looking at a personal data breach rather than a near miss.

Anonymisation under GDPR is judged by whether re-identification is reasonably possible, using means reasonably likely to be used. Running a deconvolution over a blurred region is well within “reasonably likely”. Pixelation is worse — it is a brute-force match against a small space of candidate strings, and it is exact.

Use an opaque fill on a flattened image. It is the only common technique where the output genuinely does not depend on the input.

What to remove from a screenshot

Work through this list every time. The obvious items are rarely what gets missed.

Direct identifiers

• Names, in content and in window titles, tab titles and profile menus
• Email addresses, including the signed-in account in the corner of the UI
• Phone numbers, postal addresses, dates of birth
• Account numbers, customer IDs, national insurance / SSN / national ID numbers
• Photographs of people, including avatars and video-call tiles

Financial and credential data

• Card numbers, IBANs, sort codes — including partial numbers, which combine with other sources
• API keys, tokens, session IDs and anything in a URL after ?
• QR codes and barcodes, which survive being small and are read by machine, not eye

The quiet ones

• Browser chrome. The URL bar leaks internal hostnames and customer identifiers in paths. Bookmarks leak org structure. Other tabs leak what else the person was doing.
• Notification toasts. A Slack or Teams popup that arrived mid-capture puts a third party’s name and message into your file.
• Sidebars and counts. “1,284 customers” tells a competitor your size and tells an auditor you screenshotted a full customer list.
• Timestamps and presence. “Last seen 14:02” is behavioural data about a person.
• Reflections in the UI. Recently-viewed lists, autocomplete dropdowns and search history reveal records the screenshot was not supposed to be about.
• File metadata. EXIF and PNG text chunks carry the tool, the machine name and the time. Strip them.
• The filename itself. dispute-jane-smith-refund.png undoes the redaction inside it.

Special care with DSARs

When you disclose records to a data subject, you must give them their data while protecting the rights of others in the same document. In a screenshot that usually means redacting a colleague’s name from an internal thread, another customer visible in a list, or a support agent’s personal details.

Two rules that save trouble later:

1. Redact third-party data, not inconvenient data. Removing something because it is embarrassing rather than because it identifies someone else is not a lawful redaction, and it is the thing regulators look for.
2. Keep a redaction log. Record what was removed from each file and the reason — third-party personal data, legal privilege, and so on. If the disclosure is challenged, the log is the evidence that the redaction was principled rather than arbitrary.

Reducing the problem instead of managing it

Redaction is remediation. The cheaper wins are upstream.

Stop collecting the screenshot. Much of the time a support agent needs the error message and the browser version, not a picture of the customer’s account page. A form field beats an attachment.

Redact at the source. Reproduce the issue against a test account with seeded data and screenshot that. Nothing to remove, nothing to leak, nothing to log.

Redact before it enters the system. Once the image is in your ticketing tool it is in backups, search indexes and any integration you have wired up. Removing it later means removing it from all of those. Redacting on the machine where the screenshot was taken — before it is ever uploaded — keeps the unredacted version from existing anywhere but that one disk.

Set a retention rule that covers attachments, and confirm it actually deletes the blob rather than just the row.

Write it down and train on it. Most leaks here are not malice, they are an agent in a hurry who blurred instead of blacking out. A one-page rule — opaque fill, flatten, check at 400% — prevents more incidents than any tool.

Where a local tool helps

The awkward part of screenshot redaction is that the safest moment to do it is the moment of capture, on the machine that took it, before the file moves anywhere. That is what SnapShield AI is for: detection and redaction run locally, so an unredacted copy never has to leave the machine to be processed, and the exported file has the pixels replaced rather than covered.

It does not make you compliant — no tool does. It removes one specific, common way of being non-compliant: shipping a file you believed was redacted when it was only blurred.

Related reading

• Can blurred text be recovered? — why blur and pixelation do not count as removal.
• How to redact a screenshot on Windows — the mechanics, tool by tool.