If your vendor goes out of business, can the auditor still verify your receipts?

Picture this: it's 2029, three years after you finished a heated sales cycle and picked a secure file-sharing vendor for your firm. Their service shut down last quarter. Your auditor is sitting in your conference room asking to verify that a customer record was actually destroyed in 2026 — the destruction date you committed to under your privacy notice. Can you prove it, or does "the vendor is gone" become the answer?

That conversation is exactly the audit objection that should drive your evaluation of any deletion-receipt feature. Most vendors handwave it. A few solve it cleanly. The difference is whether the proof you walk away with depends on the vendor still existing.

The vendor-lock objection nobody likes to say out loud

When you sit through a procurement review for a deletion or retention tool, you'll hear questions about SOC 2, encryption, data residency, sub-processors. You will almost never hear the question that actually matters in year five: what happens to the evidence if the vendor disappears?

It's not asked because it's awkward. The vendor on the other side of the table doesn't want to entertain their own death. Your procurement team doesn't want to be the person dwelling on it. So everyone agrees the vendor is going to be around, signs the contract, and moves on.

But auditors — especially the ones doing privacy reviews under GDPR Article 17, CCPA deletion-right verifications, HIPAA disposal safeguards under §164.530(c) and electronic-media disposal under §164.310(d)(2), or the SEC's 2024 Regulation S-P amendments on customer-information incident response — care a lot about whether your evidence outlives your vendor. Three things tend to happen to SaaS companies that aren't going to happen to your audit cycle:

