Audit & lifecycle: audit logs, data retention, Löschung auf Anfrage, Continuity/Backups

1. Warum brauchen Sie überhaupt Audit & Lifecycle in der ChatGPT‑App

Solange Sie einen Prototyp schreiben, sind Sie selbst der Nutzer, die DB ist ein lokales SQLite, und „Incidents“ heilen Sie mit git reset --hard – alles wirkt gemütlich und heimelig.

Aber sobald Ihr GiftGenius (oder eine andere ChatGPT‑App) echte Nutzer bekommt, besonders mit Zahlungen und PII, tauchen plötzlich auf:

• Sicherheitsbeauftragte des Kunden mit der Frage „Wer kann unsere Bestellungen sehen und wer hat sie geändert?“;
• Juristen mit der Frage „Wie lange bewahren Sie Daten auf und wie erfüllen Sie die Anfrage ‚Löscht mich‘?“;
• Produktionsrealität mit der Frage „Was passiert, wenn ein Entwickler im Prod eine Tabelle droppt?“.

In dieser Vorlesung behandeln wir vier tragende Blöcke:

1. Audit‑Logs – eine separate Logging‑Schicht für Sicherheit und Audit.
2. Data Retention – Lebensdauern verschiedener Datentypen und deren Umsetzung.
3. Löschung auf Anfrage des Nutzers – „Recht auf Vergessenwerden“ in der Technik.
4. Business Continuity & Backups – wie Sie Ausfälle überstehen, ohne Gesicht und Daten zu verlieren.

Alle Beispiele beziehen wir, wo möglich, auf unsere Lern‑App (den hypothetischen GiftGenius auf Next.js + Apps SDK + MCP).

2. Audit‑Logs: Wer, was, wann und mit welchem Ergebnis

Wodurch unterscheiden sich Audit‑Logs von normalen Logs

Normale Application‑Logs sind freundliche Nachrichten für Entwickler. Darin leben Stack Traces, Debug‑Informationen, seltsame Variablenwerte, Debug‑ console.log("hier darf es auf keinen Fall null sein"). Sie leben nicht lange und werden von Engineers gelesen.

Audit‑Logs sind ein anderes Universum. Ihre Hauptadressaten sind Security‑Teams, Auditoren, manchmal Juristen. Die brauchen keine Zeile „NullPointer in Zeile 55“, sondern einen Eintrag wie „Nutzer X hat um Zeitpunkt Y die Zahlungseinstellungen von Organisation Z geändert, Ergebnis: erfolgreich“. Audit‑Einträge leben üblicherweise deutlich länger (Jahre) und gelten im Falle von Ermittlungen als Beleg.

Wesentliche Unterschiede:

OWASP und ähnliche Guidelines betonen: Audit‑Logs sollten in einem separaten Speicher oder einer separaten Tabelle liegen, nicht vermischt mit normalen App‑Logs.

Was im Kontext einer ChatGPT‑App zu loggen ist

Für eine ChatGPT‑App, insbesondere mit Commerce, ist ein vernünftiges Audit‑Minimum:

• Authentifizierungsereignisse: Login, Logout, Login‑Versuche;
• Operationen an kritischen Daten: Erstellen/Aktualisieren/Löschen von Profilen, Bestellungen, Zahlungseinstellungen;
• Administrative Aktionen: Rollenwechsel, Änderung von Mandanten‑Einstellungen;
• Aufrufe sensibler MCP/Agents‑Tools: create_order, charge_customer, cancel_subscription etc.

Gute Faustregel: Alles, was Sie im Incident im Stil „Wer hat das getan und wodurch?“ fragen würden, gehört ins Audit.

Struktur eines Audit‑Ereignisses

Praktisches mentales Modell: Jeder Eintrag ist „wer / welche Aktion / an was / in welchem Kontext / mit welchem Ergebnis“. Oft formuliert als Struktur who, action, resource, context, outcome.

