Skip to content

Privacy Pitfalls

These Are Not Theoretical

Every pitfall on this page has resulted in regulatory enforcement action, fines, or both. GDPR fines have exceeded 5 billion euros cumulatively since 2018. GE's methodology prevents these mistakes structurally, not by hoping agents remember.

The mistake: A single "I accept" checkbox that covers analytics, marketing, third-party sharing, profiling, and everything else.

Why it is wrong: GDPR Article 6 and Recital 32 require consent to be specific. Bundled consent is not freely given because the user cannot accept some purposes and reject others.

Regulatory consequence: Meta was fined 390 million euros in January 2023 for bundling consent with service terms.

GE prevention: Every processing purpose is a separate consent toggle. The user can accept service delivery but reject analytics. Consent records are purpose-specific with timestamps and policy versions.

Pitfall 2: Collecting Data "Just in Case"

The mistake: Collecting data you do not currently need because "we might need it for a future feature" or "the marketing team might want it later."

Why it is wrong: GDPR Article 5(1)(c) requires data minimization. Data collection must be adequate, relevant, and limited to what is necessary for the declared purpose. "Future unknown purposes" is not a valid basis.

GE prevention: Every data field requires a documented purpose and justification before it enters the schema. Julian reviews the data model before design approval. Fields without justification are rejected.

The cost of over-collection:

  • Larger attack surface (more data to breach)
  • Higher storage and processing costs
  • Greater compliance burden (more data to manage, export, delete)
  • Increased liability in a breach

Pitfall 3: Pseudonymization vs. Anonymization Confusion

The mistake: Claiming data is "anonymized" when it is only pseudonymized. Treating pseudonymized data as exempt from GDPR.

The critical difference:

Pseudonymized Anonymized
Can be re-linked to individual Yes, with additional data No, by any means
GDPR applies Yes, fully No
Example Replacing name with token Aggregating into statistical summaries
Reversibility Designed to be reversible Must be irreversible

Why it matters: If your "anonymized" data can be re-identified — through combination with other datasets, inference, or because the mapping table still exists — it is pseudonymized, and GDPR applies fully.

GE prevention: Julian reviews any claim of anonymization. True anonymization requires demonstrating that re-identification is not reasonably likely, considering all means reasonably likely to be used (GDPR Recital 26).

Pitfall 4: Dark Patterns

The mistake: Designing consent interfaces that nudge users toward sharing more data than they intend.

Examples of dark patterns:

Pattern Description Why It Is Illegal
Pre-checked boxes Consent checkboxes defaulted to "on" Not "unambiguous indication" (Art. 4(11))
Confirm-shaming "No, I don't want to save money" Manipulates free choice
Hidden decline "Accept" is a prominent button, decline is a text link Not equally easy to refuse
Forced continuity Free trial auto-converts with buried cancellation Lacks transparency
Nagging Repeated consent prompts until user gives in Not freely given
Trick questions Confusing double-negatives in consent text Not informed consent

Regulatory consequence: The Digital Services Act (DSA) explicitly prohibits dark patterns for online platforms operating in the EU. GDPR enforcement authorities have fined companies for pre-checked consent boxes and difficult-to-find opt-out mechanisms.

GE prevention: Consent interfaces follow clear design rules:

  • Accept and decline are equally prominent
  • No pre-checked boxes
  • Plain language descriptions of each purpose
  • Withdrawal is accessible from the same location as initial consent
  • Julian reviews all consent UIs before deployment

Pitfall 5: Legitimate Interest Overreach

The mistake: Using "legitimate interest" (GDPR Art. 6(1)(f)) as a catch-all legal basis to avoid asking for consent.

Why it is tempting: Legitimate interest does not require user interaction. No consent banners, no granular toggles.

Why it fails: Legitimate interest requires a documented balancing test (Legitimate Interest Assessment / LIA) that weighs:

  1. Is the interest legitimate? (Yes, usually)
  2. Is the processing necessary? (Often questionable)
  3. Does it override the rights of the data subject? (Often yes)

Common overreach: Using legitimate interest for:

  • Marketing emails to non-customers
  • Behavioral profiling for ad targeting
  • Sharing data with third-party analytics providers
  • Tracking users across websites

These almost always fail the balancing test.

GE prevention: Julian performs and documents a Legitimate Interest Assessment for every use of Art. 6(1)(f). When in doubt, use consent. Consent is harder to implement but safer legally.

Pitfall 6: Cross-Border Data Transfers

The mistake: Transferring personal data outside the EU/EEA without a valid transfer mechanism.

