Client email example
Unsafe: “Jane Miller at jane@northwind.example says invoice INV-921 for $28,450 is wrong. Call +1 415 555 0198.”
Clean: “[CLIENT_CONTACT] at [EMAIL] says invoice [INVOICE_ID] for [AMOUNT] is wrong. Call [PHONE].” The problem remains clear without the real identity or contact details.
Support ticket example
Unsafe: “Customer CUST-3901 from IP 203.0.113.9 cannot access https://admin.example.com/users/8821.”
Clean: “Customer [CUSTOMER_ID] from [IP] cannot access [INTERNAL_URL].” If the path shape matters, use a synthetic path such as /users/[USER_ID].
JSON and log example
Unsafe: {"email":"user@example.com","token":"live-secret","order":"ORD-8821"}.
Clean: {"email":"[EMAIL]","token":"[SECRET]","order":"[ORDER_ID]"}. Keep valid JSON and preserve field names only when they are safe and relevant.
Screenshot example
Crop the screenshot to the relevant interface, cover the account menu, email, ID, balance, internal URL, and open browser tabs, then export a flattened copy.
Inspect the downloaded file rather than relying on the editor preview. The shared artifact is what must be safe.
Preserve relationships without preserving identities
A useful redaction keeps roles and relationships consistent. Use [CLIENT_A] and [CLIENT_B] when two clients appear, [ORDER_1] when an order is referenced several times, and broad labels such as [MONTH] or [REGION] when the exact date or location is unnecessary.
Read the cleaned example from beginning to end. A remaining domain name, project codename, unusual amount, job title, file path, or quoted signature may reconnect the placeholders to the real client even when obvious contact details are gone.
Final review checklist
- Placeholders describe the data type
- Different entities use different labels
- Access-bearing values are fully removed
- The example remains technically useful
- The final shared artifact is reviewed