DSGVO fur Softwareentwickler | Was Sie wirklich implementieren mussen

Die DSGVO gilt seit 2018, aber die meisten Entwickler-Guides konzentrieren sich immer noch auf die Rechtstheorie. Dieser Leitfaden ist anders. Er behandelt die technischen Anforderungen, den Code, den Sie schreiben mussen, und die Architekturentscheidungen, die Compliance praktisch statt schmerzhaft machen.

Wenn Ihre Software personenbezogene Daten von Personen in der EU speichert, verarbeitet oder beruhrt, betrifft Sie das. Es spielt keine Rolle, wo Ihr Unternehmen seinen Sitz hat.

DSGVO-Uberblick fur Entwickler

Uberspringen Sie die 99 Artikel. Hier ist, was die DSGVO fur Ihre Codebasis bedeutet:

1. Erheben Sie nur, was Sie brauchen. Speichern Sie keine Daten “fur alle Falle.”
2. Informieren Sie Nutzer, was Sie mit ihren Daten tun. Und holen Sie deren Erlaubnis ein, wenn erforderlich.
3. Lassen Sie Nutzer ihre Daten einsehen, exportieren und loschen. Sie brauchen API-Endpoints dafur.
4. Halten Sie Daten sicher. Verschlusselung, Zugriffskontrollen, Audit-Logs.
5. Melden Sie Verletzungen schnell. Sie haben 72 Stunden, um die Behorden nach Entdeckung einer Verletzung zu informieren.
6. Dokumentieren Sie alles. Ihre Verarbeitungstatigkeiten, Ihre Sicherheitsmassnahmen, Ihre Datenflusse.

Das ist die praktische Zusammenfassung. Der Rest dieses Leitfadens zeigt Ihnen, wie Sie jede Anforderung implementieren.

Die 7 wichtigsten technischen Anforderungen

1. Einwilligungsverwaltung

Die Einwilligung muss freiwillig, spezifisch, informiert und eindeutig sein. Vorangekreuzte Kastchen zahlen nicht. Gebundelte Einwilligung (“allem zustimmen”) zahlt nicht. Der Widerruf muss genauso einfach sein wie die Erteilung der Einwilligung.

Was Sie bauen mussen

Ein Einwilligungssystem braucht drei Komponenten:

• Einen Einwilligungsspeicher. Fur jeden Nutzer festhalten, wozu er eingewilligt hat, wann und wie.
• Einen Einwilligungsprufmechanismus. Vor der Verarbeitung von Daten fur einen bestimmten Zweck prufen, ob der Nutzer eine aktive Einwilligung hat.
• Einen Widerrufsmechanismus. Nutzern ermoglichen, die Einwilligung uber Ihre UI zu widerrufen, und die Verarbeitung sofort stoppen.

Datenbankschema

CREATE TABLE user_consents (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id),
  consent_type VARCHAR(100) NOT NULL,
  granted BOOLEAN NOT NULL,
  granted_at TIMESTAMPTZ,
  revoked_at TIMESTAMPTZ,
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_user_consents_lookup
  ON user_consents (user_id, consent_type, granted);

Speichern Sie die vollstandige Historie. Loschen oder uberschreiben Sie niemals Einwilligungsdatensatze. Wenn ein Nutzer die Einwilligung widerruft, fugen Sie eine neue Zeile mit granted = false ein und setzen revoked_at. Das gibt Ihnen einen Audit-Trail.

Einwilligungsprufungs-Middleware

Hier ist eine Express-Middleware, die die Einwilligung vor der Verarbeitung einer Anfrage pruft:

import { Request, Response, NextFunction } from "express";
import { db } from "./database";

interface ConsentRequirement {
  type: string;
  required: boolean;
}

function requireConsent(consentType: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const userId = req.user?.id;

    if (!userId) {
      return res.status(401).json({ error: "Authentication required" });
    }

    const consent = await db.query(
      `SELECT granted FROM user_consents
       WHERE user_id = $1 AND consent_type = $2
       ORDER BY created_at DESC
       LIMIT 1`,
      [userId, consentType]
    );

    if (!consent.rows[0]?.granted) {
      return res.status(403).json({
        error: "Consent required",
        consentType,
        message: `You must grant "${consentType}" consent to use this feature.`,
        consentUrl: `/settings/privacy`,
      });
    }

    next();
  };
}

// Usage
app.post(
  "/api/newsletter/subscribe",
  requireConsent("marketing_emails"),
  subscribeHandler
);

