GDPR: Myths&Facts | IainToolin

Click icons to expand each subtopic

🌍 GDPR & Local Variations — What Actually Changes?

Click on the icons to expand the core principles that are consistent across the EU and UK GDPR. The differences appear where the Regulation lets countries add their own flavour. Below are the common areas where you’ll see local rules — with practical “what to do” notes.

🔒 What stays identical everywhere

Principles: lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity & confidentiality, accountability.
Rights: access, rectification, erasure, restriction, portability, objection, and rights around automated decisions/profiling.
Roles: controller vs processor, DPIAs for high risk, breach notification logic, records of processing (RoPA) in many cases.

⚖️ Where countries can (and do) differ

Employment data — extra rules for HR/works councils (e.g., Germany’s BDSG §26).
What to do: check local labour law + any collective agreements before rolling out global HR analytics.
Age of digital consent — EU allows 13–16 (state chooses); UK is 13.
What to do: align parental consent and age-gating per country; don’t hardcode one age globally.
Freedom of expression / journalism — exemptions differ (e.g., media/archives).
What to do: confirm local carve-outs before handling takedown/erasure against news or archive content.
Health, genetic, biometric data — often stricter or with extra safeguards/approvals.
What to do: apply country-specific lawful bases, retention, and access controls for special-category data.
Criminal offence data — usually requires a legal basis in local law or authority oversight.
What to do: avoid processing without an explicit local-law hook and governance sign-off.
Public sector & archives — different rules for official records, statistics, and research.
What to do: check public-task bases and archiving exemptions before setting deletion schedules.
ePrivacy/cookies — enforced under national telecoms laws; consent UX expectations vary.
What to do: localise CMP behaviour (granular toggles, real refusal option, non-nudging design).

🇬🇧 UK GDPR vs 🇪🇺 EU GDPR (high level)

Framework — UK GDPR + Data Protection Act 2018; regulator is the ICO (not the EDPB).
Adequacy — EU permits data flows to the UK (subject to the EU’s adequacy decision).
Divergence — text is very similar today, but the UK can tweak reporting/record-keeping over time.
What to do: treat the UK as a separate jurisdiction in your RoPA, notices, and transfer assessments.

🚓 Enforcement realities (why it matters)

Supervisory authorities emphasise different priorities (adtech, children’s data, DSAR delays, etc.).
Fines & remedies vary in frequency and severity; some regulators are faster and more public than others.
What to do: build one global standard, then bolt on local controls where risk and law require it.

🧭 Implementation playbook (practical steps)

RoPA with locality — record processing by country (systems, purposes, data categories, bases).
Notices & consent — template globally, localise for age thresholds, special-category handling, and cookie UX.
DPIAs — run once per use case, then add country annexes for extra risks/controls.
Retention — global baseline, local exceptions where statutes or sector rules demand it.
DSAR operations — one playbook; include country rules for ID checks, redaction, and deadlines.
Cross-border transfers — map flows, apply SCCs/IDTAs as needed, and document transfer risk.
Training — same core module; short local add-ons for HR, health, or criminal-data specifics.

❓ Quick answers to common “local variation” questions

Do DSAR deadlines differ? Core rule (one month, extendable) is the same; practical expectations can vary by regulator.
Can I rely on legitimate interests everywhere? Yes in principle, but balancing tests can land differently by context and sector.
Is employee monitoring treated the same? No — works councils/collective agreements can add hurdles; consult local HR/legal early.
Are cookies the same across the EU? No — consent UX and enforcement stance differ. Localise your CMP.

🧠 GDPR Myths — Getting Data Out of Data Processor Applications

🤔 Click on the icons to expand the myth. . The mystery of projects: obligations are crystal clear on paper, yet somehow become foggy in practice.

📂 Availability & Access

📂 🚪 “The data isn’t available in the application, so we can’t give it to you.”

❌ Why it’s Wrong	✅ Reality Check
GDPR doesn’t excuse you because your tool can’t export it — the legal obligation overrides technical convenience.	Find a way: APIs, database queries, vendor-provided exports, or even screenshots if necessary.

📂 📊 “We only provide the data the application’s standard reports produce.”

❌ Why it’s Wrong	✅ Reality Check
Limiting disclosure to built-in reports ignores the right of access to all personal data held.	Personal data is any data relating to an identifiable person — not just what’s in your canned reports.

📂 🗺️ “We can’t export without you telling us the exact tables and fields.”

❌ Why it’s Wrong	✅ Reality Check
The controller/processor must know their own data schema — users shouldn’t reverse engineer your system.	Maintain a Record of Processing Activities (ROPA) and data map so you can extract without user-supplied table specs.

📂 🆔 “We’ll give you the database dump — but it’s in code/IDs, so that’s enough.”

❌ Why it’s Wrong	✅ Reality Check
If identifiers need lookups to be meaningful, those lookups are part of the personal data.	Include reference data and explain codes so the requester can understand their data.

📂 🔍 “The API doesn’t expose that field, so we can’t provide it.”

❌ Why it’s Wrong	✅ Reality Check
API limitations are a tooling choice — not a legal basis to withhold data.	Use backend access, database queries, or vendor engineering support.

🛡️ Security & Legal Duties

🛡️ 🔐 “If we export everything, we’d breach security.”

❌ Why it’s Wrong	✅ Reality Check
Security measures are to prevent unauthorised access — they don’t block lawful access by the data subject or controller.	Apply secure transfer, lawful redaction, and proper authentication — but still deliver the data.

🛡️ 🤝 “We’re just the processor — this is the controller’s problem.”

