DSGVO-Audit & Zugriffsprotokoll

betool ist darauf ausgelegt, die Anforderungen der DSGVO ohne aufgesetzte Compliance zu erfüllen: Jeder Zugriff auf Nutzerinhalte durch einen Agenten, der einer anderen Organisation angehört, wird protokolliert, und jede Organisation kann ihr eigenes Protokoll einsehen.

Das Zugriffsprotokoll

Eine dedizierte Tabelle erfasst für jeden mandantenübergreifenden Zugriff:

• Den Zeitstempel (Mikrosekundengenauigkeit)
• Die Ziel-Organisation (deren Inhalt gelesen wurde)
• Die lesende Organisation (typischerweise der Anbieter)
• Die Rolle / den Agenten / den Nutzer, der den Lesevorgang durchgeführt hat
• Den Entitätstyp (geschlossenes Vokabular: exchange_text, knowledge_chunk, audio_segment…)
• Die Entitäts-ID
• Den Nutzungskontext (Mission, Ticket, Vorschlag)

Das Entitätsvokabular ist auf Datenbankebene geschlossen (CHECK-Constraint) und auf Codeebene geschlossen (Anwendungs-Whitelist). Das Hinzufügen eines Typs erfordert eine neue Migration plus eine Aktualisierung der Whitelist. Keine überraschenden Einträge.

Auskunftsrecht (Artikel 15)

Jede Organisation kann IHRE EIGENEN Zugriffsprotokolle einsehen über:

GET /api/admin/me/content-reads

Verfügbare Filter: Zeitraum, Entitätstyp, Entitäts-ID, lesende Identität. CSV-/Excel-Export zur Weitergabe an einen Datenschutzbeauftragten.

Kein organisationsübergreifender Zugriff auf das Audit-Protokoll: Der Anbieter sieht niemals die Audit-Protokolle eines Kunden.

Recht auf Löschung (Artikel 17)

Drei Löschungsebenen werden unterstützt:

1. Nutzerlöschung — ein Endnutzer verlangt die Löschung seiner Daten innerhalb einer Kundenorganisation. Die Organisation löst die Löschung über das Administrationspanel oder die Admin-API aus.
2. Organisationslöschung — eine Organisation verlässt betool. Alle ihre Ressourcen werden gelöscht: nach org_id gefilterte Tabellen, geleerter Dateispeicher, entfernte Geheimnisse. Vertragliches Standardfenster: 30 Tage für einen Widerruf, danach unwiderrufliche Löschung.
3. Rechtliche Löschung — auf gerichtliche Anordnung Löschung bestimmter Elemente, ohne den Rest anzutasten. Im Audit-Trail mit einem Verweis auf die Rechtsgrundlage protokolliert.

Mandantenübergreifendes Lese-Opt-in & Opt-out

Standardmäßig ist das mandantenübergreifende Lese-Opt-in auf FALSE gesetzt. Eine Organisation kann es unter Administration → Datenschutz → Mandantenübergreifendes Lesen aktivieren.

Drei Modi:

• Vollständige Verweigerung — Standard. Der Anbieter kann auf keinen Inhalt dieser Organisation zugreifen. Konsequenz: Kein organisationsübergreifender Support auf Inhaltsebene ist möglich (struktureller Support und geschäftliche Flags bleiben verfügbar).
• Temporäres Opt-in — Autorisierung für ein festes Zeitfenster, widerrufbar.
• Dauerhaftes Opt-in — für Kunden, die proaktiven Support wünschen (selten im Bankwesen, üblich im Standard-SaaS).

Der Anbieter KANN dieses Opt-in NICHT im Namen des Kunden aktivieren. Dies ist ein grundlegender Test: Kann der Anbieter ohne eine Handlung des Kunden umschalten, ist die Architektur fehlerhaft.

Schutzvorrichtung für destruktive Operationen

Jede Operation, die Inhalte zerstört oder ersetzt (DELETE, REPLACE-IN-PLACE), wird am Validator verweigert, wenn die Zielorganisation das Lese-Opt-in nicht aktiviert hat. Begründung: Ohne Sichtbarkeit würde der Operator eine Nutzlast vorschlagen, die bestehende Inhalte blind überschreiben könnte.

Kaskadierende Verweigerung, wenn das Audit nicht verfügbar ist

Ist die Audit-Datenbank nicht verfügbar (Infrastrukturvorfall), werden alle mandantenübergreifenden Lesevorgänge verweigert. Strikte Richtlinie: kein Lesevorgang ohne Nachweis.

Codeseitige Konsequenz: Ein Aufrufer, der eine Ausnahme abfängt, muss den Audit-Fehler vor jeder Geschäftsverarbeitung erneut auslösen. Dies ist eine Invariante, die vom Sicherheits-Benchmark verifiziert wird.

Consent-Cookies

Auf der Marketing-Website und im Chat-Widget werden nur unbedingt notwendige Cookies gesetzt. Keine Analyse-Cookies von Drittanbietern ohne ein konformes Consent-Banner.