GDPR Developer Guide: Technical Requirements & Implementation Checklist

GDPR compliance is not just a legal checkbox — it requires specific technical implementations in your API design, database schema, and data pipeline. This guide focuses on what developers actually need to build: erasure endpoints, consent tracking, breach notification procedures, and privacy-by-design patterns.

GDPR Key Principles for Developers

GDPR is built on six processing principles that should shape your technical design decisions:

• Lawfulness, fairness, transparency — Have a documented lawful basis; tell users what you collect
• Purpose limitation — Collect data for a specific purpose; don't repurpose it
• Data minimization — Only collect what you need; avoid "just in case" fields
• Accuracy — Keep data up to date; provide user correction mechanisms
• Storage limitation — Delete data when no longer needed; implement retention policies
• Integrity and confidentiality — Encrypt in transit and at rest; access controls

Lawful Basis for Processing

Right to Erasure: Soft Delete Pattern

-- Database schema for privacy-safe soft deletion
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP;
ALTER TABLE users ADD COLUMN erasure_requested_at TIMESTAMP;

-- Erasure procedure: anonymize PII fields
UPDATE users SET
  email = CONCAT('deleted-', id, '@erased.invalid'),
  name = '[Deleted User]',
  phone = NULL,
  address = NULL,
  date_of_birth = NULL,
  ip_address = NULL,
  deleted_at = NOW(),
  erasure_requested_at = NOW()
WHERE id = $1;

// Express route: DELETE /api/users/me (authenticated)
app.delete('/api/users/me', authenticate, async (req, res) => {
  const userId = req.user.id;

  // 1. Queue erasure job (async — respects 30-day backup rotation)
  await db.erasureQueue.create({
    userId,
    requestedAt: new Date(),
    status: 'pending',
  });

  // 2. Immediately anonymize active record
  await db.users.anonymize(userId);

  // 3. Revoke active sessions
  await db.sessions.deleteByUserId(userId);

  // 4. Notify downstream services (analytics, CRM)
  await erasureEvent.emit('user.erased', { userId });

  res.json({ message: 'Your data has been scheduled for deletion.' });
});

Data Minimization in API Design

// Bad: returning all user fields including PII not needed by client
app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user); // Leaks DOB, phone, full address
});

// Good: return only fields the client actually needs
app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id, {
    select: ['id', 'displayName', 'avatarUrl', 'createdAt'],
  });
  res.json(user);
});

// Good: use GraphQL field selection to prevent over-fetching
// clients can only request explicitly allowed fields

Consent Management (CMP Integration)

// Store consent with audit trail
const consentRecord = {
  userId: user.id,
  consentVersion: '2024-01-15',  // tie to your privacy policy version
  purposes: {
    analytics: true,
    marketing: false,
    functional: true,
  },
  collectedAt: new Date(),
  ipAddress: req.ip,  // evidence of consent timing
  userAgent: req.headers['user-agent'],
};

// Never rely on a boolean — store the full consent record
await db.consentLog.create(consentRecord);

// Check consent before sending marketing
async function canSendMarketing(userId) {
  const latest = await db.consentLog.findLatest(userId);
  return latest?.purposes?.marketing === true;
}

Data Breach Notification: 72-Hour Rule

When a breach is discovered, the clock starts immediately. Build a runbook with these steps:

• 0-4 hours: Contain breach (revoke compromised tokens, block attacker IP, isolate affected systems)
• 4-24 hours: Assess scope (what data, how many users, what type of data)
• 24-48 hours: Draft supervisory authority notification with known facts; engage DPO
• 48-72 hours: File notification with your lead supervisory authority (even if incomplete — update later)
• If high-risk: Also notify affected users directly within same window

DPIA Checklist

A DPIA is required when your processing is "high risk." Check if your feature requires one:

• Systematic profiling or automated decision-making with legal/significant effects
• Large-scale processing of special category data (health, biometric, financial)
• Systematic monitoring of publicly accessible areas
• Combining datasets from different sources to identify individuals
• Processing data of vulnerable subjects (children, patients)
• Using new technologies (AI models, biometric matching)

GDPR vs CCPA vs LGPD