The classic trap
Article 11 looks like a gift to the controller: if you do not need to identify the data subject, you are not required to acquire additional data just to comply with the GDPR. The trap is that CNPD and CNIL strictly scrutinise the demonstration of that impossibility: too many organisations invoke Article 11 to deny access rights on logs, cookies or pseudonymised data without being able to technically prove they cannot re-identify. The EDPB has clarified that reversible pseudonymisation does not fall within Article 11, and the burden of proof lies entirely on the controller.
The 4 cumulative conditions to validly invoke Article 11
- Genuine purpose: processing does not, or no longer, requires identification (aggregated statistics, product telemetry, anonymised analytics).
- Demonstrable technical impossibility: you hold no re-identification key, no mapping table, no exploitable pivot identifier, even by cross-referencing with reasonably accessible datasets.
- Information to the data subject: you must inform the data subject of that impossibility, where possible (mention in the privacy notice, motivated answer to the requester).
- Reopening of rights if the subject provides additional information: if the user supplies their session ID, cookie ID or hash, you must reactivate Articles 15 to 20.
The pseudonymised data trap
Many organisations confuse pseudonymisation with anonymisation. A SHA-256 email hash, a cookie ID, a device fingerprint, an advertising identifier remain personal data under Recital 26. Article 11 does not apply here. The EDPB test is strict: if you, or any third party reasonably mobilisable, can trace back the person, then you are in a position to identify and Article 11 falls away.
How Luxgap automates this risk
Our Luxgap Re-Identification Probe makes Article 11 bluffing impossible by measuring, on your real datasets, the mathematical probability of re-identifying a person through cross-referencing. The tool connects read-only to your data lakes (Snowflake, BigQuery, Azure Synapse, AWS Redshift, S3), your analytics exports (GA4, Matomo, Mixpanel, Amplitude) and your pseudonymised databases to compute an identifiability score aligned with EDPB Opinion 04/2007 and WP216 on anonymisation.
- Computes for each table a k-anonymity, l-diversity and t-closeness score, and flags residual quasi-identifiers (ZIP code + date of birth + gender = 87% re-identification per Sweeney).
- Detects dormant mapping tables that contradict an anonymisation claim (hash key stored in another schema, Hashicorp vault, S3 backup).
- Simulates re-identification attacks by cross-referencing public datasets (commercial register, LinkedIn, voter rolls) to materialise residual risk.
- Generates a motivated Article 11 qualification memo, defensible before CNPD, distinguishing anonymous, pseudonymised and identifiable processing dataset by dataset.
- Produces an automated workflow for rights requests: if the user provides their additional identifier, the tool reactivates Articles 15 to 20 and notifies the DPO within 24h.
- Cryptographically seals each assessment (eIDAS qualified timestamp) as binding evidence in case of audit.
Available as a complement to a Luxgap DPO mandate or as a dedicated SaaS module depending on your data perimeter. Request a tailored quote and our teams will prepare a demonstration on your real datasets, with a free 48h scan to measure your identifiability score before any commitment.
