Sensitive Data & GDPR: Plain, Practical, and Built In

Common GDPR Compliance Gaps in Web Projects

Most development teams treat GDPR as a legal checkbox — something to handle after launch. But by the time a user requests "delete my data" or a partner sends an audit questionnaire, the architecture isn't ready. These are the gaps we see most often, and they're not edge cases — they show up in nearly every project that didn't plan for privacy upfront.

Nobody maps the data

GDPR Article 30 requires a Record of Processing Activities — but even if you ignore the legal requirement, you need to know what you collect. Which fields go into which tables? Who can access them? Where do they end up (backups, logs, analytics, third-party services)?

We've seen projects where customer support had access to payment card details simply because nobody drew a data flow diagram. A one-page map — collect → store → access → delete — saves hours of guesswork during audits and incident response.

Legal basis confusion

"Ask consent for everything" sounds safe, but it's often wrong — and it creates real risk. GDPR defines six legal bases for processing data. The three that matter most in web projects:

• Contract: billing, order fulfilment, account management. No consent needed — the contract is the basis.
• Legitimate interest: fraud detection, basic analytics for service improvement. Requires a balancing test, not consent.
• Consent: marketing emails, retargeting, non-essential cookies. Must be freely given, specific, informed, and revocable.

Mixing these up means you might ask for consent where it's not needed (annoying users) or rely on consent where you should use a contract basis (making your processing fragile — users can withdraw consent anytime).

Retention: "keep everything forever"

GDPR Article 5(1)(e) — the storage limitation principle — says you can only keep personal data as long as it's needed for its purpose. "Keep it just in case" is not a valid purpose. Yet most databases we audit have no retention rules at all.

The hard part isn't the database — it's backups, logs, and third-party services. A user asks to be deleted, you clear the main table, but their data still lives in last month's backup, in application logs, and in your email marketing platform. Real deletion requires automation across all storage layers.

The rest of the checklist

• User rights without drama. "Export my data" and "delete me" requests should take minutes, not days. Build export and deletion buttons into your admin panel from sprint one.
• Cookies and tracking that respect choice. Show a cookie banner, but also split tracking: technical events needed for the site to function vs. marketing that only runs after consent.
• Team access and audit trails. "Give everyone admin" is a trap. Least-privilege access + logged actions = faster investigations and fewer mistakes.
• Encryption at rest and in transit. TLS for transport, AES-256 for storage, separate keys for backups. Secrets belong in a vault, not in your repository.
• Vendor inventory. Every third-party service that touches personal data needs a processing agreement. Keep a living list: what each service does, where it stores data, what it guarantees.
• Incident playbook. GDPR Article 33 requires notifying the supervisory authority within 72 hours of discovering a breach. You need named owners, on-call contacts, a first-hours checklist, and ready-to-send notification templates.
• Data minimization in forms. Twelve fields look serious, but half are unnecessary. Each field increases storage cost, breach impact, and work when users request copies or deletion.

Privacy by Design: How We Build It In

Privacy by design isn't a checklist you bolt on after development. It's an architectural principle — every component that touches personal data has rules from day one. Here's what that looks like in practice.

Data brief and flow diagram

Before writing code, we interview the team: why does each piece of data exist, who sees it, how long should it live? The output is a one-page flow diagram — collect → store → access → delete — that developers, managers, and legal all understand.

Every processing operation gets a documented legal basis. Billing → contract. Support → necessary for service delivery. Marketing → consent only. This isn't paperwork for its own sake — it makes decisions fast and defensible when questions come up.

Consent-aware event architecture

We split analytics into two streams from the start: technical events that the site needs to function (page loads, error tracking, performance metrics) run immediately. Marketing and retargeting events only fire after the user opts in.

This is a clean architectural decision, not a hack. The consent state controls which event listeners are active. When consent is withdrawn, marketing events stop — no data leaks, no "we'll clean it up later."

Automated retention and cleanup

We define retention lifespans per data type and automate deletion. Soft-deleted records get permanently removed after 30 days. Session data expires after the legal minimum. Backups rotate on a fixed schedule with the oldest copies purged automatically.

The "right to be forgotten" becomes a real operation — not an aspirational checkbox. Export and full deletion are admin panel buttons that work in minutes, including propagation to connected services.

The rest of our approach

• Right-sized access with audit trails. Each person gets minimum required permissions. Services use separate accounts. Important actions are logged.
• No real data in test environments. Developers and QA use synthetic or anonymized datasets. Real personal data stays in production, accessible only to those who need it.
• Transparent vendor management. We maintain a living list of every connected service: what it does, where it stores data, what protection it guarantees.
• Predictable user request handling. Export formats and deletion procedures are decided upfront. The team doesn't argue about CSV vs. JSON when a request arrives — this was settled during architecture.

Case Study: Subscription Platform with Partner Program

A SaaS platform with paid subscriptions, a partner referral program, and marketing analytics. The challenge: partners needed to see conversion data, marketing wanted full-funnel tracking, and users expected their profiles to stay minimal.

We split events into two streams. Service-critical events (subscription lifecycle, payment status, partner attribution) ran immediately. Marketing events (page engagement, retargeting pixels, campaign tracking) only activated after consent. Partner tags were attributed at the transaction level — they never merged into user profiles without explicit permission.

Export and deletion were built into the admin panel from sprint one. A full data export took under 30 seconds. Complete deletion — including propagation to the payment processor and email platform — took under two minutes.

Result: analytics discrepancies dropped by roughly 40% because unconsented pageviews were no longer polluting the data. Audit preparation went from two weeks of scrambling to a two-day routine. Six months in, the partner program scaled to 50+ partners without any privacy architecture changes.

Kickoff checklist (save this)

1. Why do we need each data point and which metrics truly matter?
2. Which form fields are mandatory — and which can we drop?
3. What do we collect before consent, and what only after?
4. Who in our team and among contractors can see which data?
5. Where is encryption applied? Where do backups live? Who can see logs?
6. When and how do we delete different data types (including backups)?
7. Do we have a clear, fast process for "export my data" and "delete me"?
8. Where do our partners store information physically, and what do they guarantee?
9. What exactly happens in the first 72 hours if something goes wrong?

What you get

• Architecture with privacy built in, not bolted on.
• Lower legal and reputational risk — fines under GDPR can reach €20 million or 4% of annual global turnover.
• Smoother partner audits and shorter compliance cycles.
• Room to scale without reopening walls.