app.post(
  "/api/analytics/track",
  requireConsent("usage_analytics"),
  trackHandler
);

2. Datenzugang und -export (Auskunftsrecht)

Nutzer haben das Recht, eine Kopie aller personenbezogenen Daten anzufordern, die Sie uber sie gespeichert haben. Sie mussen diese in einem gangigen, maschinenlesbaren Format bereitstellen. JSON oder CSV funktioniert.

Was Sie bauen mussen

Einen Endpoint, der alle personenbezogenen Daten eines Nutzers aus jeder Tabelle und jedem Service sammelt und in eine herunterladbare Datei verpackt.

interface DataExport {
  exportedAt: string;
  user: {
    profile: Record<string, unknown>;
    activity: Record<string, unknown>[];
    consents: Record<string, unknown>[];
    communications: Record<string, unknown>[];
  };
}

app.get("/api/me/data-export", authenticate, async (req, res) => {
  const userId = req.user.id;

  const [profile, activity, consents, communications] = await Promise.all([
    db.query("SELECT id, email, name, created_at FROM users WHERE id = $1", [
      userId,
    ]),
    db.query(
      "SELECT action, metadata, created_at FROM user_activity WHERE user_id = $1 ORDER BY created_at DESC",
      [userId]
    ),
    db.query(
      "SELECT consent_type, granted, granted_at, revoked_at FROM user_consents WHERE user_id = $1 ORDER BY created_at DESC",
      [userId]
    ),
    db.query(
      "SELECT type, sent_at, subject FROM communications WHERE user_id = $1 ORDER BY sent_at DESC",
      [userId]
    ),
  ]);

  const exportData: DataExport = {
    exportedAt: new Date().toISOString(),
    user: {
      profile: profile.rows[0],
      activity: activity.rows,
      consents: consents.rows,
      communications: communications.rows,
    },
  };

  res.setHeader("Content-Type", "application/json");
  res.setHeader(
    "Content-Disposition",
    `attachment; filename="data-export-${userId}.json"`
  );
  res.json(exportData);
});

Dieser Endpoint muss jede Tabelle abdecken, die Nutzerdaten enthalt. Prufen Sie Ihr Schema grundlich. Eine fehlende Tabelle bedeutet einen unvollstandigen Export, was ein Compliance-Verstoss ist.

3. Recht auf Loschung (Recht auf Vergessenwerden)

Nutzer konnen verlangen, dass Sie alle ihre personenbezogenen Daten loschen. Sie mussen dem nachkommen, es sei denn, Sie haben eine gesetzliche Pflicht zur Aufbewahrung (wie Steuerunterlagen oder Betrugspravention).

Was Sie bauen mussen

Einen Losch-Endpoint, der Nutzerdaten uber alle Tabellen hinweg entfernt oder anonymisiert. Das ist schwieriger, als es klingt, wegen Foreign-Key-Constraints und Daten, von denen andere Systeme abhangen.

app.delete("/api/me/account", authenticate, async (req, res) => {
  const userId = req.user.id;
  const client = await db.getClient();

  try {
    await client.query("BEGIN");

    // Daten anonymisieren, die fur Geschaftsunterlagen aufbewahrt werden mussen
    await client.query(
      `UPDATE orders
       SET customer_name = 'deleted', customer_email = 'deleted'
       WHERE user_id = $1`,
      [userId]
    );

    // Daten loschen, die vollstandig entfernt werden konnen
    await client.query("DELETE FROM user_activity WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM user_consents WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM communications WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM sessions WHERE user_id = $1", [userId]);

    // Nutzerdatensatz anonymisieren statt loschen
    // Das bewahrt die referenzielle Integritat
    await client.query(
      `UPDATE users SET
        email = 'deleted-' || id || '@removed.invalid',
        name = 'Deleted User',
        phone = NULL,
        address = NULL,
        deleted_at = NOW()
       WHERE id = $1`,
      [userId]
    );

    await client.query("COMMIT");

    // Loschung in externen Systemen auslosen
    await Promise.allSettled([
      emailService.deleteSubscriber(userId),
      analyticsService.deleteUser(userId),
      searchIndex.removeUser(userId),
    ]);

    res.json({ message: "Account and personal data deleted" });
  } catch (error) {
    await client.query("ROLLBACK");
    throw error;
  } finally {
    client.release();
  }
});

Wichtige Entscheidungen:

