Last week our compliance lead dropped a 40-page GDPR summary on my desk. Literally printed it out. I skimmed the first ten pages, then asked the only question that mattered: “What do we need to build?”
She didn’t have that answer. Nobody on the legal side did. That’s the gap with GDPR. Lawyers can draft policies all day, but those policies are worthless until engineering makes them real in production systems. At the fintech startup, we handle financial news data, user portfolios, watchlists, and payment info. The surface area is enormous. So I started breaking it down into implementation work.
Here’s my working checklist. Sharing it because I suspect most engineering teams haven’t started yet.
The Scope Is Wider Than You Think
GDPR applies if you process personal data of EU residents. Period. “Personal data” is deliberately broad. Names, emails, IP addresses, device IDs, cookies. At the fintech startup we also deal with financial preferences and reading behavior — all of it counts. If a piece of data can identify a person, even indirectly, it’s in scope.
The fines are absurd. 4% of global revenue or EUR 20 million, whichever is higher. For a startup that’s existential. For a fintech startup handling people’s financial data, there’s also the reputational angle. One breach notification and your users vanish.
Core Principles (Architecture Requirements, Not Legal Fluff)
You need a lawful basis to collect data. Collect only what you need. Keep it accurate. Delete it when you’re done. Secure it properly.
Read those again. Those aren’t legal phrases. Those are architecture constraints. Every one of them implies engineering work.
What Users Can Demand
Under GDPR, users get real power:
- Access: Give me everything you have on me.
- Rectification: Fix my data.
- Erasure: Delete everything. All of it.
- Portability: Export my data in a usable format.
- Objection: Stop processing my data for X purpose.
Each of those is a feature. An API endpoint. A workflow. A queue. A set of edge cases nobody has thought through yet.
The Actual Checklist
1. Data Inventory
This is step one and it’s miserable. You need a complete map of personal data across your entire stack. Every database, every log file, every analytics pipeline, every third-party SaaS tool.
At the fintech startup, I started with a spreadsheet. Columns: data type, storage location, purpose, retention period, access controls, third parties involved. It took two weeks just to get a rough picture. We found user emails in places nobody expected — cached in a search index, embedded in error logs, duplicated in an old analytics table we forgot to decommission.
You can’t delete what you can’t find.
2. Consent Management
If consent is your lawful basis (and for a lot of what we do in fintech, it is), the bar is high. Consent must be explicit, purpose-specific, and trivially easy to withdraw.
Store it as a first-class record. Purpose, policy version, timestamp, method of collection. Make withdrawal as easy as opt-in — ideally one click. You need a queryable consent history because someday a regulator will ask for proof.
3. Data Access Requests
Users get 30 days. That’s 30 days to pull everything you hold about them from every system, verify their identity, and hand it over in a readable format.
If your data lives in three databases, two SaaS tools, and a logging pipeline, good luck doing this manually at any scale. Build a self-service export feature. Treat it like a product feature, not an ops runbook.
4. Right to Erasure
Deletion is the hardest part. Full stop.
You need to remove data from primary stores, analytics, derived datasets, and logs. But you also have legal retention requirements — we’re in fintech, so certain transaction records must stay for regulatory reasons. Those exceptions need clear documentation.
Backups are the nightmare. Deleting a user from production doesn’t touch last week’s backup. You need either queued deletion (mark records, exclude on restore) or a backup retention window short enough that old copies age out naturally. Either way, track every deletion request with an audit trail.
5. Data Portability
If you already built the access request pipeline, portability is just a formatting layer. JSON or CSV. Machine-readable. Done. Don’t overthink this one.
6. Encryption and Pseudonymization
Encrypt at rest, in transit, in backups. We already did most of this at the fintech startup because financial data basically demands it. But GDPR goes further — it encourages pseudonymization. Use opaque IDs for analytics and testing. Keep the mapping to real identities locked down in a separate system with tight access controls.
This isn’t just compliance theater. It genuinely limits blast radius when something goes wrong.
7. Retention Policies
Define how long each data category lives. Then enforce it automatically. Cron jobs. Scheduled deletion. Not calendar reminders that someone ignores.
Shorter retention = smaller risk surface = easier erasure requests. We’re rethinking retention across the board. Some of our tables had no expiry at all. Data just accumulated forever because nobody asked why.
8. Breach Notification
72 hours. That’s how long you have to notify the authority after discovering a breach. Which means you need to actually detect breaches quickly. Logging, monitoring, alerting, clear incident ownership.
In fintech this is already table stakes. But GDPR formalizes it. If your incident response is “panic and check the logs manually,” you’re not ready.
9. Privacy by Design
New features should be built with data minimization from the start. Default to opt-in. Ask “do we actually need this data?” during design review, not after launch. Review data flows as part of architecture review.
I’ve started adding a “data impact” section to our design docs at the fintech startup. It forces the team to think about what personal data a feature touches before writing code.
10. Third-Party Processors
Your obligations extend to every vendor that touches user data. Payment processors, analytics tools, email providers, hosting. Get data processing agreements in place for all of them. Your deletion and access workflows need to reach into vendor systems too.
We had seven third-party processors. I didn’t know the exact number until I did the inventory. That’s the problem.
Where We Are
I’m working through this at the fintech startup right now. Data inventory is mostly done. Consent tracking is designed, not built. Deletion workflows are going to take months because of the backup situation.
My rough timeline:
- Now through Q2 2017: Complete inventory, map all vendor data flows
- Q3 2017: Build consent tracking, export pipeline, deletion workflows, retention enforcement
- Q4 2017: Train the team, rehearse request handling, update privacy notices to match reality
- Q1 2018: Full audit, incident response drill, verify third-party compliance
That’s tight. And we started relatively early. If you haven’t begun, you’re behind.
The Hard Parts
Data scatter is the root cause of most pain. Personal data ends up in places you forgot about — log files, search indexes, analytics warehouses, old database replicas. Discovery takes forever.
Backups are genuinely difficult. There’s no clean solution, just tradeoffs between restore capability and deletion compliance.
Legacy systems are a time bomb. If they can’t support granular deletion or export, you need remediation time. Budget for it.
Bottom Line
GDPR is an engineering program. Legal writes the words. Engineering builds the systems that make those words true. Start with the data inventory. Everything else depends on knowing where your data lives.
May 2018 is closer than it looks.