Why it happens: Cloud services, CDNs, analytics tools, and SaaS platforms are often US-based. Data flows there automatically.

Transfer mechanisms:

Mechanism Status Notes
EU-US Data Privacy Framework Active (since July 2023) Only for certified US companies
Standard Contractual Clauses (SCCs) Active Requires transfer impact assessment
Binding Corporate Rules Active For intra-group transfers only
Adequacy decisions Country-specific Check latest EC list

GE prevention:

  • Default to EU-based infrastructure (Hetzner, EU Azure regions)
  • Every third-party service reviewed for data residency
  • Julian documents the transfer mechanism for any non-EU processing
  • Transfer impact assessments performed for SCC-based transfers

The mistake: Loading Google Analytics, Meta Pixel, or similar tracking scripts before the user consents.

Why it is wrong: The ePrivacy Directive (implemented as national cookie laws) requires consent before placing non-essential cookies or similar tracking technologies on a user's device. GDPR provides the standard for that consent.

Regulatory consequence: French DPA (CNIL) has fined Google 150 million euros and Meta 60 million euros for cookie consent violations.

Common violations:

  • Loading tracking scripts in <head> before consent banner renders
  • "Cookie wall" that blocks content until consent is given
  • Consent banner with no "reject all" option
  • Scripts that fire on page load and retroactively check consent
  • "Essential cookies" category that includes analytics

GE prevention:

  • No tracking scripts load before explicit consent
  • Cookie consent follows the "reject all" + "accept all" + "manage" pattern
  • Only strictly necessary cookies load without consent
  • Server-side analytics (privacy-preserving) as the default
  • Julian approves the cookie classification

Pitfall 8: Forgotten Data Copies

The mistake: Deleting data from the primary database but forgetting it exists in backups, caches, search indexes, logs, data warehouses, exported reports, or third-party systems.

Why it matters: A right-to-delete request under GDPR Article 17 requires erasure from all systems. If the data resurfaces from a backup restore, the deletion was not effective.

Where data hides:

Location Risk Mitigation
Database backups Data restored from backup Deletion ledger replayed on restore
Application caches Cached responses serve deleted data Cache invalidation on deletion
Search indexes Deleted user still appears in search Index update on deletion
Log files PII in structured logs Log rotation + PII redaction
Data warehouse ETL pipeline copied the data Deletion propagated to warehouse
Exported CSVs/reports Downloaded by staff Data retention policy for exports
Third-party processors Shared via API Art. 17(2) notification to processors
Email/ticket systems PII in support conversations Deletion cascade includes support
CDN/edge caches Cached pages with user content Cache purge on deletion
Browser localStorage Client-side storage Clear on logout, no PII in localStorage

GE prevention:

  • Deletion registry defines every location where user data exists
  • Cascade delete covers all locations
  • Deletion verification job confirms data is gone from all stores
  • Backup restoration replays the deletion ledger
  • Third-party processors receive deletion notifications via API

The mistake: Repeatedly prompting users for consent until they give in, or making the product deliberately worse for users who decline consent.

Why it is wrong: Consent must be freely given. If declining consent results in a degraded experience or repeated nagging, the consent is not free.

GE prevention:

  • Consent prompt appears once
  • Declining consent results in no functionality loss for core service
  • Non-essential features that require consent are clearly labeled
  • No re-prompting unless the privacy policy materially changes

Pitfall 10: Ignoring Data Protection Impact Assessments

The mistake: Skipping the Data Protection Impact Assessment (DPIA) required by GDPR Article 35 for high-risk processing.

When a DPIA is mandatory:

  • Systematic and extensive profiling with significant effects
  • Large-scale processing of special categories (health, biometric)
  • Systematic monitoring of publicly accessible areas
  • New technologies with unknown privacy impact
  • Automated decision-making with legal or significant effects

GE prevention: Julian triggers a DPIA when processing meets Article 35 criteria. The DPIA is completed before processing begins. Results are documented and reviewed by human (Dirk-Jan) when high residual risk remains.

Quick Reference: Agent Checklist

Before submitting code that handles personal data:

  • [ ] Legal basis identified for every processing activity
  • [ ] Only necessary data collected (data minimization verified)
  • [ ] Retention period defined and automated
  • [ ] Consent is granular, specific, and withdrawable
  • [ ] No dark patterns in consent UI
  • [ ] Pseudonymization applied at earliest point
  • [ ] Encryption at rest and in transit
  • [ ] Right to delete implementable across all data stores
  • [ ] Third-party data sharing documented with DPA
  • [ ] Cross-border transfers have valid mechanism

Further Reading