GDPR Compliance for Developers: A Practical Guide

GDPR has been in effect since May 2018, yet most developers still treat it as a legal problem rather than an engineering one. That is a mistake. The majority of GDPR obligations — consent management, data minimization, right to erasure, breach notification — are implemented in code. Your legal team writes the policies. Your engineering team makes them real.

This guide is written for developers who build SaaS applications. It skips the legal theory and focuses on what you need to understand, what you need to build, and what you can automate. Whether you are retrofitting GDPR compliance into an existing product or building a new application from scratch, this article covers the practical engineering decisions you will face. If your application also uses AI, see our EU AI Act developer guide for the additional obligations that apply.

GDPR core concepts developers need to understand

Controller vs. processor

This distinction determines your obligations. A data controller decides why and how personal data is processed. A data processor processes data on behalf of a controller. As a SaaS provider, you are typically both: a controller for data you collect about your users (analytics, billing), and a processor for data your customers store in your application (customer content).

This dual role has practical implications. For data you control, you must determine legal bases, set retention periods, and respond to user rights requests directly. For data you process on behalf of customers, your customers (the controllers) handle user rights, and you provide the technical mechanisms for them to do so — data export APIs, deletion endpoints, and access controls.

Personal data is broader than you think

Under GDPR, personal data means any information relating to an identifiable person. This includes obvious identifiers like names and email addresses, but also IP addresses, cookie identifiers, device fingerprints, location data, and even pseudonymous data if it can be re-identified. In practice, almost all data your application collects about users qualifies as personal data.

Developers often underestimate this scope. Server logs containing IP addresses are personal data. Error tracking payloads that include user IDs are personal data. Analytics events tied to session identifiers are personal data. When in doubt, treat it as personal data.

Legal bases for processing

GDPR requires a legal basis for every data processing activity. The six legal bases are: consent, contractual necessity, legal obligation, vital interests, public task, and legitimate interest. For SaaS applications, you will primarily use three:

• Contractual necessity: Processing needed to fulfill your service agreement. Storing user content, processing payments, sending transactional emails — all contractual necessity.
• Legitimate interest: Processing that serves a legitimate business purpose where the impact on the individual is minimal. Product analytics, security monitoring, fraud prevention — typically legitimate interest, but you must document a Legitimate Interest Assessment (LIA).
• Consent: The individual explicitly agrees to processing. Marketing emails, non-essential cookies, and optional data sharing require consent. Consent must be freely given, specific, informed, and unambiguous.

What you need to build: the GDPR engineering checklist

1. Consent management

If you rely on consent for any processing activity, you need a system that records when consent was given, what the user consented to, how consent was obtained, and allows withdrawal at any time. For cookies, this means a cookie consent banner that blocks non-essential cookies until the user opts in. Do not use pre-checked boxes. Do not use "by continuing to use this site you consent" banners — these are not valid GDPR consent.

Technically, implement consent as a database record linked to the user: timestamp, consent scope, version of the privacy policy shown, and the user's choice. When consent is withdrawn, stop the associated processing immediately and record the withdrawal.

2. Data subject rights endpoints

GDPR grants individuals several rights that your application must support. From an engineering perspective, these translate to API endpoints or admin tools:

3. Data minimization

GDPR requires you to collect only the data you actually need. This is an engineering principle as much as a legal one. Audit every form field, every analytics event, and every API payload. Ask: do we need this data to provide the service? If not, do not collect it.

Common violations include collecting full names when only an email is needed for login, tracking granular user behavior when aggregate metrics would suffice, storing IP addresses indefinitely in server logs, and requesting broad OAuth scopes when narrow ones would work. Each unnecessary data point increases your compliance burden and your attack surface.

4. Breach notification system

GDPR requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach. If the breach poses a high risk to individuals, you must also notify affected users without undue delay. This means you need:

• Monitoring and alerting for unauthorized data access
• An incident response plan with clear ownership and procedures
• Templates for authority and user notifications
• Logging sufficient to determine the scope of a breach

The 72-hour clock starts when you become "aware" of the breach, not when you discover the root cause. Having a documented incident response process is essential to meeting this deadline.

5. Data Processing Agreements (DPAs)

Every sub-processor that handles personal data on your behalf needs a Data Processing Agreement. This is a legal contract, but developers need to be aware of it because adding a new third-party service means a new DPA is needed. Major services like AWS, Stripe, Vercel, and Sentry have standardized DPAs you can sign online. Smaller services may require negotiation.