Für unseren GiftGenius beschreiben wir ein Interface in TypeScript:

// lib/audit.ts
export type AuditAction =
  | "auth.login"
  | "auth.logout"
  | "order.create"
  | "order.cancel"
  | "account.delete"
  | "giftidea.generate";

export interface AuditEvent {
  eventId: string;          // uuid
  timestamp: string;        // ISO
  actor: {
    userId: string | null;  // kann bis zum Login null sein
    tenantId?: string | null;
    ip?: string | null;
    client: "chatgpt-app" | "admin-panel" | string;
  };
  action: AuditAction;
  resource?: {
    type: string;           // "order", "user", ...
    id?: string;
  };
  context?: {
    mcpTool?: string;
    requestId?: string;
  };
  outcome: {
    status: "success" | "failure";
    reason?: string | null;
  };
}

Beachten Sie, dass im Ereignis keine vollständigen E‑Mail‑Adressen, Kartennummern und andere PII landen, die wir gemäß früheren Vorlesungen maskieren und ohne Not nicht loggen.

Wo und wie Audit‑Logs speichern

Mindestanforderungen an den Speicher:

• eigene Tabelle oder sogar separate DB von den normalen Logs, damit man nicht versehentlich etwas überschreibt;
• nach Möglichkeit append‑only: technisch kann das eine Policy „Wir machen niemals UPDATE/DELETE auf dieser Tabelle“ sein, plus eine DB‑Rolle, die nur INSERT und SELECT darf;
• eingeschränkter Zugriff: nicht das ganze Engineering‑Team sollte vollen Audit‑Zugriff haben.

Wenn Sie PostgreSQL über Prisma/Drizzle verwenden, kann das Modell so aussehen (vereinfachtes Beispiel):

CREATE TABLE audit_events (
  event_id   uuid PRIMARY KEY,
  created_at timestamptz NOT NULL DEFAULT now(),
  actor_user_id text,
  actor_tenant_id text,
  actor_ip      inet,
  action        text NOT NULL,
  resource_type text,
  resource_id   text,
  context_mcp_tool text,
  context_request_id text,
  outcome_status text NOT NULL,
  outcome_reason text
);

Das Schema passen Sie an Ihre Bedürfnisse an, aber Hauptsache strukturiert. Einzeilige JSON‑Müllhalden werden Sie später verfluchen.

Audit in unserer App implementieren

Wir bauen einen kleinen Helper in der Next.js‑App (Node‑Umgebung, z. B. im MCP‑Server oder API‑Route):

// lib/audit.ts
import { randomUUID } from "crypto";
import { db } from "./db"; // Ihr DB‑Client

export async function logAudit(event: Omit<AuditEvent, "eventId" | "timestamp">) {
  const full: AuditEvent = {
    ...event,
    eventId: randomUUID(),
    timestamp: new Date().toISOString(),
  };

  // In der Praxis: über Queue/Background; hier nur ein Insert
  await db.insertInto("audit_events").values({
    event_id: full.eventId,
    created_at: full.timestamp,
    actor_user_id: full.actor.userId,
    action: full.action,
    outcome_status: full.outcome.status,
    outcome_reason: full.outcome.reason ?? null,
    // ...weitere Felder
  });
}

Jetzt fügen wir den Aufruf in einen Handler ein, der eine Bestellung erstellt (nehmen wir an, es ist ein MCP‑Tool oder ein Server‑Endpoint):

// app/api/orders/route.ts
export async function POST(req: Request) {
  const user = await requireUser(req); // aus dem Auth‑Modul
  const body = await req.json();
  const order = await createOrderInDb(user, body);

  await logAudit({
    actor: { userId: user.id, client: "chatgpt-app" },
    action: "order.create",
    resource: { type: "order", id: order.id },
    context: { mcpTool: "create_order_tool" },
    outcome: { status: "success" },
  });

  return Response.json(order);
}

