Screenshots, PII and GDPR in Support Tickets: A Practical Guide

Quick answer: a screenshot that shows a customer's name, email, account details or anything else that identifies them is personal data under the GDPR, exactly like the same details typed into a ticket. Collect only the screenshots you need, blur anything the reader doesn't need to see, keep them only as long as the ticket requires, and treat a screenshot sent to the wrong person as a possible data breach. The hard part is that screenshots are images, so the tools that protect your text usually can't see what's inside them.

This guide explains how the GDPR applies to a common support workflow. It is not legal advice. For decisions about your organization, talk to your data protection officer or counsel.

Why screenshots are the blind spot in support

Support teams usually protect text well. Help desks mask card numbers in messages, data loss prevention tools scan outgoing email, and agents learn not to paste passwords into tickets.

Screenshots slip past most of that:

• Text inside an image isn't text. Redaction rules, search and DLP tools that work on ticket text don't read the pixels of an attachment unless they run text recognition on it.
• They show more than the problem. A screenshot of an error also captures the sidebar of recent customers, the account owner's email and the browser tabs behind it.
• They multiply. One screenshot gets attached to the ticket, pasted into an internal chat, filed in the issue tracker and forwarded to a vendor. Each copy has its own access list and its own retention.
• They're hard to find later. When a customer asks for their data or for erasure, nobody can search images for their name.

Is a screenshot personal data under the GDPR?

Usually, yes. Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. The format doesn't matter. A screenshot is personal data when someone can be identified from it, directly or with other information you hold:

• Directly identifying: names, email addresses, phone numbers, photos, postal addresses.
• Indirectly identifying: customer IDs, order numbers, account numbers, IP addresses, usernames, ticket links.
• Special category data under Article 9, such as health information visible in a patient portal, needs even more care.

A screenshot of a settings page with nobody's details in it isn't personal data. The same page with the account owner's email in the corner is.

The GDPR principles a careless screenshot breaks

The rules that matter most for screenshots come from the principles in Article 5 and the security duties that follow from them.

• Data minimisation (Art. 5(1)(c)). Personal data must be limited to what is necessary. A full-screen capture when a cropped one would do, or an unblurred list of other customers, is more data than the purpose needs.
• Storage limitation (Art. 5(1)(e)). Data shouldn't be kept longer than necessary. Screenshots attached to tickets often outlive the ticket by years.
• Integrity and confidentiality (Art. 5(1)(f) and Art. 32). You need appropriate security, including against accidental disclosure. Posting a customer's screenshot in a busy channel is an accidental-disclosure risk.
• Data protection by design and by default (Art. 25). Your processes and tools should make the private option the default. A screenshot tool that blurs before sharing and doesn't upload by default fits this principle. One that sends every capture to a vendor cloud works against it.
• Right of access and erasure (Art. 15 and Art. 17). Customers can ask for a copy of their data and, in many cases, for its deletion. Screenshots in tickets are in scope.

Where support screenshots travel

Every place a screenshot lands is another system processing personal data, often run by a vendor acting as your processor under Article 28.

Map this path for your own team. For each stop, you should be able to answer: who can see it, how long it stays, and whether the vendor is covered by a data processing agreement. If a stop has no answer, that's where screenshots leak from.

Screenshots customers send you

You can't stop customers from attaching screenshots, but you can shape what they send and what you keep.

• Ask for the right thing. Help articles and auto-replies can say: "Please crop your screenshot to the problem and hide card numbers, passwords and other people's details."
• Redact on arrival. If a customer sends a full card number or a password, remove or replace the attachment, using your help desk's redaction or deletion tools where available, and tell them to change the password.
• Don't spread it further than needed. Link to the ticket from internal chat instead of re-uploading the image.
• Delete with the ticket. Make sure your help desk retention rules cover attachments, not only message text.

Screenshots your team sends

Outbound screenshots are where you have the most control, and where mistakes are most visible.

• Only the customer's own data. A screenshot sent to a customer must never show another customer's details. This is the classic support mistake: the agent's sidebar lists recent tickets with names and emails.
• Crop first, then blur. Crop to the part that explains the answer, then blur anything identifying that remains.
• Use test accounts for how-to guides. Help articles and macros should use demo data, never a real account.
• Check the edges. Tab titles, the address bar, notification pop-ups and the signed-in account name all show up in full-window captures.

When a screenshot leaks: is it a personal data breach?

