Show the consent they gave

A customer says they never agreed to a purpose your product is still using. Tonight, alone, three things. Confirm the request is from that person. Open the live product, in an account you administer, and show the text that person was shown, the affirmative act, and when it happened. Then withdraw that purpose yourself, or write that you cannot, and that the withdrawal is not as easy as the act was. If any of the three needs the person who built the product, you have not demonstrated consent. You have sent a message asking someone else to remember.

The file you would hand them is a different object. Hand one customer their file produces a copy of what you hold about that person, and it excludes the next person. A copy of stored rows does not show the words they were asked to accept. Correcting one wrong fact is correct one customer's wrong fact: you change a field they say is inaccurate, and you name the copies that still have the old one. Erasing the account is when a customer asks to be deleted. Erasure makes the question disappear by making the person disappear, which is an answer they did not ask for when they said the agreement was never theirs. Closing registration before a stranger can sign up is what to prove before public signup. That drill is a door. This one is the record of a door someone already walked through. A later request to stop marketing email is not this record. Show the unsubscribe they sent is the request, the next send, and a different person who is still on it. Agreement to a purpose is not proof you left them off a campaign. None of this is legal advice. The regulation quoted below defines which processing it covers. A page on a vendor's site does not decide that for your company, and it does not replace the lawyer who reads your terms.