Dasselbe können Sie um gefährliche Operationen herum tun – Bestellung stornieren, Zahlungsdaten ändern, Account löschen.

Wir haben eine separate, strukturierte Audit‑Schicht — hervorragend. Die nächste natürliche Frage lautet: Wie lange sollen all diese Ereignisse (und die übrigen Nutzerdaten) leben und was passiert nach Ablauf?

3. Data Retention: Wie lange leben Ihre Daten?

Warum man nicht alles ewig speichert

Der Ingenieursreflex „könnte ja noch nützlich sein“ ist bei Nutzerdaten sehr gefährlich.

Erstens: Je länger und mehr Daten Sie sammeln, desto schwerer die Folgen im Falle eines Leaks: je voller das Benzinfass, desto schlimmer der Brand. Viele Datenschutz‑Guidelines nennen Daten explizit ein „toxisches Asset“: sinnvoll aufbewahren, aber Umfang und Dauer minimieren.

Zweitens: Rechtsrahmen wie GDPR/CCPA etablieren das Prinzip „nicht länger als für den Zweck erforderlich“. Personenbezogene Daten dürfen also nicht endlos „zur Sicherheit“ liegen bleiben. Für jeden Datentyp braucht es klare Aufbewahrungsfristen und Verfahren zum Löschen oder Anonymisieren.

Drittens: Cloud‑Speicher kostet Geld. Große Log‑Tabellen und Chat‑Historien wachsen schnell, und nach einem Jahr stellt sich heraus, dass die Hälfte der Cloud‑Rechnung „gestriger Müll“ ist.

Verschiedene Daten — unterschiedliche Fristen

Erfahrung und öffentliche Guidelines ergeben ungefähr dieses Bild:

Wichtig: Das ist keine Rechtsberatung, sondern technische Orientierung. Für ein reales Produkt stimmen Sie Fristen mit Juristen ab, aber technisch sollten Sie bereits verschiedene TTLs umsetzen können.

Wie Retention im Code umsetzen

Häufigstes Pattern: Die Tabelle hat created_at oder expires_at, und Sie haben einen periodischen Prozess, der alte Einträge löscht oder anonymisiert.

Beispiel: Säuberung normaler Logs, älter als 90 Tage.

// scripts/cleanup-logs.ts
import { db } from "../lib/db";

async function cleanup() {
  await db
    .deleteFrom("app_logs")
    .where("created_at", "<", new Date(Date.now() - 90 * 24 * 60 * 60 * 1000));
  console.log("Old logs removed");
}

cleanup().catch(console.error);

Diesen Skript kann man per Cron, über GitHub Actions nach Zeitplan oder mit dem Scheduler der Cloud starten.

Für PII wird statt Löschen oft anonymisiert. Beispielsweise verlieren Bestellungen älter als N Jahre die Verknüpfung zu einer konkreten Person:

UPDATE orders
SET user_id = NULL
WHERE created_at < now() - interval '3 years';

Dabei bleiben Summen, Artikel und andere „Buchhaltung“ erhalten, aber die Zuordnung zu einer Person entfällt.

Vergessen Sie nicht, dass Backups ebenfalls eigene Lebensdauern brauchen. Periodizität und Aufbewahrungsdauer der Backups besprechen wir im Backup‑Block, aber die Idee ist gleich: Auch Archive dürfen nicht ewig liegen, sonst wird das „Recht auf Vergessenwerden“ zur Fiktion.

4. Löschung auf Anfrage des Nutzers: „Recht auf Vergessenwerden“ im Code

Woher kommt die Anforderung

Die europäische GDPR (und ähnliche Gesetze) führt das sogenannte „Recht auf Vergessenwerden“ ein: Ein Nutzer kann die Löschung seiner personenbezogenen Daten verlangen, und das Unternehmen muss dies ohne unangemessene Verzögerung umsetzen.