❌ Why it’s Wrong	✅ Reality Check
GDPR Article 28 gives processors direct obligations to assist the controller in meeting data subject rights.	Work with the controller to fulfil requests; your contract should reflect this.

🛡️ 🖊️ “We can withhold data if it’s mixed with other people’s data.”

❌ Why it’s Wrong	✅ Reality Check
Mixed records must be separated or redacted — not withheld entirely.	Use redaction tools or splitting to protect others’ rights.

🗄️ Retention & Scope

🗄️ 🗄️ “We only keep data for 90 days, so we can’t help.”

❌ Why it’s Wrong	✅ Reality Check
If you delete data outside a documented retention schedule, you risk non-compliance.	Retain per the agreed retention policy; deletion must be lawful, proportionate, and documented.

🗄️ 📏 “We can refuse because the request is too broad.”

❌ Why it’s Wrong	✅ Reality Check
Requests can be narrowed for practicality, but “too broad” isn’t an automatic opt-out.	Engage with the requester to scope, but still meet your legal duties.

🗄️ ⏳ “We can’t provide historic versions — only the current record.”

❌ Why it’s Wrong	✅ Reality Check
GDPR covers data at the time of the request, but past versions may be relevant for some rights.	Where held, provide historical data or note lawful deletion.

📑 Format & Structure

📑 📄 “We can’t send raw data because it’s not in a user-friendly format.”

❌ Why it’s Wrong	✅ Reality Check
GDPR doesn’t require pretty output — only that it’s intelligible to the requester.	Provide CSV, XML, JSON, or plain text — plus a key or explanation if needed.

📑 🗃️ “We only handle structured data — unstructured is out of scope.”

❌ Why it’s Wrong	✅ Reality Check
GDPR covers all personal data, whether in a database, PDF, audio file, chat log, or sticky note scan.	Search across structured, semi-structured, and unstructured stores.

📑 📎 “Attachments and uploaded documents aren’t part of the request.”

❌ Why it’s Wrong	✅ Reality Check
Files often contain the richest personal data.	Search attachments, uploads, and linked storage locations.

💰 Cost & Charge

💰 💰 “We can charge for the data export as a service.”

❌ Why it’s Wrong	✅ Reality Check
Under GDPR, the first copy must be free unless requests are manifestly unfounded or excessive.	Only charge in rare, justified cases — and be ready to prove it.

📊 Derived & Log Data

📊 🧮 “We don’t need to provide data created by the system.”

❌ Why it’s Wrong	✅ Reality Check
Personal data includes derived data, profiles, and inferred information about the person.	Include calculated scores, risk ratings, and other derived personal data.

📊 📝 “If the data is held in logs, we can ignore it.”

❌ Why it’s Wrong	✅ Reality Check
Logs often contain IP addresses, usernames, or actions — all personal data.	Search and redact as necessary, but logs are still in scope.

🕵️ Pseudonymisation

🕵️ 🕵️ “We’ve pseudonymised it, so it’s no longer personal data.”

❌ Why it’s Wrong	✅ Reality Check
If you can reverse the pseudonymisation, it’s still personal data.	True anonymisation is irreversible — rare in practice.

🛠️ Relevant techniques and how they contribute

🛡️ Compliance Quick Reference — Click to open

Quick reference for when you’re in a design review and someone says “but does it tick the GDPR / PCI / HIPAA boxes?” — here’s the answer without having to dig through 400 pages of legalese.

Technique	Type	Description	GDPR	PCI-DSS	HIPAA	ISO 27001
Encryption	Reversible	Transforms data with a cryptographic key; decryptable with the right key.	✔ Strong encryption meets Art. 32	✔ Req. 3 & 4	✔ Meets encryption safeguard	✔ Annex A.10.1
Tokenisation	Reversible	Replaces sensitive values with non-sensitive tokens stored in a secure vault.	✔ Pseudonymisation under Recital 26	✔ Alternative to encryption for card data	✔ Suitable for PHI de-identification	✔ Annex A.9 & A.18
Format-Preserving Encryption (FPE)	Reversible	Encrypts data but keeps original format (e.g., 16-digit card stays 16 digits).	✔ Meets pseudonymisation criteria	✔ PCI-approved method	✔ OK for HIPAA safe harbor	✔ Annex A.10
Deterministic Substitution	Reversible	Consistently replaces data with a mapped alternative from a lookup table.	✔ Pseudonymisation	✔ If applied to PAN before storage	✔ Meets limited data set criteria	✔ Annex A.14
Randomisation / Shuffling	Non-Reversible	Reorders or replaces data values randomly to break link to original subject.	✔ Full anonymisation	✔ Meets masking requirements	✔ PHI removal	✔ Annex A.18.1
Generalisation	Non-Reversible	Replaces specific data with broader categories (e.g., DOB → Year).	✔ k-anonymity compliance	✔ Allowed if PAN not stored	✔ Meets HIPAA de-identification	✔ Annex A.9.4
Noise Addition / Perturbation	Non-Reversible	Adds small, random changes to numeric values to preserve stats but hide identities.	✔ Differential privacy fit	✔ Works for PCI if no actual PAN	✔ OK for HIPAA safe harbor	✔ Annex A.18
Redaction / Nulling	Non-Reversible	Replaces with null, blanks, or partial masking (e.g., ****1234).	✔ GDPR display-only safe	✔ PCI display masking rule	✔ PHI display protection	✔ Annex A.9

⚖️ Not legal advice. Check your local policy interpretations and version of the standards.

You can check the GDPR rules here

Link to EU GDPR

Link to UK GDPR