Before attaching anything to a ticket, replace names, emails, identifiers, tokens and free text with placeholders, crop screenshots, and cut logs to the lines you need. Better still, reproduce the bug with synthetic data and attach that. A ticket is a copy, and copies spread.
Why tickets are a leak path
Debugging pulls real data toward developers: a stack trace with a request body, a screenshot of a customer's account, an exported spreadsheet that "shows the problem". These land in ticket systems, chat threads, email and vendor support portals, each with its own access list and retention.
The data minimisation principle says personal data should be adequate, relevant and limited to what is necessary for the purpose. A bug report rarely needs the customer's identity. This is general information, not legal advice.
What to look for
| Artifact | Typical hidden data | Fix |
|---|---|---|
| Logs | Emails in messages, tokens in headers | Cut to the relevant lines, redact |
| Screenshots | Names, addresses, order details, browser tabs | Crop, blur, retake with test account |
| HAR files and traces | Cookies, authorization headers, bodies | Strip headers and bodies, or recapture in staging |
| Database exports | Entire rows | Replace with a synthetic row of the same shape |
| Stack traces | Query parameters, user ids | Remove values, keep structure |
| Screen recordings | Everything on screen | Re-record with test data |
Steps
- Try reproducing first. Create a test account in staging and follow the same steps. If it reproduces, attach that evidence instead.
- Describe the data shape. Write "user with 3 addresses, one with a non ASCII character" rather than pasting the record. Shape is what developers need.
- Replace with consistent placeholders. Use the same placeholder for the same value, such as user A and user B, so the sequence of events still makes sense.
- Strip secrets. Remove authorization headers, cookies, API keys and session identifiers. Treat any that were shared as exposed, and rotate them if they were live.
- Crop and blur. Use the screenshot tool's redaction and check the result by viewing at full size. Text can survive light blur.
- Check metadata. Files can carry author names and paths. Export a clean copy.
- Choose the right channel. Use the ticket system your access rules cover, not personal email or a public paste site.
- Set an expiry. If an attachment truly needs real data, record the reason, limit visibility, and delete it when the issue closes.
For vendor support cases
Vendors will ask for logs or sample data. Send the minimum, redacted, through their official portal, and ask how long they retain attachments. Keep a note of what you sent and when.
Make it routine
Add a line to your bug template: "Does this report contain customer data? If yes, remove it or explain why it is needed." Provide a short redaction how to in your engineering handbook. Make the safe path easier than the unsafe one, for example with a command that strips headers from a HAR file.
Quick check
Is blurring a screenshot enough?
Not always. Heavy redaction boxes are safer than blur, and cropping beats both. Review the image before you send it.
What if a customer sent the data to us themselves?
Handle it under your privacy process, limit who sees it, and do not forward it to broader channels. Ask your privacy lead if unsure.
Sources
Last reviewed: 19 October 2026.