Für Sie als Entwickler heißt das: Früher oder später kommt eine Anfrage „Löscht alle Daten über mich“ (oder Sie bieten selbst einen Button „Delete my data“ an), und dann muss nicht nur der Eintrag in users verschwinden, sondern der ganze Pfad: Bestellungen, Sessions, Token, Aktivitäts‑Logs, CRM, Zahlungen usw.

Es gibt jedoch auch Gesetze, die die Aufbewahrung bestimmter Daten verlangen: etwa Finanztransaktionen. Der juristische Teil ist also komplexer als der technische.

Was genau zu bereinigen ist

Minimalset für unseren GiftGenius:

• Nutzerprofil (Name, E‑Mail, Einstellungen);
• Sessions, Refresh‑Token, Verknüpfungen zu OAuth‑Providern;
• Bestellungen, sofern sie nicht in „personalisierter Form“ benötigt werden (oder anonymisiert werden können);
• Logs und Audit‑Einträge, in denen PII liegt (z. B. E‑Mail im Rohformat).

Es verbleiben Daten, die für Berichte wichtig sind, aber bereits anonymisiert — Bestellsummen, Anzahl Transaktionen, Aggregate nach Ländern etc.

Beispiel eines Lösch‑Ablaufs

Ablaufschema:

1. Der (angemeldete) Nutzer klickt „Meinen Account löschen“.
2. An den Server geht eine Anfrage mit seinem userId.
3. Der Server:
   • löscht/anonymisiert abhängige Einträge (Bestellungen, Sessions, Integrationen);
   • entfernt PII im Profil;
   • schreibt einen Audit‑Log „Löschanfrage verarbeitet“.

Der Einfachheit halber zeigen wir einen Minimalfall über zwei Tabellen. Im realen Produkt ergänzen Sie weitere Entitäten (Integrationen, Drittservices etc.).

Service‑Code in Next.js (vereinfachtes Beispiel):

// app/api/delete-me/route.ts
import { db } from "@/lib/db";
import { logAudit } from "@/lib/audit";

export async function POST(req: Request) {
  const user = await requireUser(req);

  await db.transaction(async (tx) => {
    await tx.deleteFrom("sessions").where("user_id", "=", user.id);
    await tx.deleteFrom("orders").where("user_id", "=", user.id);

    await tx.updateTable("users")
      .set({
        is_deleted: true,
        name: null,
        email: null,
      })
      .where("id", "=", user.id);

    await logAudit({
      actor: { userId: user.id, client: "chatgpt-app" },
      action: "account.delete",
      outcome: { status: "success" },
    });
  });

  return new Response(null, { status: 204 });
}

In der Realität fügen Sie hier Aufrufe externer APIs hinzu (z. B. Stripe – um den customer zu lösen), und die Transaktion gestalten Sie robuster. Das Prinzip steht: alles an einem Ort, mit Audit‑Eintrag.

Bezug zu Backups

Der knifflige Teil „und was ist mit Backups?“ wirft viele Fragen auf. Selbst wenn Sie den Nutzer aus der Produktions‑DB gelöscht haben, können seine Daten in nächtlichen Snapshots verbleiben. Damit das nicht zu „faktisch löschen wir nie jemanden“ wird, gibt es zwei Ansätze:

1. Backups leben selbst nur begrenzt (z. B. 30–90 Tage) und verschwinden dann zusammen mit den Daten. Nach Ablauf der Retention enthalten weder die Haupt‑DB noch die Archive den Nutzer.
2. Wenn Sie doch aus einem Backup wiederherstellen, führen Sie ein Register „gelöschter“ IDs und lassen nach dem Restore Lösch‑/Anonymisierungs‑Skripte erneut laufen.

