How to prove to your auditor that a file was actually deleted

Your auditor has just asked, in that particular tone auditors use, whether you can prove the offer letter you sent to a withdrawn candidate three weeks ago has actually been deleted. You know it expired. You're pretty sure the recipient never re-shared it. But "I think so" is not an answer that closes a finding, and emailing the vendor to ask for confirmation is the part of the conversation you were hoping to avoid.

This post is about the artifact that ends that conversation in your favor — what it looks like, what an auditor will actually accept, and what to ask for from any tool that claims to delete things on your behalf.

Why "we deleted it" is not deletion evidence

Auditors don't doubt you personally. They doubt the workflow. The control objective in every framework that touches data retention — SOC 2 CC6.5, ISO 27001 A.8.10, HIPAA §164.310(d), GDPR Article 17, the FTC Safeguards Rule's disposal clause — is the same shape: prove that the data is gone, prove who authorized the disposal, prove when it happened, and prove that the proof itself hasn't been altered.

A vendor email saying "the file was deleted on March 4" satisfies none of those. It's an assertion, not an artifact. The auditor has no way to know whether the email was generated automatically, hand-written by a support rep checking a dashboard, or stitched together from logs after you asked. A screenshot of an empty folder is worse — it proves your screen was empty, not that anything was destroyed.

What auditors want, and increasingly demand, is something they can independently verify without contacting the vendor. That's the bar to clear. Everything in this post is about how to clear it.

"I don't need you to tell me it's gone. I need to be able to confirm it's gone six months from now when I'm not in the room with you." — Lead auditor, mid-tier SOC 2 firm, paraphrased from a kickoff call

What a deletion evidence pack actually contains

A complete deletion evidence pack — the kind that ends an audit thread instead of starting a new one — has four parts. Each part exists because a sophisticated auditor will ask about it, and each part has to stand on its own without depending on the others.

The four parts:

1. The receipt itself — a signed, timestamped document that names what was deleted (without naming the contents), when the deletion fired, what triggered it (manual revoke, view cap, time expiry, download cap), and who held the authority to authorize the share originally.
2. A signature you can verify — a cryptographic signature on that document, plus a way for someone outside your organization to confirm the signature matches the document and was issued by the platform.
3. An anchor into a tamper-evident log — a reference linking the receipt to a position in an append-only audit chain, so the auditor can confirm the receipt wasn't generated retroactively to cover a gap.
4. The chain itself — exportable, verifiable, with no edit history because the structure mathematically forbids editing.

Most "deletion confirmation" features stop at part one. The receipt looks legitimate, but there's no way to verify it didn't get fabricated last Tuesday. Auditors have seen this pattern enough times that they discount unsigned receipts entirely.

The signature is what turns the receipt from a vendor claim into a portable artifact. If your platform publishes its public key in a well-known location (most do this via a JWKS endpoint), anyone — your auditor, your DPO, your customer's procurement team — can independently confirm the receipt was signed by that platform and hasn't been altered since. They don't need access to your account. They don't need a support ticket. They just need the receipt file and a verification tool.

The chain anchor matters because it answers the auditor's most awkward question: "How do I know you didn't generate this receipt last week?" In a hash-chained log, every entry includes a cryptographic fingerprint of the entry before it, so you can't backdate an event without breaking every entry that came after it. The receipt's chain anchor is the position in the chain it locked to at the moment of deletion. The auditor confirms that position still resolves to the same hash today, and the receipt's authenticity is settled.

What auditors actually ask for, in their own words

Three real questions, anonymized, from compliance officers walking auditors through their controls in the last twelve months:

• "Can you show me, for any of the files you sent last quarter, the timestamp the file became unrecoverable, and prove that timestamp wasn't generated after the fact?"
• "I see your retention policy says files auto-delete after seven days. How would you demonstrate to a regulator that this control was operating effectively across all 240 shares in scope?"
• "If the file was deleted on March 4, and we're sitting here on April 12, what's the chain of custody between then and now that proves nothing changed about the deletion record?"

Notice what's not in any of these. They're not asking whether you can delete things. They're asking whether your ability to prove it survives time, personnel changes, and the vendor going out of business.

That last point matters more than people realize. A growing share of compliance frameworks expect deletion evidence to remain verifiable even if the platform that issued it disappears. That's only possible when the verification artifact is portable — when the signed receipt can be checked against a public key that exists outside the vendor's control surface, by anyone with the file.

If your current sharing tool's deletion proof depends on a working login to that vendor's portal, you don't have deletion evidence. You have a vendor dependency.

The minimum bar for a defensible workflow

Here's the workflow shape that lands cleanly in every audit I've seen close in under two cycles. None of these are aspirational; they're table stakes for serious compliance work.

When you send a sensitive file:

