Checkout carries a tick box reading "I agree to you processing my data to fulfil my order". Four months in, 61 customers have used the preferences page to withdraw that permission, and the fulfilment job is now skipping their open orders. What was the design mistake?

What is being tested

Whether you treat the lawful basis as a design input with runtime consequences rather than wording that the legal team owns. The basis you pick decides what your code must be able to do when the customer changes their mind.

The mechanism

Consent under the GDPR comes with a withdrawal right: Article 7(3) gives the person the right to withdraw at any time and requires withdrawal to be as easy as giving it. So choosing consent creates a hard runtime obligation: a path that stops the processing, everywhere, on request.

Shipping a parcel cannot stop on request, because the customer is owed the parcel. That is the signal that the processing was never consent-shaped. Article 6(1)(b) covers processing necessary to perform a contract with the person, and the EDPB's Guidelines 2/2019 make necessity an objective test rather than something a contract clause can assert.

The tick box did three things, all bad. It asserted consent for processing the business will carry out regardless, which makes the consent not freely given in the sense Article 7(4) describes when a service is conditional on consent it does not need. It created an obligation the system then half-honoured. And it produced 61 records that look, to an auditor, like a system ignoring withdrawals.

Why the other options fail

• "Refuse the withdrawal after shipping." If the basis is consent, withdrawal cannot be made harder than consenting. Blocking it is a second violation stacked on the first, and it is the version a regulator notices because the refusal is in the product.
• "Pre-tick the box." Pre-ticked consent is not a valid expression of agreement, and the mistake is upstream of the default: no box belongs here at all.
• "Keep processing and ignore the flag." This is the common production shortcut. It makes the stated basis a fiction while the consent record exists as written evidence against you, and it converts a paperwork error into a demonstrable one.

What to build instead

Record the basis per purpose, on the record, as data: fulfilment on contract necessity, marketing on consent, fraud checks on legitimate interests, tax records on legal obligation. Each purpose then gets the control its basis implies, and the one consent flag that used to gate everything disappears. The test before adding a consent surface is simple: if the answer to "we stop" is "we cannot stop", consent is the wrong basis.

When not to use consent

Consent is the right basis for the things you genuinely would not do if asked not to: marketing sends, optional analytics, non-essential cookies, enrichment from third parties. It is the wrong basis where processing is necessary to deliver the contract, where the law requires you to keep the data, or where the relationship is so unequal that refusal has a cost, as in employment. The simpler architecture usually has fewer consent gates and more purpose records, because every consent gate is a withdrawal path somebody has to build and keep working.