• Loschen vs. anonymisieren. Datensatze, die fur die Buchhaltung benotigt werden (Bestellungen, Rechnungen), sollten anonymisiert werden. Alles andere loschen.
• Externe Systeme. An Drittanbieter-Services gesendete Daten mussen dort ebenfalls geloscht werden.
• Zeitrahmen. Die DSGVO sagt “ohne unangemessene Verzogerung.” Vollstandige Loschung innerhalb von 30 Tagen. Fur die meisten Systeme: sofort.

4. Datenminimierung

Erheben und speichern Sie nur die Daten, die Sie fur einen genannten Zweck tatsachlich brauchen. Wenn Sie nach einer Telefonnummer fragen, aber Nutzer nie anrufen, sollten Sie sie nicht erheben.

Praktische Regeln

• Prufen Sie jedes Formularfeld. Fur jedes Feld fragen: “Welches spezifische Feature funktioniert nicht mehr, wenn wir das entfernen?” Wenn die Antwort keines ist, entfernen Sie es.
• Legen Sie Aufbewahrungsfristen fest. Bewahren Sie Daten nicht ewig auf. Definieren Sie, wie lange jeder Datentyp benotigt wird, dann loschen Sie automatisch.
• Minimieren Sie Logging. Entfernen Sie personenbezogene Daten aus Log-Eintragen. Loggen Sie Nutzer-IDs, nicht Namen oder E-Mails.

-- Automatische Datenaufbewahrung mit PostgreSQL
-- Als geplanten Job ausfuhren (z.B. pg_cron)
DELETE FROM user_activity
WHERE created_at < NOW() - INTERVAL '2 years';

DELETE FROM session_logs
WHERE created_at < NOW() - INTERVAL '90 days';

DELETE FROM password_reset_tokens
WHERE created_at < NOW() - INTERVAL '24 hours';

5. Verschlusselung

Die DSGVO verlangt “geeignete technische Massnahmen” zum Schutz personenbezogener Daten. Verschlusselung ist die wichtigste.

At Rest

• Verschlusseln Sie Ihre Datenbank-Festplatte. Alle grossen Cloud-Anbieter unterstutzen das. Aktivieren und uberprufen Sie es.
• Fur hochsensible Felder (Sozialversicherungsnummern, Gesundheitsdaten) fugen Sie Verschlusselung auf Anwendungsebene hinzu.
• Verschlusseln Sie Backups. Ein unverschlusseltes Backup ist eine Verletzung, die darauf wartet, zu passieren.

In Transit

• TLS uberall. Jede Verbindung zwischen Services, Datenbanken und Nutzern. Keine Ausnahmen.
• Erzwingen Sie HTTPS. Leiten Sie HTTP um. Setzen Sie HSTS-Header.
• Nutzen Sie TLS fur Datenbankverbindungen. PostgreSQL unterstutzt das nativ.

// PostgreSQL-Verbindung mit TLS
import { Pool } from "pg";

const pool = new Pool({
  host: process.env.DB_HOST,
  port: 5432,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  ssl: {
    rejectUnauthorized: true,
    ca: fs.readFileSync("/path/to/server-ca.pem").toString(),
  },
});

6. Meldung von Verletzungen

Wenn personenbezogene Daten kompromittiert werden, mussen Sie die zustandige Datenschutzbehorde innerhalb von 72 Stunden benachrichtigen. Wenn die Verletzung ein hohes Risiko fur Einzelpersonen darstellt, mussen Sie auch die betroffenen Nutzer informieren.

Was Sie bauen mussen

• Audit-Logging. Jeden Zugriff auf personenbezogene Daten verfolgen. Wer hat zugegriffen, wann und von wo.
• Anomalieerkennung. Alarm bei ungewohnlichen Zugriffsmustern (Massendatenexporte, Zugriff von neuen IPs, Zugriff ausserhalb der Geschaftszeiten).
• Einen Incident-Response-Plan. Dokumentieren, wer was tut, wenn eine Verletzung erkannt wird. Das ist kein Code. Es ist eine Checkliste, die Ihr Team ubt.

