🧠 GDPR Myths — Getting Data Out of Data Processor Applications

🤔 The mystery of projects: obligations are crystal clear on paper, yet somehow become foggy in practice.

📂 Availability & Access
❌ 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.
❌ 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.
❌ 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.
❌ 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.
❌ 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
❌ 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.
❌ 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.
❌ 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
❌ 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.
❌ 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.
❌ 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
❌ 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.
❌ 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.
❌ Why it’s Wrong ✅ Reality Check
Files often contain the richest personal data. Search attachments, uploads, and linked storage locations.
💰 Cost & Charge
❌ 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
❌ 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.
❌ 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
❌ Why it’s Wrong ✅ Reality Check
If you can reverse the pseudonymisation, it’s still personal data. True anonymisation is irreversible — rare in practice.

🔒 Data Masking Techniques; Compliance Matrix for your back pocket (click-2-expand)

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