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

What teams usually forget

• A simple map of the data. No one writes down which fields are collected, where they go next, and who can see them. Then an audit comes and support somehow has access to card details (hint: they shouldn’t). A one-page flow saves hours of guesswork.
• Clear legal reasons for each use. “Ask for consent for everything” feels safe but is often wrong. Billing relies on the contract; customer support relies on what’s necessary to deliver the service; advertising needs explicit permission. Mixing these creates risk and confusion. 
• Collect only what you need. Twelve fields in a form look serious, but half are unnecessary. Extra data raises storage costs, breach impact, and work when users ask for copies or deletion. Each field needs a clear purpose and a lifespan.
• Retention and real deletion. “Keep it, just in case” leads to immortal databases—and immortal backups. A user asks to be deleted, but their data still lives in logs and snapshots. You need rules and automation for what gets removed, when, and where.
• User rights without the drama. Requests like “send me my data” or “erase me” arrive unexpectedly. Without a process, teams improvise formats, dates, and responsibilities. This should take minutes, not days. 
• Cookies and tracking that actually respect choice. Show a banner, but also split tracking: technical events needed for the site to work vs. marketing that only runs after permission. If you don’t separate them, numbers wobble and risk grows. 
• Access inside the team. “Give everyone admin so nothing blocks us” is a trap. More access means higher chance of mistakes and harder investigations. Give each person only what they need and record important actions.
• Encryption and secret handling. Keys in plain files, unencrypted backups, real emails in test databases—classic pitfalls. Protect data “in transit” and “at rest,” secure backups with their own keys, and store secrets outside code. 
• Vendors and services. Emailing, analytics, payments—great, but where are the data stored and what have you agreed on? Keep a list, define responsibilities, and know the storage locations. It makes due diligence painless.
• An incident plan for the first hours. When something goes wrong, people ask “who does what?” instead of solving the problem. You need roles, contacts, a first-hours checklist, which logs to check, and ready-to-send notices.

How we do it

•  Start with a short data brief and a simple flow. We interview the team: why each piece of data exists, who sees it, and how long it lives. Then we draw a one-page flow—collect → store → access → delete. Everyone understands it: devs, managers, and legal.
• Write down the reason for every operation. Billing → contract. Support → necessary for the service. Ads → only after permission. This isn’t paperwork for its own sake; it makes team decisions fast and defensible.
• Design forms and events for “just enough.” We remove “maybe later” fields. For analytics we run two sets of events: the ones required for the site to function, and everything else that only starts after permission. Results stay honest, risk stays low.
• Right-sized access with an audit trail. Each person gets the minimum they need. Services use separate accounts. Important actions are recorded. Disputes and investigations become quick and clear.
• Protect data in motion and at rest. Encryption is on by default. Backups are protected with separate keys. Secrets live in a secure store, not in the repo. It’s boring—and it’s what saves you.
• No real personal data in tests. Developers and QA use synthetic or anonymized datasets. Real data stays in production and only for the few who truly need it.
• Retention rules and automatic cleanup. We set lifespans per data type and automate deletion or masking—backups and logs included. “Right to be forgotten” becomes real, not aspirational.
• Transparent partners. We keep a living list of every connected service: what it does and where it stores data. Each one has clear obligations for protection. Audits go faster, nerves stay calmer.
• Fast, predictable user requests. We prepare formats and buttons in admin: export and full deletion take minutes. The team doesn’t argue about CSV vs. JSON—this was decided earlier. 
• A first-hours incident playbook. Named owners, on-call contacts, step-by-step actions, and message templates. When something happens, we don’t invent a process—we execute one.

Mini-case: subscriptions + partner program + analytics

We split events: what’s needed for the service runs immediately; marketing and retargeting only after consent. Partner tags don’t merge into a user profile without permission. Profiles are minimal. Export and deletion are built into admin from sprint one.
 
Outcome: honest analytics, calmer audits, and no “rip out the foundation” six months later.

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 permission, 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 hours if something goes wrong?

What you get

• Architecture with privacy built in, not bolted on.
• Lower legal and reputational risk; smoother partner audits.
• Room to scale without reopening walls.