Privacy Receipts: What They Are and Why Teams Ask for Them
A privacy receipt is a downloadable record that processing stayed local. Here’s the idea, what belongs in one, and when they’re useful in real reviews.
Part of the Developer Privacy Workflows series.
Security questionnaires love binary answers: “Do you upload customer files to third parties?” Sometimes the honest answer is “not for this workflow” - and then someone asks how you’ll prove it next quarter. That’s the gap a privacy receipt tries to fill.
It’s not a legal shield by itself. It’s a structured note you can download after a local job: what ran, where it ran, and what didn’t leave the browser. Think packing slip for processing, not a court order.
The concept in plain terms
When a tool processes a file entirely in your tab, the interesting claim is negative: no server ever held the bytes. Screenshots of a marketing page don’t convince a careful reviewer. A receipt that records tool id, timestamp, processing mode (client-side), and optional hashes of inputs/outputs gives them something inspectable.
OneDevToolkit documents the shape in the privacy receipt spec and walks through usage in how privacy receipts work. You can also assemble one with Privacy Receipt Builder.
What usually belongs inside
- Tool name and version or build id.
- UTC timestamp for when the job finished.
- Processing locality claim (e.g. browser-only).
- Optional content hashes - handy if you need to show “this output came from that input” without attaching the files.
- Notes field for ticket ids or client names (keep PII out of the note if the receipt itself will be shared widely).
Hashing side quest: generate digests with Hash Generator when you want a portable fingerprint. Background: hash checksums explained.
Who asks for these
Agencies handling client PDFs. Freelancers under NDA. Internal IT reviewing “free tools” habits. Procurement teams comparing vendors who all claim “we don’t store your data.” A receipt won’t replace a SOC report for a hosted SaaS, but it strengthens the story for local workflows where the alternative was a random uploader.
Good uses and bad uses
Good: After redacting a contract in PDF Redact, download a receipt into the project folder next to the deliverable. When the client asks “where did this file go?”, you have a dated artifact.
Bad: Treating a receipt as proof that no other tool in your stack ever leaked data. It only speaks to the job it describes. Also bad: stuffing secrets into the receipt JSON and emailing it around.
A tiny team playbook
- Classify the file (public / internal / restricted).
- Restricted → local tool only.
- Download receipt when the client or ticket requires evidence.
- Store receipts with the work product, not in a shared “misc” Drive dump.
Receipt vs privacy policy
A privacy policy describes intentions across a product. A receipt describes one job. Policies matter for vendors you entrust with data. Receipts matter when the claim is that you didn’t entrust them - you processed locally and want a souvenir of that choice.
Don’t mix them in conversation with clients. If they ask for SOC2, a receipt won’t substitute. If they ask “did this PDF leave our laptop during redaction?”, a receipt is the right artifact.
A practical hashing workflow
- Compute a SHA-256 of the input file before processing.
- Run the local tool.
- Hash the output.
- Store both digests on the receipt with timestamps.
Later, anyone can re-hash the deliverable and see it matches. They still have to trust that your client-side tool didn’t phone home - which is why vendor transparency and Network-panel checks still matter - but you’ve made the file lineage clearer than a vague email saying “we handled it carefully.”
Agency template language
Consider a short clause in SOWs: “Sensitive transforms occur in client-side tools when available; optional privacy receipts can be delivered with the work product.” That sets expectations before someone asks you to use a random converter under deadline.
Train juniors on when to attach receipts: regulated industries, nervous clients, anything that already required an NDA addendum. Skip them for public blog-image compression or you’ll create paperwork theater.
Field notes from teams who shipped this
The pattern that keeps showing up: write the constraint first, then the steps, then the failure modes. Teams that only publish happy-path screenshots create tickets. Teams that document the ugly path create trust.
Schedule a short review ninety days after publishing. Check whether product UI names still match, whether linked tools still exist, and whether support still hears the same questions. Update the page or merge it. Standing still is how useful posts become interchangeable again.
If you adapt this article for internal wikis, keep the examples tied to your stack names. The moment you generalize back to “best practices for organizations,” you’ve started erasing the specificity that made the piece worth saving.
Storage hygiene for receipts
Receipts can contain client names and hashes. Store them with the same access controls as the work product. Don’t dump them into a public Notion page. Retention schedules should match the engagement’s contract, then delete.
FAQ
Is a receipt cryptographic proof?
It’s evidence of a claim, especially when paired with hashes and a trustworthy client-side implementation. It isn’t a remote attestation from a secure enclave unless your stack adds that.
Do we need receipts for every click?
No. Use them when someone else needs a paper trail. Everyday public-asset work can skip them.