• They get acquired and the new owner shuts the product line down (we've all seen the "thank you for being a customer, please export your data within 60 days" email).
• They run out of runway and ghost.
• They pivot, and the old API endpoints go dark even though the company technically still exists.

In all three cases, if your proof of compliance lives in their portal — if the only way to verify a deletion is to log into their dashboard and trust their database — your evidence stack just got an expiration date you didn't agree to.

The audit question isn't "did this vendor delete the data?" It's "can you, the customer, demonstrate to a third party that deletion happened, without depending on the vendor still being reachable?"

That's the lens. Once you put it on, a lot of vendor claims collapse.

What a "receipt" usually means in this category, and why most of them fail this test

When a vendor says they generate a deletion receipt, look at the receipt itself. Open one. Most of the time, you'll find something like this:

• A PDF with the vendor's logo, the date, the customer's name, and a sentence that reads "we have deleted the following data."
• A row in the vendor's audit log dashboard with a green check mark.
• A JSON blob with an internal ID and a server timestamp.

All three are essentially the same artifact: a vendor-issued attestation that only the vendor can validate. If you re-present that PDF to an auditor in 2029, the auditor has no way to confirm it was actually issued by the vendor's system on the date it claims, that it hasn't been edited, or that the row it references ever existed. They have to take your word for it. Or yours and the vendor's, if the vendor is still around.

This is the vendor-lock trap. Not the obvious kind where your data is held hostage — the subtler kind where your evidence is held hostage. You exported it on time, you stored it carefully, and it still doesn't prove anything without the issuer's continued cooperation.

The two-question test

When you're evaluating a deletion-receipt feature, ask the vendor:

1. If your service went offline tomorrow, could I still verify this receipt is authentic?
2. Could a third party — my auditor, my regulator, opposing counsel in litigation — verify it independently, without contacting you?

If the answer to either is no, the receipt is theatre. It feels like evidence; it isn't.

For more on what compliance teams should specifically look for in this category, our compliance buyer page walks through the standard objections and the architectural answers to each.

How public-key signatures change the math

Here's the part that's worth understanding even if you're not technical. Every Proof-of-Deletion Receipt CIPH4 generates for Enterprise drops is signed with a cryptographic key. Specifically, it's signed with the private half of an Ed25519 key pair. There's a matching public half that doesn't have to be kept secret — in fact, it's published openly.

Signing with the private half and verifying with the public half is the same technology that makes HTTPS work, that secures every software update your laptop has ever installed, and that underwrites the global financial messaging system. It's older than the internet, the math is settled, and it has a property that matters enormously for audit work:

A signature can be verified by anyone holding the public key. Forever. Without the signer being involved or even existing.

That means a receipt issued today can be verified in 2029, in 2034, in 2050 — as long as someone has the public key on file. Your auditor doesn't need to ping our servers. Your regulator doesn't need our cooperation. Your forensic investigator doesn't need a subpoena.

This is the whole game. The public key is the thing you keep in your evidence vault. The receipts are the things you produce when asked. The combination is self-verifying.

What does "keep the public key on file" actually look like?

In practice, your compliance team does three things at onboarding:

• Download the current public key from our public verifier page — it's a small text file, a few hundred bytes.
• Store it in your evidence repository alongside your retention schedule, your privacy notice, and your subprocessor list. Treat it like a notarized signature card.
• Optionally, keep an offline copy. Print it. Burn it to a CD. Put it in the same vault as your articles of incorporation. The key doesn't change unless we deliberately rotate it (which we announce, document, and overlap), and a printed copy verifies just as well as a digital one for a court-admissible chain of custody.

That's the entire setup. Once it's done, every receipt you ever receive from us can be verified by anyone, on any computer, using any cryptography library written in the last twenty years.

What "the vendor is gone" actually looks like for the audit

Let's run the scenario all the way through. Suppose CIPH4 doesn't exist in 2029. Pick your reason: we got acquired and the new owner sunset the product, we pivoted, we ran out of runway. From your auditor's perspective in 2029, what happens?

Your auditor opens your evidence binder. They find:

• The receipt PDF — or JSON — issued in 2026 when the customer record was destroyed.
• The public verification key you stored at onboarding, with a chain-of-custody note saying when and how it was retrieved.
• Optionally, instructions on how to run the verification yourself (we publish the verifier in our public documentation).

The auditor runs the verification, which is a one-line operation in any modern programming language and takes a few milliseconds. The output is a yes or no. If yes, the receipt was issued by the holder of the private key on the date it claims, against the exact data it claims, and hasn't been altered since. The auditor checks the date, ticks the box, and moves on.

The fact that CIPH4 is gone is irrelevant. The auditor never tried to call us. Our existence was never part of the verification.

This is the difference between an attestation and a proof. An attestation says "trust me." A proof says "check for yourself." Audits prefer proofs.

The "but what if your private key leaked" question

The right follow-up question, and one that good auditors do ask, is: what if the vendor's signing key was compromised at some point? Couldn't someone have forged receipts?

The honest answer is: yes, in a key-compromise scenario, receipts signed during the compromise window would be suspect. That's why we treat the signing key with operational discipline appropriate to its evidentiary role: it's held in the platform's secrets manager with audited access, rotation procedures are documented internally, and any rotation is announced to customers in advance so the verifier-side public key can be updated alongside.

You can read the architecture in detail on our security overview. The short version is that the key-management discipline is part of what your auditor is evaluating when they review our SIG (security questionnaire) or our independent assessments. But the math of the receipt — the part that survives our company — doesn't depend on us being trustworthy in 2029. It depends on us being trustworthy in 2026, which is something you're already evaluating today.

What this means for your buyer-side evidence strategy

If you take one operational change away from this post, make it this one: add "vendor-independence of audit evidence" as a row in your vendor evaluation matrix. It belongs next to data residency, breach notification SLA, and subprocessor list. Score every vendor that produces compliance evidence on whether their evidence can be verified after they're gone.

In practice, that row will have three possible values:

• No — the receipt is a vendor-issued PDF or dashboard row with no independent verifier. (Most vendors.)
• Partial — the receipt includes a hash or signature, but verification requires the vendor's hosted tool. (Some vendors; this is better than nothing but still vendor-dependent.)
• Yes — the receipt is signed with a public-key pair, and the public key is available outside the vendor's infrastructure. (CIPH4, and a small number of others.)

The auditors and risk officers I talk to most about this — compliance leads at regional banks, privacy counsel at hospital systems, internal-audit teams at law firms with M&A practices — universally rank "yes" as a procurement requirement once they understand what they're being offered. It doesn't make sense for someone to spend an hour explaining the concept. It makes a lot of sense for a one-line addition to a checklist.

A few specific scenarios where this matters most

• Regulated retention windows that outlast vendor contracts. Healthcare compliance documentation — including evidence of disposal — must be retained for six years under HIPAA's documentation rule (45 CFR §164.530(j)). Financial-services records often run seven. Government contracts go further. Your evidence has to age longer than your vendor relationships.
• M&A transactions and clean-room dispositions. When a deal closes and a clean room is dissolved, the receipts proving each bidder's data was destroyed go into the closing binder and live there forever. The advising bank wants those receipts to be independently verifiable in case the dispute window opens five years later.
• Litigation hold releases. When a hold is lifted and data is destroyed under court approval, the receipt becomes the official record of what was destroyed and when. Court records outlive vendor contracts.
• Privacy-rights requests under GDPR Article 17 and CCPA. Regulators occasionally audit deletion requests years after the fact. Your customer has the right to know the deletion actually happened, and the regulator has the right to verify your records.

What to do next

Pull your current evidence stack and ask which artifacts depend on a vendor's continued existence to be verifiable in five years. The ones that do are technical debt; the ones that don't are durable proof. Spend a half hour on our verifier page to see what vendor-independent verification looks like in practice, then bring the question to your next vendor review — the answer tells you more about the maturity of the product than any compliance checklist.