GDPR (General Data Protection Regulation)
An EU regulation effective May 2018, applying directly and uniformly across member states (no national transposition needed) to any organization processing EU residents’ personal data, regardless of where that organization is based. It builds on the same notice, choice, access, and security baseline described in Fair Information Practices, but GDPR’s consent, rights, and default-setting requirements are what actually shape an interface.
GDPR’s consent, rights, and default-setting requirements are what actually shape an interface.
Ground every processing activity in a lawful basis, and don’t over-ask for consent
GDPR permits processing only under one of six lawful bases: consent, contract necessity, legal obligation, vital interests, public task, or legitimate interests. Consent is only one of these — if a contract or a legal obligation already justifies collecting something, asking for consent on top of it is both unnecessary and, per the “freely given” requirement below, potentially invalid, since a consent request implies the customer has a genuine choice to refuse. A consent interface (a cookie banner, an onboarding toggle) should ask only about the processing that genuinely rests on consent as its basis, and give plain notice — not a consent request — for everything else.
Design consent as active, specific, and reversible
GDPR’s definition of consent sets four conditions a consent mechanism has to meet:
- Freely given — refusing can’t cost the customer access to the service (no “consent walls”), and consent to processing the service doesn’t need can’t be made a condition of it, such as a checkout that won’t complete until the customer agrees to have their details shared with partner retailers. An incentive for opting in can be fine; a penalty for opting out isn’t.
- Specific — one toggle per purpose, not one box covering marketing, analytics, and third-party sharing at once.
- Informed — what’s collected, why, who receives it, and for how long, stated before the customer decides, not after.
- Unambiguous — an active opt-in (a click, an unchecked-by-default box someone deliberately checks, a yes/no choice with both options equally prominent).
Withdrawing consent has to be exactly as easy as giving it: if opting in was one click, opting out can’t be buried three settings screens deep or require contacting support. The regulation’s own text names the specific mechanism that satisfies “unambiguous”: “ticking a box when visiting an internet website” is its own worked example of a clear affirmative act, while silence, a pre-ticked box, or mere continued use of the site explicitly do not count as consent at all — not just weak consent. The request itself is also constrained: when consent is asked for electronically, the request “must be clear, concise and not unnecessarily disruptive to the use of the service” — a standard that applies to the interruption a consent prompt causes, not only to what the prompt’s controls do.
Withdrawing consent has to be exactly as easy as giving it: if opting in was one click, opting out can’t be buried three settings screens deep or require contacting support.
Word the consent request so it can actually be understood
A consent request that technically asks the right question can still be invalid if the customer can’t tell what they’re agreeing to:
- Name who’s asking — the organization itself, plus any third parties that will rely on the same consent.
- Keep it separate and plain — prominent, concise, kept apart from the terms and conditions, and in plain language. Vague or sweeping wording invalidates consent, and so do double negatives or inconsistent terms that leave the customer unsure which answer means yes.
- Layer it instead of front-loading it — layered information and just-in-time requests, asked at the moment a feature needs the data, keep a request from disrupting the experience. But avoiding disruption never excuses an unclear request.
- Make explicit consent an express statement — for sensitive categories such as health data, an optional form field the customer happens to fill in isn’t enough. Put a statement such as “I consent to you using this information to…” next to a box they tick.
Ask again when the purpose changes
Consent doesn’t stretch to cover a new purpose, even a closely related one: if the data will be used for something the original request didn’t name, ask again or find a different lawful basis. Consent also fades over time without a fixed expiry date, so refresh it at intervals that make sense to the customer. If a withdrawal couldn’t actually be honored (for example, because deleting the data would break a research study), consent was the wrong basis to rely on in the first place.
Surface the full set of data-subject rights, not just erasure
GDPR’s rights go well beyond the basic access principle in Fair Information Practices:
- Erasure — deletion of the customer’s data under certain circumstances, such as a “delete my account” action that actually removes what’s held rather than just deactivating it.
- Portability — a copy of the data the customer provided, in a common format they can take to another service.
- Access — a full account of what’s held, why, its source, and who it’s shared with (typically an account-page “your data” export).
- Rectification — editable fields, plus a way to flag an inferred attribute as wrong.
- Restriction — pause processing during a dispute without deleting the data outright.
- Objection — an always-available opt-out for legitimate-interest-based marketing.
- A right against solely-automated decisions — Article 22 gives a person the right not to be subject to a decision made by an algorithm alone (credit, hiring, pricing) when it has legal or similarly significant effects on them. It allows one only where the decision is necessary for a contract, authorized by law, or based on the person’s explicit consent. Even then, in the contract and consent cases the person must be able to get human intervention, give their own view, and contest the outcome. Either way, people must be told when automated decision-making is being used.
Default to the most private setting
Article 25’s Privacy by Design and by Default requirement means privacy has to be built into a product from the start, not patched on after launch, and that default settings already sit at the most privacy-protective option — non-essential toggles off, non-essential cookies not loaded until consent is given, profile visibility private until the customer chooses otherwise. The customer should have to opt in to less privacy, never opt out of more.
The customer should have to opt in to less privacy, never opt out of more.
Nothing about the account itself changed between the two panels — only which state the toggles started in before the customer touched anything.
Notify quickly after a breach
A breach must be reported to the relevant supervisory authority within 72 hours of discovery, unless it’s genuinely unlikely to risk anyone’s rights or freedoms. Affected individuals must be told directly, “without undue delay,” whenever the breach poses a high risk to them — unless the exposed data was encrypted or pseudonymized well enough that whoever has it can’t actually read it, which is itself a design reason to encrypt sensitive data at rest.
Know when a DPO or impact assessment is required
Large-scale systematic monitoring (behavioral tracking, broad analytics), large-scale processing of sensitive categories (health, biometric, criminal-record data), or public-authority status each trigger a requirement to name a Data Protection Officer and publish their contact details, and to complete a Data Protection Impact Assessment before launching the processing — relevant to any product built around recommendation engines, ad targeting, or biometric login.
Related Concepts
Patterns
- Privacy Policy
- Privacy Preferences
- Account Management
- Cookie Consent Banner
- Passwordless Authentication
Principles
Standards
Sources
General Data Protection Regulation (Wikipedia) (CC BY-SA) is this page’s source for the six lawful bases, the four consent conditions (freely given, specific, informed, unambiguous), the data-subject-rights list (including erasure and portability), the Article 25 default-setting requirement, and the 72-hour breach-notification deadline above.
Regulation (EU) 2016/679 — General Data Protection Regulation (EUR-Lex official text) is the official regulation text itself, cited directly for Recital 32’s exact consent-mechanism wording (the “ticking a box” example, the pre-ticked-box exclusion, and the consent-request disruptiveness standard) in the Design consent section above, and for Article 22’s exceptions and safeguards for solely automated decisions.
What Is Valid Consent? (ICO) (OGL v3.0) is the UK regulator’s guidance on the same consent test, which the UK GDPR keeps unchanged. It is the source for the bundled-consent checkout example, the incentive-versus-penalty distinction, equal-prominence choices as a valid opt-in, and both Word the consent request so it can actually be understood and Ask again when the purpose changes.