Maintain a sub-processor register that lists every third-party service, what data it processes, where it is hosted, and the DPA status. Codepliant automatically detects your third-party services by scanning your codebase, giving you a starting point for this register. Learn more about generating this documentation on our Privacy Policy Generator page.

Detecting GDPR-relevant services with Codepliant

Before you can comply with GDPR, you need to know what data your application actually collects and which third-party services it sends data to. Codepliant automates this discovery by scanning your package.json, source imports, and .env files.

Run a single command to scan your project and see which GDPR-relevant services are detected:

$ npx codepliant go

Scanning project...

Detected services:
  Analytics:     Google Analytics, Mixpanel, Segment
  Payments:      Stripe
  Auth:          Auth0
  Error tracking: Sentry
  Email:         SendGrid
  Database:      PostgreSQL (Prisma)
  AI:            OpenAI

Generated documents:
  ./compliance/privacy-policy.md
  ./compliance/cookie-policy.md
  ./compliance/terms-of-service.md
  ./compliance/ai-disclosure.md

Done. 4 documents generated.

Codepliant detects services across three layers: dependency names in your package manifest, import statements in your source code, and environment variable patterns in .env files. Here is what it looks for in each category relevant to GDPR:

# Analytics (collect user behavior data)
Dependencies: @google-analytics/data, mixpanel, @segment/analytics-next
Imports:      gtag(), mixpanel.track(), analytics.track()
Env vars:     GA_TRACKING_ID, MIXPANEL_TOKEN, SEGMENT_WRITE_KEY

# Payment processors (handle financial PII)
Dependencies: stripe, @paypal/checkout-server-sdk
Imports:      new Stripe(), paypal.orders.create()
Env vars:     STRIPE_SECRET_KEY, PAYPAL_CLIENT_ID

# Error tracking (may capture user context)
Dependencies: @sentry/node, @sentry/nextjs, bugsnag
Imports:      Sentry.init(), Bugsnag.start()
Env vars:     SENTRY_DSN, BUGSNAG_API_KEY

# Email services (process email addresses)
Dependencies: @sendgrid/mail, nodemailer, postmark
Imports:      sgMail.send(), transporter.sendMail()
Env vars:     SENDGRID_API_KEY, SMTP_HOST, POSTMARK_API_TOKEN

# Auth providers (store identity data)
Dependencies: auth0, next-auth, @clerk/nextjs, firebase-admin
Imports:      auth0.getSession(), getServerSession()
Env vars:     AUTH0_SECRET, NEXTAUTH_SECRET, CLERK_SECRET_KEY

For a JSON-formatted scan result you can pipe into your own tooling, use the scan subcommand:

$ npx codepliant scan --json

{
  "services": {
    "stripe": {
      "category": "payments",
      "dataCollected": [
        "payment card numbers",
        "billing addresses",
        "email addresses",
        "transaction history"
      ],
      "detectedVia": ["dependency", "import", "env"]
    },
    "google-analytics": {
      "category": "analytics",
      "dataCollected": [
        "IP addresses",
        "page views",
        "device information",
        "user behavior"
      ],
      "detectedVia": ["dependency", "env"]
    },
    "sentry": {
      "category": "error-tracking",
      "dataCollected": [
        "error stack traces",
        "user context",
        "device information",
        "IP addresses"
      ],
      "detectedVia": ["dependency", "import"]
    }
  }
}

This output tells you exactly which services require DPAs, what data categories to disclose in your privacy policy, and which services need entries in your cookie policy. Instead of manually auditing your codebase every quarter, run Codepliant in CI to catch new sub-processors the moment a developer adds an npm install.

Common GDPR mistakes developers make

After scanning hundreds of codebases, we see the same patterns repeatedly. Here are the GDPR mistakes that catch engineering teams off guard:

Common GDPR implementation patterns for SaaS

Soft delete with scheduled purge

When a user requests deletion, soft-delete their account immediately (marking it as deleted and removing it from the application) but schedule the hard delete for 30 days later. This gives you a recovery window for accidental deletions while still honoring the erasure request promptly. After 30 days, a background job permanently removes all personal data and propagates deletion to sub-processors.

Anonymization for analytics

