Update: October 2026
A consent request asks someone to agree to the use of their personal data. If it is vague, bundled with other terms or hard to understand, the consent it produces is invalid, and so is any processing that relies on it.
This guide covers what a request must say, how to word it, which opt-in methods work, and what to record. It draws on Article 7 of the GDPR, the ICO’s UK guidance, and the EDPB’s Guidelines 05/2020 for the EU.
• A consent request must be prominent, concise, in plain language and separate from other terms. Article 7(2) says a request made within a broader written declaration must be clearly distinguishable from other matters.
• At a minimum, the request names your organisation and any other controllers relying on it, states each purpose, explains what you will do with the data and says people can withdraw at any time. The EDPB adds the type of data, automated decision-making where relevant, and the risks of transfers without an adequacy decision or safeguards.
• Consent needs a clear opt-in, a record of who agreed to what and when, and a withdrawal route that is as easy as giving consent. Pre-ticked boxes, silence, and blanket acceptance of terms don’t count.
The ICO says consent requests must be prominent, concise, easy to understand, and separate from other information, such as general terms and conditions. It builds on Article 7(2) of the GDPR, which requires that a request that forms part of a wider written declaration be presented in a way that is clearly distinguishable from other matters, in an intelligible and easily accessible form, using clear and plain language.
The EDPB takes the same position in its Guidelines 05/2020 on consent. Information needed to decide whether to consent cannot be hidden in general terms and conditions. If you request consent electronically, it must be separate and distinct, not buried in the terms.
In practice, this means a dedicated checkbox, screen or form field, written for the people who will read it. Use simple language, avoid legal jargon and avoid confusing wording such as double negatives. Use the same wording and method across your different consent options. If the audience includes children, write so that a child can understand it, and consider age verification and parental authorisation. Our guide to children’s data under GDPR and the digital age of consent covers those rules.
Consent has to be specific and informed. The ICO sets out the minimum content: your organisation’s name 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 consent at any time. It is good practice to say how to withdraw.
Naming matters. The ICO says consent for categories of third-party controllers isn’t specific enough, and that if you buy in consented data, consent is valid for your processing only if you were specifically identified. You do not need to name processors in the request, but you must still meet your transparency duties under Articles 13 and 14.
The EDPB lists six items as the minimum for consent to be informed: the controller’s identity, the purpose of each processing operation, what type of data will be collected and used, the existence of the right to withdraw, information about automated decision-making under Article 22(2)(c) where relevant, and the possible risks of data transfers where there is no adequacy decision and no appropriate safeguards under Article 46. The EDPB guidelines are no longer directly relevant to the UK regime, and the ICO describes them as helpful guidance on certain issues only. UK organisations can use them as a reference point. Organisations serving EU individuals should treat them as the standard to follow.
A consent request does not replace privacy information. You must still give people the information required by Articles 13 and 14, and both the ICO and the EDPB say this does not all have to sit inside the consent request itself. The EDPB notes that valid informed consent can exist even when not every Article 13 or 14 item appears at the point of asking, as long as those points are covered elsewhere, such as in the privacy notice.
This allows a short request with more detail one click away. The ICO also suggests just-in-time notices, which appear on screen when a person enters the relevant data and briefly explain how it will be used. A just-in-time notice must be combined with an active opt-in and should not unduly disrupt the user.
There is a limit. Recital 32 says electronic consent requests must not unnecessarily interfere with service use. The ICO says this is not an exemption: avoiding disruption does not override the need for a clear, specific request, and some disruption may be needed to obtain valid consent.
The two requests below are illustrations written for this guide. They are not model clauses.
A weak request reads: “By continuing, you agree to us using your information for marketing and to share it with our partners.” It bundles purposes, does not name the partners, relies on continuing to use the service and does not mention withdrawal.
A stronger request reads: “Tick this box if you want Example Ltd to email you about new products and offers. You can unsubscribe at any time using the link in every email or by changing your preferences in your account. We will not share your email address with other companies.” It names the organisation, states one purpose, describes the processing, requires a tick, and explains how to withdraw.
If you want to share data with named third parties, ask for a separate opt-in for each one. The ICO says people should not be forced to agree to all or nothing, and that you should provide a separate opt-in for each purpose unless you are confident it is appropriate to bundle them.
Whatever method you use must be an unambiguous indication by clear affirmative action. The ICO lists examples of active opt-in mechanisms: signing a consent statement on a paper form, ticking an opt-in box on paper or electronically, clicking an opt-in button or link online, selecting from equally prominent yes and no options, choosing technical or preference dashboard settings, replying to an email requesting consent, answering yes to a clear oral request, and volunteering optional information for a specific purpose, such as filling in optional form fields combined with just-in-time notices.
You cannot rely on silence, inactivity, pre-ticked boxes, opt-out boxes, default settings or blanket acceptance of terms and conditions. Recital 32 says silence, pre-ticked boxes or inactivity do not constitute consent. The ICO says opt-out boxes are essentially the same as pre-ticked boxes, and that using them to benefit from inaction is a warning sign about the quality of the consent.
Where you need explicit consent, for example for special category data, the opt-in needs an express statement. The ICO’s example is a tick box next to the wording “I consent to you using this information to recommend appropriate beauty products”, which is explicit, whereas simply filling in a form field is likely to be implied consent only. The statement should refer to the element of processing that needs explicit consent. Our guide to valid consent under GDPR explains the wider test.
Article 7(1) requires you to demonstrate that the person consented. The ICO says you need to keep an audit trail for as long as you rely on the consent. The records should show who consented, when they consented, what they were told at the time, how they consented and whether they have withdrawn.
The “what they were told” element is the one most often missed. Keep a master copy of the consent wording and the privacy information in use on that date, with version numbers. The ICO’s example of a poor record is a spreadsheet with “consent provided” next to a customer’s name. A better record is a copy of the signed, dated form, or online data with a timestamp linked to the form version in use. For oral consent, keep a note made at the time with the date, and the name and version of the script used.
Article 7(3) gives people the right to withdraw consent at any time and says withdrawal must be as easy as giving consent. The consent request must tell them about this right before they agree. The ICO’s example of a poor approach is consent given through an online form where withdrawal is only possible by phone. A good approach offers an online withdrawal route, such as an opt-out link on every page.
When someone withdraws, you must stop the processing that relied on that consent as soon as possible. The ICO says you cannot switch to a different lawful basis for the same processing, because telling people they have a choice and then continuing after they refuse is unfair. People must also be able to refuse or withdraw without detriment. Our guide to withdrawing consent explains the process in more detail, and our GDPR cookies guide covers the position on cookies.
Consent does not last indefinitely in the same form. The ICO says you should keep consents under review and refresh them if your purposes or activities change, because consent doesn’t evolve. If you are unsure whether a consent is still valid, refresh it. The ICO suggests refreshing every two years, with a longer or shorter interval where the context justifies it.
The ICO’s consent guidance pages carry a notice that they are under review because of changes made by the Data (Use and Access) Act 2025. Check the ICO’s page on planned guidance updates before relying on a specific passage, and keep an eye on any revised wording for the UK.
A consent request that follows these steps is short, specific, and easy to read, and it gives you evidence you can produce if a regulator or customer asks. The wording is what people see, so it is also where most invalid consents begin.
We are publishing this guide because the rules on consent wording have not changed in principle, while the supporting guidance has been revised. Review your live consent requests against the points above, and speak to our GDPR consultants if you want us to check the wording and records.
At a minimum, the ICO says it must include your organisation’s name and the names of any other controllers relying on the consent, why you want the data, what you will do with it, and that people can withdraw consent at any time. The EDPB also lists the type of data, automated decision-making where relevant and the risks of certain international transfers.
No. Article 7(2) requires a consent request to be clearly distinguishable from other matters, and the ICO and EDPB both say it must be separate from general terms and conditions. Blanket acceptance of terms does not constitute valid consent.
No. The ICO and the EDPB both say the consent request doesn’t have to include everything required by Articles 13 and 14. You must still provide that privacy information elsewhere, for example in a privacy notice linked from the request.
Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.