consent-record

---
name: consent-record
description: Builds the evidence file that shows, for every address you email, who agreed, when, what they were shown at the time and how they agreed, plus the withdrawals. Use when you need to prove you were allowed to send it, or before you send to a list you inherited.
---

# Prove you were allowed to send it, on the day somebody asks

You give this your sign-up forms, your booking system's guest records, the paper sheets from the bar, and whatever spreadsheet your list currently lives in. You get back a consent register with one row per address per purpose, a dated folder of the exact forms and scripts people saw, a suppression file of everyone who has said no, and a plain list of the addresses you cannot evidence at all. The last file is the one that matters, because it is the one you must stop sending to.

## What it does

1. **Write down the five things a record has to show before opening a spreadsheet.** Article 7(1) of the UK GDPR says "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data." The ICO turns that into five headings you must be able to produce: **who** consented, by name or other identifier; **when** they consented, as a dated document, an online timestamp, or for spoken consent "a note of the time and date which was made at the time of the conversation"; **what they were told at the time**, meaning "a master copy of the document or data capture form containing the consent statement in use at that time, along with any separate privacy policy or other privacy information, including version numbers and dates"; **how** they consented; and **whether they have withdrawn consent: and if so, when**. Five columns, not one. A register with a "consented" tick and nothing else fails on four of them.

2. **Snapshot every form, sheet and script in use, and date the snapshot.** The third heading is the one businesses never have, because forms get edited and the old wording disappears. Save a PDF or screenshot of each live sign-up point today, name it `form_<point>_v1_2026-09-14.pdf`, and store it beside the register. Cover the booking widget's marketing tick, the wifi portal screen, the gift voucher checkout, the paper sheet on the bar, the wording your staff say when they ask at the till, and the privacy notice each one links to. From now on, every time one of those changes, save a new version and start a new version number. The ICO's failing example is exact about why: keeping "the time and date of consent linked to an IP address, with a web link to your current data-capture form and privacy policy" is not good enough, because a link to the current form is not evidence of the old one.

3. **Build the register as one row per address per purpose, never one row per person.** Consent under the UK GDPR "should be specific and granular, so your records also need to be specific and granular to demonstrate exactly what the consent covers". A guest who agreed to the monthly newsletter did not agree to text messages, and a guest who agreed to hear about the restaurant did not agree to hear about the sister hotel. Columns: email, name, purpose (for example "marketing email, this venue"), route (consent, soft opt-in, or corporate subscriber), date, form or script version, how (ticked box, clicked link, replied to email, said yes on the phone), collection point, withdrawn (yes or no), withdrawn date, source system. Two purposes means two rows.

4. **Record a soft opt-in differently from a consent, because it needs different evidence.** Consent needs proof of an affirmative act. The soft opt-in needs proof of four other things: that you took the address directly from that person, that it happened during a sale or negotiations for a sale, that the marketing is for your similar products and services, and that an opt-out was offered both at collection and in every message since. So a soft opt-in row carries a transaction reference or booking reference in place of a tick, plus the version of the checkout or booking flow that showed the opt-out. If you cannot produce the transaction reference, you have an assumption rather than a record.

5. **Mark what you cannot evidence, and never reconstruct it.** Work through the list and put every address into one of three buckets: evidenced, evidenced but thin, or not evidenced. "Not evidenced" is the correct answer for most inherited lists, business cards, a spreadsheet a previous manager built, and anything that arrived from a third party without paperwork. Do not date a row from the booking system's record-created field and call it a consent date; the record was created when the table was booked, which is not the same event. The ICO's own failing example is "You keep a spreadsheet with 'consent provided' written against a customer's name." A reconstructed record is worse than no record, because it is a false statement you would have to stand behind.

6. **Treat every withdrawal as its own dated event, and keep it after the address is gone.** People "have the right to withdraw his or her consent at any time" and "It shall be as easy to withdraw as to give consent". When someone unsubscribes, write the date into the register, move the address to the suppression file, and keep it there. The ICO is direct about this being lawful: "keeping a suppression list isn't for direct marketing purposes. You are keeping this list so that you can comply with your statutory obligations". Keep only what is needed to recognise them again, usually the address and the date. Its worked example shows why deleting is the mistake: a company deleted an objector's number, later bought a screened list that contained it, called them again, and "has breached PECR".

7. **Record what you tell people, because the record has to contain it.** A consent request must as a minimum include "the name of your organisation and the names of any other controllers who will rely on the consent", why you want the data, what you will do with it, and "that people can withdraw their consent at any time". CAP Code rule 10.2 adds the list that must be provided when you collect personal data, including the retention period and the right to object. Store the privacy notice version alongside the form version so the pair can be produced together, and write the retention period into the register header rather than leaving it undefined.

8. **Set a review date and a refresh rule, and put both in the file.** The ICO says consent "does not last forever" and that how long depends on the relationship, and separately, "If in doubt, we recommend you consider refreshing consent every two years". For third-party consent it is firmer: "we generally recommend that you should not use consent for direct marketing that was given via a third party more than six months ago". Write a review date into every row, defaulting to two years from the consent date and six months for anything that arrived via a third party. A register with no review date silently ages into a register of stale permissions.

9. **Produce the four artefacts and one page for the owner.** `consent-register.csv` with the columns above. A `forms/` folder holding the dated version of every form, script and privacy notice. `suppression.csv` holding address, date, channel, and nothing else. `not-evidenced.csv` holding every address you cannot stand behind, with the single reason. The page says how many addresses are evidenced, how many are not, what the three fastest fixes are, and the one sentence the owner would say if a recipient asked where they got their address. If that sentence cannot be written for a given address, that address belongs in `not-evidenced.csv`.