In großen Unternehmen praktiziert man manchmal Crypto‑Shredding: PII des Nutzers wird mit einem separaten Schlüssel verschlüsselt, und bei der Löschanfrage wird genau dieser Schlüssel vernichtet. Selbst wenn irgendwo verschlüsselte Kopien verbleiben (in Logs, Backups), sind sie ohne Schlüssel nutzloser Müll. Das ist großartig, aber für ein Startup etwas raketenwissenschaftlich.

Wichtiger UX‑Aspekt

Denken Sie daran: Löschung ist nicht nur SQL. Der Nutzer erwartet:

• einen klaren Weg zur Anfrage (Button, Formular, E‑Mail);
• angemessene Fristen der Durchführung (in der Praxis bis zu 30 Tage);
• eine Erfolgsbenachrichtigung oder eine begründete Ablehnung (z. B. wenn Teile gesetzlich aufzubewahren sind).

Technisch haben Sie alles vorbereitet: Sie können bereinigen, die Aktion auditieren und nichts Überflüssiges in Backups behalten.

5. Business continuity & Backups

Stellen Sie sich vor, alles oben funktioniert perfekt … bis ein fataler DROP TABLE orders, ein Cloud‑Ausfall oder der Absturz einer Region passiert. Wir brauchen Mechanismen, um den Service in vertretbarer Zeit wiederherzustellen und kritische Daten nicht zu verlieren.

RTO und RPO — zwei Buchstaben, die Ihren Schmerz definieren

Zwei Basisparameter des Disaster Recovery:

• RTO (Recovery Time Objective) – wie lange Sie sich Unerreichbarkeit leisten können. Beispiel: Wenn RTO = 1 Stunde ist, müssen Sie das System nach einem schweren Ausfall spätestens nach einer Stunde wieder hochfahren.
• RPO (Recovery Point Objective) – wie viele Daten Sie zeitlich verlieren dürfen. Wenn RPO = 10 Minuten ist, dürfen beim Restore maximal die letzten 10 Minuten Historie fehlen.

Je kritischer das Produkt (Banking, Handelssysteme), desto näher beide Parameter an null. Für den Lern‑GiftGenius kann man mit RTO ~ ein paar Stunden und RPO ~ 15–60 Minuten leben, aber auch das muss umgesetzt werden.

Was kann in Ihrem Stack schiefgehen

Im Kontext einer ChatGPT‑App auf Vercel + Cloud‑DB + externe APIs sind typische Probleme:

• OpenAI‑API nicht verfügbar: Ihre App antwortet mit Fehlern auf Tool‑Calls.
• Vercel (oder andere) haben einen Ausfall: Das Widget erreicht Ihr Backend nicht.
• Datenbank beschädigt oder etwas versehentlich gelöscht (z. B. DROP TABLE).
• Konto kompromittiert, das die Infrastruktur verwaltet.

Dem begegnen Sie mit einer Kombination aus Backups, Replikation und einem vernünftigen App‑Verhalten bei Ausfällen.

Backup‑Strategien

Moderne Cloud‑Postgres/andere DBs bieten meist mindestens drei Optionen:

1. Voll‑Backups + inkrementelle.
   Täglich einen vollständigen Snapshot der DB machen und dazwischen inkrementelle Änderungen speichern. Restore = Rücksprung auf einen Snapshot und Abspielen des Änderungsjournals.
2. Point‑in‑Time Recovery (PITR).
   Die DB schreibt das Transaktionsjournal (WAL) und erlaubt die Wiederherstellung auf einen beliebigen Zeitpunkt (z. B. „Stand 14:03:00, bevor wir die Tabelle gedroppt haben“).
3. Replikation in eine andere Region.
   Eine passive oder aktive Replik der DB in einer anderen Region/Cloud halten. Fällt die Hauptregion aus, kann die App auf die Replik umschalten und verliert nur Daten, die noch nicht repliziert waren.

Für unseren Maßstab reicht meist: PITR beim DB‑Provider aktivieren und periodische Off‑Site‑Backups.

Einfaches Beispiel: täglicher Dump für lokale/dev‑DB

