The Full Stack Developer's Guide to GDPR Compliance

Why This Matters for Developers

GDPR is not just a legal problem. It has direct implications for how you design databases, handle user data, implement logging, and build APIs. Fines can reach 4% of global annual revenue. More practically, EU and UK enterprise clients will not sign contracts with vendors who cannot demonstrate GDPR compliance. Getting it right from the start is much cheaper than retrofitting it later.

The Six Things GDPR Requires at the Code Level

1. Lawful Basis for Processing

You must have a documented reason for processing every category of personal data. For most web applications, this is consent (cookie banners, explicit opt-ins) or legitimate interest (fraud prevention, security). Store consent records in your database with timestamp and consent version.

2. Data Minimization

Only collect what you actually need. Audit every field in your user schema. Do you need date of birth or just age verification? Do you need full address or just country? Remove fields you do not actively use. This reduces your compliance surface area and your breach liability.

3. Right to Erasure

Users can request deletion of their data. Build a deleteUser(userId) function that cascades through all tables: anonymize or delete rows, purge from analytics systems, remove from email lists, and generate a deletion confirmation record (which you must keep for proof). Soft deletes are not erasure — you must actually remove the PII.

4. Data Portability

Users can request an export of their data in a machine-readable format. Build a exportUserData(userId) endpoint that collects all their data across tables and returns a structured JSON or CSV. This is also a great stress test of whether you actually know where all user data lives in your system.

5. Breach Notification

You have 72 hours to notify the relevant data protection authority of a breach. This means you need logging and alerting that can detect and quantify a breach quickly. Know exactly what data was exposed, how many users are affected, and when it happened.

6. Processor Agreements

Every third-party service that handles personal data (email providers, analytics, error tracking, payment processors) must have a Data Processing Agreement (DPA) in place. Stripe, Vercel, AWS, and most major providers offer these. Keep a register of all processors.

Practical Implementation

Encrypt PII fields at the application level using a library like @prisma/client-extension-encryption. Log all access to personal data. Use pseudonymization where possible — replace user IDs in analytics events with hashed values. Run a DPIA (Data Protection Impact Assessment) before launching any feature that processes sensitive data at scale.

I build GDPR-compliant systems for European clients as a default. See how this applies to fintech projects, or get in touch to discuss your compliance requirements.