People describe a choice they do not feel they control, and the number is a feeling about a banner, not a count of records you failed to keep. The UK Information Commissioner's Office commissioned Savanta to run the Public Attitudes on Information Rights Survey 2025. The online portion is a 15-minute survey of 8,019 members of the UK public, fieldwork 10 January to 21 February 2025, weighted to the UK adult online population by age, gender, ethnicity, region, disability, and socio-economic status. A separate telephone survey of 500 adults with very low or no digital familiarity ran on overlapping dates. Those 500 are a different sample. Do not fold their percentages into the 8,019. On "consent or pay," the online report's question Q5b, base all 8,019 respondents, asks what people typically did in the last 12 months if they were shown a choice to access a site free with personalised ads and cookies, or to pay. The printed answers: 37% typically chose the free option with personalised ads and cookies, 19% typically left without selecting either, and 7% usually paid to remove personalised cookies (Information Commissioner's Office, Public Attitudes on Information Rights Survey 2025).

Read the base before you borrow the rate. Q5b's base is every online respondent, not only people who had seen such a banner. 37, 19, and 7 sum to 63. The paragraph does not print the other answers, so the three you can quote do not add to 100, and you should not invent a remainder to force them there. A later sentence says nine in ten (89%) claim at least some understanding of the options, and that just over two in five (42%) have some understanding and are not entirely sure what the options mean. The report presents the 42% as the more detailed cut, not as a second survey. It does not print an arithmetic that makes 42 a slice of 89, so do not manufacture one. The executive summary says only one in five feel informed (19%) and in control (19%). It prints both figures. It does not say they are the same people. Sceptical is 24%, pressure 17%, frustration 16%. Those are feelings about a choice the researchers described and about the prior year. They are not a count of consent logs, not your users, and not a finding that a paywall fails a legal test. Awareness of the right the survey calls informed consent is a different line: 48% of the online population say they are aware of it, up from 44% in 2024. Awareness of a right is not a record that a named person agreed. Savanta ran the fieldwork. The ICO commissioned it. Neither one sells you a settings screen.

The definition the slogan compresses is four conditions, and a pre-ticked box fails them before you ever store a row. Regulation (EU) 2016/679, Article 4(11): "'consent' of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her" (EUR-Lex, Regulation (EU) 2016/679). Freely given, specific, informed, unambiguous. The indication is a statement or a clear affirmative action. Recital 32 says consent should be given by a clear affirmative act, and it names examples: a written statement, including by electronic means, an oral statement, ticking a box, choosing a technical setting, or other conduct that clearly indicates acceptance. Then the line people skip: "Silence, pre-ticked boxes or inactivity should not therefore constitute consent." Consent should cover all processing for the same purpose, and when there are multiple purposes, "consent should be given for all of them." A single click that bundles the account, a marketing list, and a model vendor has not become specific by being one click.

Consent is one lawful basis, and it is not the one you reach for because the settings page had a spare toggle. Article 6(1) says processing is lawful only if and to the extent that at least one of the listed bases applies. Article 6(1)(a) is that the person "has given consent to the processing of his or her personal data for one or more specific purposes." Article 6(1)(b) is different: processing necessary for a contract they are party to, or for steps they asked for before that contract. The demonstration duty in Article 7 opens with "Where processing is based on consent." If the account exists because they bought a plan, the record you may need is the contract, not a checkbox you added so the privacy page looks complete. Article 7(4) is the pressure test inside consent, and it is narrower than a survey mood: when assessing whether consent is freely given, "utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract." A product that will not create the account unless the person also agrees to a purpose the product does not need is the shape that sentence names. The 17% who felt pressure in the ICO survey are not that test, and this page does not decide which of your purposes are necessary.

What you have to be able to show, when the basis really is consent, is Article 7 itself. Article 7(1): the controller "shall be able to demonstrate that the data subject has consented to processing of his or her personal data." Article 7(2): if consent sits inside a written declaration that also concerns other matters, the request "shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language." Any part of that declaration which infringes the regulation is not binding. The terms of service and the consent are not the same paragraph. Article 7(3): the person may withdraw consent at any time. Withdrawal "shall not affect the lawfulness of processing based on consent before its withdrawal." Before they give it, they are informed of the right to withdraw. "It shall be as easy to withdraw as to give consent." A click that takes a second, and a withdrawal that takes a support ticket and a deploy, has failed the last sentence even if the first click was real.

The board that reads Article 7 for regulators tells you what the record contains, and it refuses a screenshot of today's website. The European Data Protection Board's Guidelines 05/2020 on consent say Article 7(1) puts "the burden of proof" on the controller. The regulation "does not prescribe exactly how this must be done," and the controller must still "prove that a data subject in a given case has consented." The duty should not become an excuse to collect more personal data than the link requires. Paragraph 108's online example is the one to build: retain "information on the session in which consent was expressed, together with documentation of the consent workflow at the time of the session, and a copy of the information that was presented to the data subject at that time." The next sentence is the trap: "It would not be sufficient to merely refer to a correct configuration of the respective website" (EDPB, Guidelines 05/2020 on consent, version 1.1, adopted 4 May 2020). Today's banner is today's banner. The guideline also says there is no specific time limit in the regulation for how long a consent lasts, and that if the processing changes or evolves considerably, the original consent is no longer valid and a new one is needed. Withdrawal need not be the same gesture as the grant. Paragraph 114 is the practical line: where consent was one mouse-click, swipe, or keystroke, the person must in practice be able to withdraw "equally as easily."

If the person in the email is a child, stop before you run the adult drill. Article 8(1) applies where Article 6(1)(a) is the basis and you offer an information society service directly to a child. Processing is lawful where the child is at least 16. Below that age it is lawful "only if and to the extent that consent is given or authorised by the holder of parental responsibility." Member States may set a lower age by law, "provided that such lower age is not below 13 years." Those numbers are the regulation's ages for that clause. They are not a finding that your product is an information society service, and they are not a finding about a child who wrote to you. This page does not decide the age, the parent, or the service. Get advice before you store anything further about that account. Do not manufacture an adult consent row on a child's login and call the three proofs done.

Do the three proofs in one sitting, on the live product, with a second browser that is not your admin session. First, the request. You can point at the signal that convinced you it is them: a reply from the address on the account, a session they started, a method you already published. A forwarded screenshot from a stranger who knows their email is not that signal. Write the purpose they dispute and the date you received the mail. Second, the record. As an administrator you can reach, open that person only. The page shows the text they were shown, not the text you would show a new signup this afternoon. It shows the act: a tick, a statement, a setting they changed. It shows when. Load the product the way they would. The purpose on their screen and the purpose in the stored text are the same, or you write that they differ. Third, withdrawal. You turn that purpose off, yourself. The next action that needed it does not run. The path is not an email to the vendor and not a ticket in a tracker you do not administer. If withdrawal takes a deploy only the author can make, the third proof has failed, and you say so before you tell them the agreement is in order.

Three moves that feel like a demonstration and are a second problem. Asking the model inside the product to "remember that they agreed," which edits a prompt and leaves the table empty. Pasting the record into a chatbot so it can draft the reply, which puts the session and the text into a vendor you did not have this morning. Ticking the box now, inside their account, because the row is missing. That last one is you consenting. It is not them, and it is not a reconstruction. Article 7 asks you to demonstrate a consent that happened. A consent you perform after the complaint is a new event, and it should be labelled as one if a lawyer tells you a fresh agreement is even available. Changing every account's banner because the tool you were given has no single-person path is an outage for the people who did not write to you.

The path you wanted was built when the product learned to open one account without opening the next. Gigbase is a multi-tenant workspace with subscription plans and role-based access for agencies, admins, and team members, and a dedicated admin dashboard. The shape that matters here is an admin, in an account you administer, who can open one person's stored record while the others still sign in. That case is not a consent story. Nothing in the description is a consent log, a headcount, a duration, or a result figure. If the only control on the admin screen rewrites every profile from a prompt, or emails the vendor, you do not have a demonstration. You have a paragraph and a waiting list.

There is a version of this email where hiring someone to build the record is the wrong purchase. No customer has said they never agreed, and no customer can yet, because nobody is using the product. You have no product, so there is no text to show and no withdrawal to perform. You are still choosing who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top saas development company. That page is criteria. It does not rank anyone, including us. The processing you actually do sits on a contract, and a checkbox would be theatre beside it. A customer has already seen another customer's data. A missing consent row does not close a leak. The person is a child, and the question is whose agreement the regulation would even ask for. Or you wanted a lawyer to tell you whether the regulation covers you. Hire the lawyer. A repository does not answer that, and neither does this page.

When the request is real and the record is missing as a control, the missing object is specific. An admin action, in an account you administer, that shows one person's text, act, and time, and that lets you withdraw that purpose without a deploy. A startup software development company that expects this will have put that action next to the rest of the account admin, before a stranger could agree to a purpose you might later have to stand behind. One that needs a call in order for you to see what your own screen asked is telling you who holds the agreement. The accounts that had to be in your name before this email arrived are the handover you must receive. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include one consent you can show and withdraw yourself. If you do not yet have customers, and the question is whether the systems you have could store the text at all, a two-week AI readiness assessment hands you the findings either way. The findings are yours. They are not a promise that a regulation applies, and they are not a rate.

Before you answer the customer, do the three proofs and write the date. Confirm it is them. Show the text they were shown, the act, and the time, and look at the live screen the way they would. Withdraw the purpose yourself, or write that you cannot and that the two paths are not equally easy. Do not ask a model to remember an agreement, and do not tick the box for them. The screen is how you notice which words are still up. The page where you list the session, the text, and the withdrawal is the page you can defend.