Selbst wenn Sie in Prod eine Managed‑DB nutzen, wollen Sie für Staging/Dev manchmal ein simples Skript:

# scripts/backup.sh
#!/usr/bin/env bash
set -e
DATE=$(date +%F)
pg_dump "$DATABASE_URL" > "backups/backup-$DATE.sql"
echo "Backup created: backups/backup-$DATE.sql"

Start per Cron oder GitHub Actions. Wichtig: Backups müssen ebenfalls nach Aufbewahrungsfrist gelöscht werden.

Verhalten der App bei Ausfällen externer Dienste

Backups und PITR lösen das Problem „was tun, wenn alles kaputt ist oder Daten korrupt sind“. In der Geschäftspraxis treten jedoch öfter partielle Ausfälle auf — externe API down, Netzwerk abgeschnitten, Payment hängt.

Wenn OpenAI‑API oder Payment flachliegen, ist die schlechteste Strategie ein nackter 500er mit sinnlosem Stack Trace. Ideal ist:

• Der Backend gibt einen strukturierten Fehler wie { error: "upstream_unavailable" } zurück;
• Das Widget zeigt eine verständliche Meldung: „Service vorübergehend nicht verfügbar, bitte später erneut versuchen“;
• Das System bombardiert die liegende API nicht mit endlosen Retries (Circuit Breaker‑Pattern etc. betrachten wir im Modul zur Resilienz).

Beispiel eines MCP‑Tools, das einen externen Fehler berücksichtigt:

// mcp/tools/createGiftIdea.ts
export async function createGiftIdea(args: Input): Promise<Output> {
  try {
    return await callOpenAiModel(args);
  } catch (err) {
    await logAudit({
      actor: { userId: args.userId ?? null, client: "chatgpt-app" },
      action: "giftidea.generate",
      outcome: { status: "failure", reason: "openai_unavailable" },
    });
    throw new Error("UPSTREAM_UNAVAILABLE");
  }
}

Ihre Zwischenschicht zwischen MCP und Widget weiß anschließend, wie diese Fehlermeldung im UI sauber darzustellen ist.

Wiederherstellung testen: Ein Backup ohne Restore ist nur eine Datei

Klassischer Anti‑Pattern: Das Backup läuft täglich, alle sind zufrieden … bis sich herausstellt, dass es sich nicht wiederherstellen lässt (Format geändert, Schlüssel verloren, Speicher vollgelaufen).

Minimalplan:

• periodisch (z. B. monatlich) ein Staging‑Umfeld aus einem Backup hochziehen;
• Basis‑Szenarien durchgehen: Login, Bestellung anlegen, App‑Funktion;
• sicherstellen, dass Wiederherstellungszeit und Datenverlust innerhalb Ihrer RTO/RPO liegen.

Statt eines Kurses in „DevOps‑Religion“ genügt hier: Backup‑Prozesse sind Teil der App‑Architektur, nicht „etwas, das irgendwer in der Cloud schon machen wird“.

6. Visualisierung: Lebenszyklus von Daten und Ereignissen

Damit das nicht nur Worte sind, zeichnen wir zwei einfache Diagramme.

Lebenszyklus der Nutzerdaten

flowchart TD
  A["Datenerzeugung<br/>(Registrierung, Bestellung)"] --> B["Speicherung und Nutzung<br/>(Prod‑DB)"]
  B --> C["Archiv/Aggregation<br/>(anonyme Metriken)"]
  B --> D[Anfrage auf Löschung]
  D --> E[Löschung/Anonymisierung<br/>in der Prod‑DB]
  E --> F["Ablauf der Aufbewahrungsfrist von Backups<br/>(Retention)"]
    

Kerngedanke: Der Datenlebenszyklus endet nicht in der Prod‑DB — er setzt sich in den Backups fort.

Audit‑Fluss für eine riskante Aktion

