Consent records: how to prove you had permission years later

What does a provable consent record contain?#

A provable consent record contains six facts that someone else can check: the person or account, the exact wording presented, the date and time, the channel, the action taken and any later withdrawal or change. If one is missing, the record shows that something happened but not what was agreed.

The wording is the element most often lost. A CRM field that says opted in, with a date, does not show what the person was told they were opting in to. To prove scope you need the form, page or contract text that was live on that date, kept as a versioned document.

• 1Identity: the contact, user or customer account the permission belongs to.
• 2Wording: the version of the checkbox text, terms of service, order form or notice shown.
• 3Timestamp: when the action happened, recorded by the system rather than typed in later.
• 4Channel: web form, in-app clickwrap, signed contract, email reply or recorded call.
• 5Action: what the person did, such as ticking a box, signing or clicking accept.
• 6Changes: withdrawals, unsubscribes, amendments and replacement agreements.

Consent, notice and contract permission leave different trails#

Consent is only one way permission is documented, and in B2B companies it is often not the main one. Permission to use customer records may come from a master services agreement, a data processing addendum or terms of service the customer accepted. A privacy notice tells people how data will be used, but it is not the same as their agreement.

Each source leaves its evidence in a different system, with its own typical gap. Knowing which source applies to a record set tells you where to look first.

Where do business systems store the evidence?#

Business systems store consent evidence in pieces, so assembling it usually means pulling from three or four places. A CRM or marketing platform typically holds the current subscription or opt-in status on the contact record. Check whether yours keeps a history of changes or only the latest value, and whether it records the source form.

Notes, calls and emails attached to a contact can hold the rest of the story, and they do not always come out with a standard export. HubSpot's documentation, for example, says activities such as calls and notes must be exported with a separate method from the standard record export.

Help desks and chat tools add another trap. Zendesk lets admins create ticket deletion schedules that keep deleting matching archived tickets, and deleted tickets cannot be restored. Slack keeps messages for the life of a workspace by default on paid plans, but admins can set deletion periods, and deletion is permanent. Check these settings before assuming the history exists.

How to rebuild a consent trail for older records#

Rebuilding a consent trail means matching each record to the permission in force when it was created. Work by cohort rather than by individual: customers who signed up under the same terms version share the same proof.

• 1Fix the record set and the date range you need to support.
• 2Collect every version of the terms, privacy notice and order form used in that period, with go-live dates.
• 3Fill gaps in version history from CMS revisions, code repositories, legal files and public web archives.
• 4Group accounts by the version they accepted, using sign-up or contract dates.
• 5Pull negotiated contracts for large accounts, since their terms may override the standard form.
• 6Record withdrawals, unsubscribes and terminations that take records out of scope.
• 7Write a short permissions memo listing each cohort, its proof and its gaps, and have counsel review it.

Why you cannot fix old permission by changing terms now#

Changing terms today does not create permission for records collected under older terms, and doing it quietly can add risk. FTC staff warned on February 13, 2024 that a company adopting more permissive data practices, such as using consumer data for AI training, and telling people only through a surreptitious, retroactive change to its terms or privacy policy may be engaging in unfair or deceptive practices.

The safer course is usually to carve out records whose permission cannot be proven and to apply any new terms only to records created after customers accept them. Updated terms then build a cleaner cohort going forward instead of trying to rewrite the past.

How long should consent records be kept?#

Consent records should be kept at least as long as you rely on the permission they prove, and then for as long as a complaint, audit or contract claim could reach back. Counsel can set the outer limit for your industry and the laws that may apply.

The working rule is that proof must outlive the data it supports. If records from a given year are licensed, the terms and notices that covered them need to survive for the life of the license and after it ends. Put consent evidence under its own retention rule or legal hold rather than letting it follow the deletion schedule of the system it came from.

Illustrative: a software company proves permission for its support history#

Illustrative: a fictional vertical software company sells scheduling software to commercial cleaning firms. It runs Intercom for chat support, HubSpot for marketing and Salesforce for contracts, and its terms of service have changed several times since launch. Leadership wanted to know whether de-identified support conversations could be licensed.

The privacy lead pulled every terms version from the website repository's history and matched accounts to the version accepted at sign-up. Most accounts had accepted terms that allowed aggregated, de-identified use of service data. An early cohort had accepted terms silent on the point, and several enterprise customers had negotiated strict confidentiality clauses.

The company kept the first group in scope, excluded the early cohort and the negotiated accounts, and documented each decision in a permissions memo that counsel reviewed. No terms were changed retroactively.

How SourceX treats consent evidence#

SourceX handles consent evidence in the Rights step of the SourceX five-step transaction, before any preparation or delivery. The supplier identifies which permission covers each record set, and records that cannot be supported are left out rather than argued in.

The result is summarized in the SourceX Evidence Packet, which records provenance, licensing rights, permitted use, the privacy record and release authorization. Buyers increasingly expect this kind of record; the Data & Trust Alliance's Data Provenance Standards include an element for the location of consent documentation. The underlying logs and contracts stay with the supplier.