## Then it checks

1. Every evidenced row carries all five ICO headings: who, when, what they were told (as a named file version), how, and the withdrawal status, with no heading left blank.
2. Every form, script and privacy notice referenced in the register exists as a dated file in the `forms/` folder, and no row points at a "current" version of anything.
3. No consent date was inferred from a record-created date, an order date, a first-seen date or any other system field that records a different event, and no row was filled in from memory.
4. Every address appears in exactly one of the register, the suppression file or the not-evidenced file, and the three counts add up to the total address count.
5. Every soft opt-in row names a transaction or booking reference and the version of the flow that showed the opt-out at collection, rather than a tick.
6. Every row carries a review date, set at two years by default and six months for anything obtained through a third party.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never write a consent date, a wording or a method you did not read off a system or a document. The register's whole value is that every line in it is a statement you could repeat to a regulator, and one guessed date makes the other nine hundred unreliable.
- Never delete an unsubscribe. Suppression is what stops the same person being re-added next time a list is imported, and the ICO's own example shows a deletion causing the breach it was meant to prevent.
- Never merge two purposes into one row to make the file tidier. Granular records exist so that you can show what the consent actually covered, and a merged row proves consent to neither.
- Never treat a signed privacy policy, a ticked terms and conditions box or an unticked opt-out as evidence of consent. The ICO rules out "pre-ticked boxes, opt-out boxes, default settings or a blanket acceptance of your terms and conditions", so a row resting on any of those belongs in the not-evidenced file.
- This output is a working document prepared for the owner's solicitor or data protection adviser to check before it is relied on. It assembles and labels evidence against published guidance; it is not legal advice and it is not a finding that your consent is valid.

## Built from
- Information Commissioner's Office, "How should we obtain, record and manage consent?", UK GDPR guidance, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/consent/how-should-we-obtain-record-and-manage-consent/, no publication date shown on the page, read 14 September 2026: Article 7(1), the five record headings in step 1, the failing and passing examples in steps 2 and 5, the granularity requirement in step 3, and the two-year refresh in step 8.
- Information Commissioner's Office, "Respect people's preferences", https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/respect-peoples-preferences/, no publication date shown on the page, read 14 September 2026: the suppression rule and the deleted-number example that shapes step 6 and the second rule.
- Information Commissioner's Office, "Plan direct marketing", https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/plan-direct-marketing/, latest update shown 20 August 2025 on the sibling pages, read 14 September 2026: the five soft opt-in requirements behind step 4, and the six-month limit on third-party consent in step 8.
- The Privacy and Electronic Communications (EC Directive) Regulations 2003, regulation 22, https://www.legislation.gov.uk/uksi/2003/2426/regulation/22, in-force text carrying amendments commenced 5 February 2026, read 14 September 2026: the statutory wording of the soft opt-in limbs that step 4 requires evidence for.
- Committee of Advertising Practice, CAP Code (Edition 12), Section 10 "Use of data for marketing", https://www.asa.org.uk/type/non_broadcast/code_section/10.html, no publication date shown on the page, read 14 September 2026: rule 10.2's list of what must be told at collection, and rule 10.12 on withdrawal being as easy as consent, which together shape step 7.

# consent-record

## You are given

A folder containing whatever the owner has: exported CSVs from a booking system, an EPOS or a mailing tool; screenshots or PDFs of sign-up forms, wifi portals and checkout pages; photographs of paper sign-up sheets; a privacy notice; and a plain-text note naming each collection point and the date its wording last changed. Column names will be inconsistent and dates will be in mixed formats.

## Produce

Write these into an `output/` folder beside the inputs.

1. `consent-register.csv`, UTF-8 with a header row, one row per email address per purpose. Columns in this order: `email`, `name`, `purpose`, `route`, `consent_date`, `form_version`, `method`, `collection_point`, `source_file`, `source_row`, `withdrawn`, `withdrawn_date`, `review_date`. `route` is one of `consent`, `soft_opt_in`, `corporate`. `method` is one of `ticked_box`, `clicked_link`, `replied_email`, `verbal`, `paper_form`, `transaction`. Dates are `YYYY-MM-DD`. `review_date` is `consent_date` plus two years, or plus six months where `collection_point` names a third party.
2. `not-evidenced.csv`, same first four columns plus `reason`, listing every address that cannot fill all of `consent_date`, `form_version` and `method` from a source file.
3. `suppression.csv`, columns `email`, `date`, `channel`, and nothing else.
4. `forms/`, holding every supplied form, screenshot or script copied and renamed `form_<collection_point>_v1_<YYYY-MM-DD>.<ext>`, using the date from the owner's note.
5. `summary.txt`, under 300 words: total addresses, counts in each of the three files, the five most common reasons in `not-evidenced.csv`, and the three collection points producing the most unusable rows.

## Rules

- Never write a value into `consent_date`, `method` or `form_version` that is not read from a supplied file. Leave it empty and send the row to `not-evidenced.csv`.
- Never use a record-created, order, first-seen or last-updated field as a consent date.
- Never merge two purposes into one row.
- Every output row must carry `source_file` and `source_row` so any value can be traced back.
- The three files must partition the input: every distinct address appears in exactly one of them, and the counts must sum to the distinct address count. State both numbers in `summary.txt`.
- Do not contact anyone, do not send anything, and do not modify the input files.

## Return

The five paths written, the row count of each CSV, the partition check as `distinct_addresses = register + not_evidenced + suppression` with both sides shown, and any input file you could not parse, named with the reason.