sequenceDiagram
  participant User as Nutzer
  participant ChatGPT as ChatGPT
  participant App as Ihr Backend/MCP
  participant DB as Datenbank
  participant Audit as Audit‑Speicher

  User->>ChatGPT: "Bestellung #123 stornieren"
  ChatGPT->>App: callTool cancel_order
  App->>DB: UPDATE orders SET status='canceled'
  App->>Audit: INSERT audit_event {actor, action, resource, outcome}
  App-->>ChatGPT: Ergebnis der Operation
  ChatGPT-->>User: Meldung zum Ergebnis
    

7. Typische Fehler in Audit & Lifecycle

Fehler Nr. 1: Audit‑Logs und normale Logs mischen.
Wenn alle Meldungen in einen gemeinsamen logs‑Index laufen, unterscheidet nach einem halben Jahr niemand mehr „Nutzer hat Admin‑Rolle geändert“ von „wir haben wieder eine Null‑Referenz“. Ins Audit gehören strukturierte Ereignisse auf Business‑Ebene (siehe Abschnitt zur Struktur eines Audit‑Events) und ein separater Speicher mit eingeschränktem Zugriff.

Fehler Nr. 2: PII in Audit und Debug‑Logs loggen.
Volle E‑Mail, Telefonnummer, Lieferadresse, letzte vier Kartenziffern – all das landet oft versehentlich in Logs. Das erhöht das Leck‑Risiko und widerspricht Privacy‑Empfehlungen. Loggen Sie stattdessen IDs und maskierte Werte.

Fehler Nr. 3: Keine Retention‑Policy — „wir speichern alles für immer“.
Im MVP wirkt das harmlos, doch nach einem Jahr sind Tabellen monströs groß und jede Analytics‑Abfrage wird zum DDoS gegen die DB. Außerdem verstoßen Sie gegen das Prinzip der Datenminimierung moderner Datenschutzgesetze. Minimale TTLs je Datentyp müssen durchdacht und die Bereinigung automatisiert sein.

Fehler Nr. 4: „Löschung auf Anfrage“ == DELETE FROM users.
Wenn Sie nur die Nutzerzeile löschen, aber PII in Bestellungen, Sessions und Logs belassen, haben Sie de facto niemanden gelöscht. Korrekt ist ein transaktionales Vorgehen über alle verbundenen Entitäten; wo Löschen nicht geht, wird anonymisiert. Und den Löschvorgang selbst als Audit‑Event loggen.

Fehler Nr. 5: Backups bei der Datenlöschung ignorieren.
Nutzer in Prod gelöscht – gut, aber seine Daten leben noch ein Jahr in alten Snapshots. Beim Restore „aufersteht“ alles, und Sie brechen Ihre eigenen Zusagen gegenüber Nutzer und Privacy Policy. Entweder die Lebensdauer der Backups begrenzen oder ein Verfahren zum erneuten Anwenden von Löschungen nach dem Restore haben.

Fehler Nr. 6: „Backups sind an, also ist alles gut“, aber niemand hat das Restore geübt.
Ein Backup, das nie auf Restore getestet wurde, ist nur eine teure Datei. Ohne regelmäßige Wiederherstellungs‑Tests kennen Sie weder Ihr tatsächliches RTO/RPO noch ob Ihr DR‑Plan überhaupt funktioniert. Minimum: regelmäßiges Test‑Staging aus einem Backup nach Checkliste.

Fehler Nr. 7: Diskrepanz zwischen Dokumentation und Realität.
In der Privacy Policy steht, dass Sie Logs 30 Tage speichern und Daten auf Anfrage löschen, aber im Code bleibt alles ewig. ChatGPT‑Store, Enterprise‑Kunden und Auditoren finden das leicht heraus mit Fragen wie „zeigen Sie die Retention‑Tabelle“ und „demonstrieren Sie die Löschung eines konkreten Nutzers“. Besser erst umsetzen, dann aufschreiben.