CREATE TABLE data_access_log (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL,
  accessed_by UUID NOT NULL,
  access_type VARCHAR(50) NOT NULL,
  resource_type VARCHAR(100) NOT NULL,
  resource_id UUID,
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_data_access_log_user
  ON data_access_log (user_id, created_at);

CREATE INDEX idx_data_access_log_accessor
  ON data_access_log (accessed_by, created_at);

7. Privacy by Design

Die DSGVO sagt, dass Datenschutz von Anfang an in Systeme eingebaut werden soll, nicht nachtraglich hinzugefugt. In der Praxis bedeutet das, Datenschutz zum Standard zu machen.

• Standardmassig privat. Neue Features sollten minimale Daten erheben und Opt-in fur alles uber die Kernfunktion hinaus erfordern.
• Einstellungen standardmassig auf die privateste Option. Nutzer, die ihre Einstellungen nie anruhren, sollten den hochsten Datenschutz haben.
• Trennung der Belange. Mischen Sie keine Analysedaten mit Funktionsdaten. Verwenden Sie Auth-Tokens nicht fur Tracking.

Anonymisierung vs. Pseudonymisierung

Das ist nicht dasselbe, und der Unterschied ist wichtig.

• Pseudonymisierung ersetzt identifizierende Informationen durch ein umkehrbares Token. Beispiel: E-Mail-Adressen hashen. Wenn Sie die Hash-Funktion und die ursprungliche E-Mail haben, konnen Sie die Person re-identifizieren. Die DSGVO gilt weiterhin, weil Re-Identifizierung moglich ist.
• Anonymisierung entfernt identifizierende Informationen dauerhaft. Beispiel: aggregierte Analysen (“1.247 Nutzer besuchten die Preisseite”) ohne Moglichkeit, einzelne Nutzer zu identifizieren. Die DSGVO gilt nicht fur wirklich anonymisierte Daten.

Echte Anonymisierung ist schwierig. Wenn Ihr “anonymer” Datensatz einen Zeitstempel, eine Stadt und einen Geratetyp enthalt, konnte diese Kombination jemanden eindeutig identifizieren. Seien Sie konservativ.

Cookie-Einwilligung

Wenn Ihre Website Cookies uber das strikt Notwendige hinaus verwendet, brauchen Sie eine Einwilligung, bevor Sie sie setzen.

Erfordert Einwilligung: Analyse-Cookies, Werbepixel, Social-Media-Widgets, jedes Drittanbieter-Tracking-Script.

Erfordert keine Einwilligung: Session-Cookies, Warenkorb-Cookies, CSRF-Tokens, das Cookie-Einwilligungspraferenz-Cookie selbst.

Ihr Einwilligungsbanner sollte nicht-essenzielle Cookies blockieren, bis die Einwilligung erteilt ist, granulare Auswahlmoglichkeiten bieten und “Alle ablehnen” genauso einfach machen wie “Alle akzeptieren.” Bauen Sie das nicht von Grund auf. Tools wie Cookiebot handhabben die Komplexitat. Die Grundregel: Kein Tracking-Script feuert, bevor die Einwilligung erteilt ist.

Drittanbieter-Datenverarbeiter

Jeder Drittanbieter-Service, der die Daten Ihrer Nutzer verarbeitet, ist ein “Auftragsverarbeiter” nach DSGVO. Sie sind fur deren Compliance verantwortlich.

Was Sie prufen sollten

Vor der Integration eines Drittanbieter-Services, der personenbezogene Daten beruhrt:

1. Haben sie einen AVV? Ein Auftragsverarbeitungsvertrag ist verpflichtend. Die meisten SaaS-Anbieter veroffentlichen ihren offentlich.
2. Wo speichern sie Daten? Wenn ausserhalb der EU, prufen Sie die Rechtsgrundlage fur den Transfer.
3. Auf welche Daten greifen sie zu? Minimieren Sie, was Sie senden. Wenn der Service nur eine E-Mail braucht, senden Sie nicht das volle Profil.
4. Konnen Sie Daten aus deren Systemen loschen? Nutzerloschungsanfragen mussen uberall ankommen.
5. Wie gehen sie mit Verletzungen um? Ihr AVV sollte Benachrichtigungsfristen festlegen.

Haufige Drittanbieter-Auftragsverarbeiter zum Prufen

• E-Mail-Dienste (Resend, SendGrid, Mailchimp)
• Analytics (Google Analytics, Mixpanel, Amplitude)
• Fehlertracking (Sentry, Bugsnag)
• Zahlungsverarbeitung (Stripe, Adyen)
• Cloud-Hosting (AWS, Google Cloud, Vercel)
• Kundensupport-Tools (Intercom, Zendesk)
• AI APIs (OpenAI, Anthropic, Google AI)

Fuhren Sie eine Liste aller Auftragsverarbeiter. Prufen Sie sie vierteljahrlich.

Datenaufbewahrungsrichtlinien

Bewahren Sie personenbezogene Daten nicht langer als notig auf. Definieren Sie Aufbewahrungsfristen fur jeden Datentyp.

Datentyp	Empfohlene Aufbewahrung	Grund
Nutzerkontodaten	Bis Loschung angefordert	Fur den Service benotigt
Session-Logs	90 Tage	Sicherheit und Debugging
Nutzeraktivitats-Logs	1-2 Jahre	Produktanalytik
Support-Tickets	3 Jahre	Servicequalitat
Finanzunterlagen	7 Jahre	Steuer-/rechtliche Pflichten
Passwort-Reset-Tokens	24 Stunden	Sicherheit
Fehlgeschlagene Login-Versuche	90 Tage	Sicherheitsuberwachung

Implementieren Sie automatisierte Bereinigungsjobs. Verlassen Sie sich nicht darauf, dass jemand daran denkt, ein Script auszufuhren.

DSGVO-Checkliste fur Entwickler

Nutzen Sie diese als Ausgangspunkt beim Bauen oder Prufen eines Systems.

Datenerhebung

• Jedes Formularfeld hat einen genannten Zweck
• Es werden keine unnotigen Daten erhoben
• Die Datenschutzrichtlinie ist von jedem Datenerhebungspunkt verlinkt
• Einwilligung wird vor der Verarbeitung eingeholt (wo erforderlich)
• Einwilligungsdatensatze werden mit Zeitstempeln gespeichert

Datenspeicherung

• Datenbank-Verschlusselung at rest ist aktiviert
• TLS wird fur alle Verbindungen erzwungen
• Sensible Felder haben Verschlusselung auf Anwendungsebene
• Backups sind verschlusselt
• Zugriff auf Produktionsdaten ist eingeschrankt und protokolliert

Nutzerrechte

• Datenexport-Endpoint existiert und deckt alle Tabellen ab
• Kontoloschungs-Endpoint existiert und behandelt alle Daten
• Nutzer konnen Einwilligung in ihren Einstellungen einsehen und widerrufen
• Loschung wird an Drittanbieter-Services weitergegeben
• Alle Nutzerrechtsanfragen werden innerhalb von 30 Tagen beantwortet

Cookies und Tracking

• Cookie-Einwilligungsbanner ist implementiert
• Nicht-essenzielle Cookies werden vor Einwilligung blockiert
• Einwilligungsoptionen sind granular (nicht alles-oder-nichts)
• “Alle ablehnen” ist genauso prominent wie “Alle akzeptieren”

Drittanbieter

• Alle Auftragsverarbeiter sind dokumentiert
• AVVs sind mit jedem Verarbeiter unterzeichnet
• An Drittanbieter gesendete Daten sind minimiert
• Datenloschung bei Drittanbietern ist moglich

Sicherheit

• Audit-Logs verfolgen Zugriff auf personenbezogene Daten
• Anomalie-Alarmierung ist konfiguriert
• Incident-Response-Plan ist dokumentiert
• Verletzungsmeldeprozess ist definiert (72-Stunden-Frist)

Aufbewahrung

• Aufbewahrungsfristen sind fur alle Datentypen definiert
• Automatisierte Bereinigungsjobs sind geplant
• Abgelaufene Daten werden tatsachlich geloscht (verifizieren Sie das)

Abschliessende Gedanken

DSGVO-Compliance ist kein einmaliges Projekt. Es ist eine Reihe von Praktiken, die in Ihre Art, Software zu bauen, eingewebt sind. Die technische Arbeit ist uberschaubar: Einwilligungsspeicher, Datenexport, Losch-Endpoints, Verschlusselung, Audit-Logging. Standard-Engineering.

Der schwierige Teil ist die Grundlichkeit. Es ist leicht, die Log-Datei, das Analytics-Event oder die Drittanbieter-Integration zu vergessen, die Nutzer-E-Mails speichert. Prufen Sie regelmaessig. Testen Sie Ihren Losch-Endpoint. Verifizieren Sie, dass Ihre Exporte vollstandig sind. Bauen Sie Datenschutz von Anfang an in Ihren Prozess ein.

---

Brauchen Sie Hilfe beim Bau DSGVO-konformer Software oder bei der Prufung Ihrer bestehenden Systeme? Kontaktieren Sie uns. Wir bauen datenschutzorientierte Anwendungen fur europaische Unternehmen und Unternehmen, die EU-Nutzer bedienen.