Article 4(12) defines a personal data breach to include the accidental or unlawful … unauthorised disclosure of, or access to, personal data. A screenshot showing one customer's details sent to another customer fits that definition. So does posting it somewhere people without a need to know can see it.

What the GDPR asks you to do:

1. Contain it. Delete the message, ask the recipient to delete it and confirm, revoke links.

2. Record it, always. Under Article 33(5) you must document every personal data breach, its effects and what you did about it, even ones you don't report.

3. Assess the risk to the people involved. A first name shown to a trusted business partner is very different from a full card number posted publicly.

4. Notify the authority if there's a risk. Under Article 33(1), you notify your supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to people's rights and freedoms.

5. Tell the affected people if the risk is high (Article 34).

The European Data Protection Board's guidelines on breach notification explain how to assess risk. Your DPO should own the decision, but support needs to report incidents to them quickly, because the 72 hours start when your organization becomes aware.

Access requests, erasure and screenshots

When a customer exercises their right of access, the copy you provide should include personal data held in ticket attachments, not just the ticket text. When they ask for erasure and you have no reason to keep the data, the screenshots go too.

That only works if you can find them. Two habits help:

• Keep screenshots attached to the ticket of the person they concern, not floating in chat threads, shared drives or personal downloads folders.
• Blur other people's data before attaching, so one customer's request never forces you to hand over or review another customer's details.

A screenshot policy you can adopt today

Short enough to fit in an onboarding doc:

1. Capture only the part of the screen that explains the issue.

2. Blur names, emails, phone numbers, account and order numbers, card data and credentials before sharing.

3. Never show one customer's data to another customer.

4. Use demo accounts for help articles, macros and training material.

5. Attach screenshots to the ticket they belong to. Link to the ticket instead of re-uploading the image elsewhere.

6. Delete screenshots with the ticket, according to your retention schedule.

7. Report a screenshot sent to the wrong person to your DPO the same day.

8. Use tools that are private by default: local capture, built-in blur, no automatic upload.

Making the private way the fast way

Policies fail when following them is slow. If blurring means opening a second app, a busy agent with 40 tickets in the queue will skip it.

Screshot was built for this workflow. Agents capture the visible area or a full page, blur customer details in one drag and copy the result straight into the ticket. Capturing, blurring, copying and downloading all happen on the agent's device, and nothing is uploaded, so there is no extra processor holding your customers' screenshots. IT can force-install it for the whole support team, and your DPO can check the data flow in our security review pack.

FAQ

Is a screenshot with blurred names still personal data?

It depends on what's left. If the blur removes everything that identifies a person and nothing else in the image or its context points to them, the image no longer contains their personal data. If an order number, a username or an unusual detail is still visible, it may still identify them. Blur strongly, too: light pixelation can sometimes be reversed.

Do we need the customer's consent to take a screenshot of their account?

Not necessarily. Consent is only one of the lawful bases in the GDPR. When an agent captures a customer's account to resolve that customer's request, the processing is usually part of providing the service you agreed to. Confirm the lawful basis for your support processing with your DPO and record it.

How long can we keep screenshots in support tickets?

The GDPR doesn't set a number of days. You decide a retention period based on why you need the data, apply it to attachments as well as text, and stick to it.

Is posting a customer screenshot in an internal chat channel a breach?

Not automatically. Colleagues with a genuine need to see it are part of normal processing. It becomes a problem when the channel includes people without that need, external guests, or when the screenshot shows more than the task requires.

What are the fines for getting this wrong?

Article 83 allows fines of up to €20 million or 4% of global annual turnover for breaches of the core principles, whichever is higher, and up to €10 million or 2% for some other obligations. In practice, the bigger costs for most teams are incident handling, customer trust and the time spent on a breach that a two-second blur would have prevented.

Sources

• GDPR Article 4: Definitions (personal data, personal data breach)
• GDPR Article 5: Principles relating to processing of personal data
• GDPR Article 25: Data protection by design and by default
• GDPR Article 32: Security of processing
• GDPR Article 33: Notification of a personal data breach to the supervisory authority
• GDPR Article 34: Communication of a personal data breach to the data subject
• EDPB Guidelines 9/2022 on personal data breach notification under GDPR
• GDPR Article 83: General conditions for imposing administrative fines

Written by

Screshot Team

Product & security team

The team that builds Screshot, the private screenshot tool for Chrome. We write about keeping customer data out of screenshots, rolling out tools across a company, and getting work done faster with your screen.