GDPR and consent in practice: data you may actually use

What Module 8 settled, and what it didn't

Lesson 8.2 already taught the email rules properly: lawful basis per audience, what valid consent looks like, the soft opt-in and its four conditions, double opt-in, unsubscribe handling, and a retention rule for your list. If your memory of those is soft, reread it — this lesson assumes it and will not repeat it.

But email is one table in a larger inventory. Your marketing also holds enquiry-form submissions, order histories, analytics identifiers, ad-platform audiences, call transcripts — and now, after Lesson 11.2, whatever your AI workflows touch. GDPR governs all of it, and "we're too small for GDPR" is not a thing: the regulation applies from the first record, though a few of its bookkeeping duties scale with size, as we'll flag. This lesson generalises what you learned for email into a single whole-business picture, built as a table you fill in once and maintain.

Personal data is wider than you think

Personal data is any information relating to an identifiable person. Not just names: email addresses, phone numbers, IP addresses, cookie and device identifiers, order histories, a voice on a call recording, free-text in a form. If it can be linked to a person — directly or combined with other data — it counts, and holding or using it is processing, which needs a lawful basis.

One category deserves special respect: special category data — health, beliefs, sexuality, and similar — carries stricter rules. A physiotherapy clinic's enquiry form brushes against this by design, which is why Tomas features below.

Lawful bases beyond the inbox

GDPR offers six lawful bases. Three do the work in marketing:

• Consent — defined tightly, as Lesson 8.2 taught. The basis for marketing email to prospects, and for non-essential cookies.
• Contract — processing needed to deliver what someone bought: shipping an order, sending a booking confirmation. Not a marketing basis, but much of your data was collected under it.
• Legitimate interests — the flexible one, and the most abused. It requires a documented balancing test: your interest, weighed against the person's rights and reasonable expectations, written down before you rely on it. It can support things like fraud prevention, some B2B outreach in some member states, or postal mail. What it cannot do — the expensive confusion Lesson 8.2 already flagged — is override the ePrivacy consent requirement for electronic marketing. "Legitimate interest" typed into a form field with no test behind it is not a basis; it is a hope.

Where the right basis genuinely depends on national rules or sector — B2B outreach being the classic case — say so in your inventory and check before acting. Uncertainty written down is compliance work; uncertainty ignored is exposure.

Minimisation and retention, across the whole stack

Two principles from Lesson 8.2 now apply everywhere:

Minimisation — collect what the purpose needs. Storkflow's seven-field demo form from Module 4 was a conversion problem; it is also a minimisation problem. Every field is data you must protect, justify and eventually delete. The question "would we still ask this if each answer cost us €10 a year to store safely?" is a good proxy for the legal one.

Retention — every data store needs a rule with a number in it, and someone who applies it. Your email sunset policy from Lesson 8.6 is one such rule; you owe the same to form submissions, exports on laptops, call recordings and ad audiences. "We keep everything forever, just in case" is the answer that fails audits and, more practically, turns every future breach into a bigger one.

When someone exercises their rights

People hold rights over their data: access, rectification, erasure, portability, objection, and restriction. You will eventually receive a request, and what you need is a procedure, not goodwill. The deadline is one month, extendable in complex cases; the request can arrive informally, in any words, on any channel — "delete everything you have about me" in a reply email counts.

Here is what answering one actually looks like, at Herzog scale. A past patient emails exactly that sentence. Tomas's procedure:

1. Confirm identity — reasonably, without demanding a passport for a newsletter deletion. Replying to the address he holds on file is usually proportionate.
2. Locate her data — his inventory (below) tells him where to look: MailerLite, the Tally enquiry form, the booking records.
3. Delete what marketing holds — she leaves the email list; her enquiry-form entry goes. Her address stays on the suppression list, so the deletion itself is provable and she is never accidentally re-imported — Lesson 8.2's suppress-don't-delete logic, which coexists with erasure because keeping that minimal record is how the request stays honoured.
4. Explain what stays, and why — her clinical records are not marketing data. Health-record laws require clinics to retain them for years, and a legal obligation overrides the right to erasure for exactly that data. He tells her so, plainly.
5. Reply within the month, in writing. He answered in twelve days, and the whole thing took forty minutes — because the inventory existed.

The right to erasure is real but not absolute. The skill is knowing which of your data falls to it and which lawfully stays — and being able to say so without bluffing.

Cookies, pixels, and consent that happens before

The cookie rule generalises the email rule: non-essential cookies and trackers — analytics, advertising pixels, retargeting — may only fire after opt-in consent. Not alongside the banner; after the choice. "By using this site you agree" is not consent, pre-ticked boxes are not consent, and a banner that loads GA4 and the Meta pixel while the visitor is still reading it is decoration on a violation. Ostara's Shopify banner does this correctly — which is why its pixel sees roughly 60% of sessions, a cost of doing this lawfully that Module 9 already priced in.

There is a legitimate alternative path: consent-free, cookieless analytics. Storkflow's Cloudflare Web Analytics from Module 4 stores no personal identifiers and needs no banner — trading depth for simplicity, a strategy rather than a downgrade. National cookie guidance differs in details (banner design, what counts as essential), so if you operate mainly in one country, read its authority's guidance once.

Processors, agreements, and where your data actually lives

Almost nothing on your list is processed on your own hardware. Your ESP, your analytics tool, your form builder, your ad platforms — each is a processor, handling personal data on your instructions, and each needs a data processing agreement (DPA) in place. For mainstream tools this is usually a signature or a checkbox in settings — but it is your job to know it exists, and where the data is hosted. Transfers outside the EU/EEA need a lawful mechanism; EU hosting, where offered, is the simpler answer.

And now the clause your AI workflows created. Pasting customer data into an AI tool is disclosure to a processor like any other — except that consumer chatbot accounts typically come with no DPA, no business terms, and settings that may allow your input to train the model. Tomas learned this the uncomfortable way: he had pasted three patients' names and appointment details into a free chatbot to draft reminder messages. Patient identity plus appointment detail is health-adjacent data in a consumer tool with no agreement — a genuine incident, not a technicality. The fix was boring and complete: a neutral message template with {first_name} merge fields in his ESP, no personal data near the chatbot. Lena's rule from Lesson 11.1 is the general form: customer data goes only into an AI account with a signed DPA and training on your data switched off — and only the minimum the task needs. Strip names when the summary doesn't need names. Usually it doesn't.

Tomas's inventory

Four rows of Tomas's table, showing the method:

Front-desk email list (~230) — consent, wording on file, MailerLite (DPA accepted), retention per the M8 sunset rule. Clean. Tally enquiry form — name, phone, "what hurts", preferred clinic. Two findings: non-patient enquiries kept indefinitely since Module 4 → new rule, delete after 24 months; and "what hurts" pulls health detail into a marketing tool → the form now asks for a word, not a history ("brief — e.g. 'knee'; details at the clinic"). The chatbot incident — closed as above, and written into his AI SOP's checklist so it stays closed. Clinical records — outside marketing entirely, governed by health-record law; listed so the boundary is explicit.

No fines, no drama. An afternoon, a table, four fixes. That is what this looks like at small-business scale — which is the point.

Now build yours.

---