• The file is encrypted before it leaves your browser, so the platform itself never holds the readable contents. The auditor's questions about what the vendor might have seen become moot.
• The share carries explicit destruction conditions you set at send time — number of views, number of downloads, time expiry up to the system-enforced 7-day ceiling (or a specific calendar date on Enterprise), or any combination. These conditions are visible to you and to your auditor in the share's record.
• When any condition fires, the platform produces a signed receipt naming the share, the trigger, and the time, and anchors that receipt to a position in your organization's audit log.
• The receipt is exportable as a self-contained file. Your auditor can verify it without an account.

When your auditor asks for evidence:

• You export the relevant receipts directly from the platform — not as PDFs, but as the original signed artifacts.
• You point them at the platform's public verification page, where they paste in any receipt and confirm the signature, the timestamp, and the chain anchor.
• For high-stakes engagements (M&A diligence, regulatory inspection), you also export the full audit chain segment covering the period in scope and provide the verification command alongside it.

That's the whole loop. If the platform you use can support those four export points cleanly, the deletion-evidence conversation with your auditor becomes a fifteen-minute item instead of a fifteen-page memo.

The platforms that struggle with this aren't bad products. They're often products that were designed for productivity first and added compliance as a feature layer later. The bones aren't there. When you ask for a signed receipt, you get a CSV export of activity logs and a kind email from support.

How CIPH4 builds this in, for the buyers who asked

CIPH4 was built backwards from this auditor conversation. Every share — whether it's a free-tier password handoff or an Enterprise M&A data-room drop — generates an entry in a hash-chained audit log. Every Enterprise-tier deletion event also produces a signed Proof-of-Deletion Receipt, anchored to the chain position it was written into.

The receipts are signed with a key whose public half is published openly. Your auditor doesn't need to call us, log into anything, or take our word for the signature being valid. They paste the receipt into our public verifier — or run the verification offline against the published public key — and get a yes/no on whether the receipt is authentic and the chain anchor still resolves.

The hash-chained audit log records every share lifecycle event on every plan. CSV export of the chain is a TEAMS-and-up feature. The structure is the same one banks use for transaction ledgers: each entry includes a hash of the prior entry, so a single altered byte anywhere in the history would change every fingerprint that came after it. This is what auditors mean when they ask for "tamper-evident" logs. It's not a marketing word; it's a mathematical property.

For compliance teams specifically, the compliance workspace surfaces this without making you build the export pipeline yourself. Receipts and audit rows are filterable by date range, originating user, and event type at export time. When SOC 2 season starts, the evidence pack is a filter and an export, not a project.

Three things to flag honestly:

• The signed-receipt feature is Enterprise-tier. The hash-chained audit log is on every plan, including Free; the CSV chain export is Teams-and-up. The Teams export and activity record map cleanly onto SOC 2 CC6.5 and ISO 27001 A.8.10 evidence requests. The signed Ed25519 receipt is the artifact that closes GDPR Article 17 and HIPAA disposal proofs cleanly, and that's the deciding factor for most regulated buyers. The current pricing for each tier is on the pricing page.
• Receipts cover the destruction event, not the entire chain of custody before it. If your auditor is asking about who viewed the file between send and destruction, that's the audit log's job, not the receipt's. Both ship together; just don't conflate them.
• The receipt names the share, not its contents. By design — the platform never sees the contents, so it can't sign over them. What it signs is a cryptographic hash of the ciphertext that existed at destruction time, plus the share metadata. Auditors familiar with content-addressed integrity recognize this immediately; if your auditor isn't, the security architecture page walks through the model in compliance-friendly language.

What to tell your auditor in the next conversation

When the deletion-evidence question comes up — and it will, on every annual cycle — the productive sentence is some version of: "We can produce a signed receipt for every destruction event in scope, verifiable against a published public key without contacting us, and anchored to a tamper-evident chain that we'll export alongside it."

That sentence does two things. It tells the auditor you understand the actual evidence standard, not just the surface request. And it sets the expectation that the conversation is about reviewing artifacts, not about whether the artifacts exist.

If you're not at a platform that can support that sentence yet, the migration is smaller than it looks. Most compliance teams move their highest-risk share categories first — offer letters, M&A diligence packages, breach-response files, vendor onboarding packets — and leave lower-stakes sharing on incumbent tools. Within a quarter you've got receipts for the items the auditor actually scrutinizes, and the audit thread closes faster every subsequent year because the evidence pack already exists.

What to do next

If you've got an audit on the horizon and you're still planning to send a vendor support ticket as your deletion evidence, the time to fix that is now, not the week the auditor arrives. Start with one share category, generate a real receipt, and walk it through the verification flow yourself before you put it in front of someone else.

The artifact is the conversation. Get the artifact right and the rest of the audit takes care of itself.