If you need historical analytics but not individual-level data, anonymize records after a defined retention period. Replace user identifiers with random tokens, aggregate event data, and remove any fields that could enable re-identification. Truly anonymous data is outside GDPR scope entirely.

Encryption at rest and in transit

While GDPR does not mandate specific security measures, it requires "appropriate technical and organizational measures." Encryption at rest (AES-256 for databases and file storage) and in transit (TLS 1.2+ for all connections) are considered baseline. Most cloud providers handle this by default, but verify your configuration. Also consider field-level encryption for sensitive data like government IDs or health information.

Audit logging

Maintain immutable audit logs for all access to personal data, data modifications, consent changes, and deletion operations. These logs serve as evidence of compliance during regulatory inquiries. Log the actor, action, timestamp, and affected data categories — but do not log the personal data itself.

International data transfers

If you transfer personal data outside the EU/EEA (which most SaaS applications do if they use US-based cloud services), you need a legal mechanism for the transfer:

• EU-US Data Privacy Framework: If your sub-processor is certified under the DPF, transfers to that processor are covered. Major providers like AWS, Google Cloud, and Microsoft are certified.
• Standard Contractual Clauses (SCCs): The fallback mechanism for transfers to countries without adequacy decisions. Most DPAs from major providers include SCCs.
• Adequacy decisions: Transfers to countries the European Commission deems adequate (UK, Canada, Japan, South Korea, and others) require no additional safeguards.

For each sub-processor, verify which transfer mechanism applies and document it. Your privacy policy must disclose international transfers and the safeguards in place. Codepliant detects your sub-processors automatically, so you always have an up-to-date list to audit against. For a broader view of data privacy requirements, visit our Data Privacy Compliance Hub.

GDPR and AI: additional obligations for AI-powered SaaS

If your SaaS uses AI, GDPR adds specific obligations on top of the standard requirements. For a detailed breakdown of AI-specific regulation, see our EU AI Act developer guide and the AI Governance Hub:

• Article 22 — Automated decision-making: Users have the right not to be subject to decisions based solely on automated processing that significantly affect them. If your AI makes decisions about access, pricing, content moderation, or eligibility, you must offer human review.
• Transparency about AI processing: Your privacy policy must disclose the existence of automated decision-making, provide meaningful information about the logic involved, and explain the significance and consequences for the user. Codepliant can generate an AI Disclosure document for you automatically.
• Data sent to AI providers: If you send user data to OpenAI, Anthropic, or other AI APIs, this is a data transfer to a sub-processor. You need a DPA with the AI provider, and the transfer must be disclosed in your privacy policy.
• Training data: If user data could be used to train AI models (either by you or your AI provider), this requires a separate legal basis — typically consent. Most major AI providers now offer options to opt out of training data usage.

GDPR enforcement: the numbers developers should know

GDPR enforcement is real and increasing. As of 2026, regulators have issued over 2,000 fines totaling more than 4.5 billion EUR. While headline fines target large companies (Meta: 2.5 billion EUR, Amazon: 746 million EUR, TikTok: 345 million EUR), small and mid-size companies are fined regularly too. The median fine is around 50,000 EUR — significant for a startup.

Common violations that result in fines include:

Action plan: GDPR compliance for your engineering team

1. Scan your codebase. Run Codepliant to generate an inventory of all data collection, third-party integrations, and AI usage in your application. This gives you the factual foundation for compliance.
2. Document your data processing. For each data category, record the legal basis, retention period, and sub-processors involved. This is your Record of Processing Activities (ROPA), required by Article 30.
3. Implement user rights. Build or verify data export, deletion, and consent management flows. Test them end-to-end, including propagation to sub-processors.
4. Review your privacy policy. Ensure it accurately reflects your data practices, names your sub-processors, specifies retention periods, and covers AI processing if applicable. Use the Privacy Policy Generator to create one from your codebase.
5. Set up consent management. Implement a GDPR- compliant cookie consent banner. Ensure non-essential cookies are blocked until opt-in. See our Cookie Policy Generator for help documenting your cookie usage.
6. Prepare for breaches. Document an incident response plan. Test it with a tabletop exercise. Ensure you can identify, assess, and report a breach within 72 hours.
7. Integrate into CI/CD. Add Codepliant to your deployment pipeline to regenerate compliance documentation on every deploy. This keeps your privacy policy synchronized with your code.