How do you prove consent was given?

short answer

A defensible consent record captures four things a typical record omits: the verbatim disclosure text as displayed, the identity of every party the data was going to, the site's terms and privacy policy exactly as they read that day, and a timestamp bound to all of it so nothing can be changed afterwards without detection. A database row saying consent equals true, next to a page that has since been redesigned, proves a submission — not an agreement.

What most records contain

Open almost any CRM and the consent evidence looks like this:

consent_given: true
consent_timestamp: 2024-03-12T14:22:09Z
ip_address: 203.0.113.44
source_url: /quote-form

This establishes that something was submitted from an address at a time. It does not establish what the person read, who they agreed could contact them, or what the site’s terms said. Two years later, when those things are the entire question, the record cannot answer it.

The four things that make a record defensible

1. The verbatim disclosure, not a reference to it. Store the exact words displayed, and ideally a hash of them. A pointer to “disclosure template v3” is worthless once v4 exists and v3 was not archived.

2. Every party the data was going to. “Our marketing partners” invites the obvious question. If a list of recipients was shown, record that list as it was at that moment, so a later addition is detectable rather than deniable.

3. The terms and privacy policy as they read that day. The rules in force when someone agreed are part of what they agreed to. Sites change their policies quietly and often. A snapshot, content-hashed, closes an argument that is otherwise unwinnable.

4. Integrity that does not depend on your word. If your evidence is “our database says so,” the other side’s position is “your database could say anything.” Records that can be independently recomputed — hashes over canonical facts, an append-only log, external anchoring — move the dispute from trust to arithmetic.

Why screenshots and session replay fall short

Session recording is genuinely useful. It shows what a session looked like, and for fraud investigation that is valuable.

But it has three limits worth knowing:

It is custodial. Verifying it means asking the vendor holding it to vouch for its own record.
It is human-readable only. A person can watch it; software cannot check it. That matters increasingly as agents and automated systems fill forms.
It captures appearance, not commitment. A replay shows a checkbox being ticked. It does not, by itself, fix the disclosure text, the recipient list, and the site’s terms into a single tamper-evident commitment.

The strongest position uses both: a recording for what happened, and a recomputable record for what was agreed.

Retention

Keep consent records at least as long as your longest realistic exposure window. For TCPA purposes the statute of limitations is four years, and disputes surface late. Records that were deleted on a two-year retention schedule have a habit of being the ones you needed.

Retention also means surviving vendor changes. If your evidence lives only in a platform you might leave, plan the export before you need it — not during the migration.

The test

Ask of any consent record: could a carrier, a regulator, or opposing counsel verify this without our cooperation?

If the answer is no, the record’s strength is exactly equal to your credibility at the moment it is questioned — which is generally the moment your credibility is under attack.

General information, not legal advice.