Alle Schlüssel werden in Azure Key Vault gespeichert und über External Secrets in Kubernetes-Pods
eingebunden – niemals in Code oder Konfigurationsdateien. Die Schlüsselrotation erfolgt automatisiert. Der Zugriff wird über Azure RBAC mit Just-in-Time-Rechteerhöhung für Notfallszenarien gesteuert; jede Schlüsselverwendung wird protokolliert.

Der Zugriff wird über einen formellen Anfrageprozess bereitgestellt. Alle Zugriffe sind auf das für die Rolle erforderliche Minimum beschränkt. Temporär erhöhte Zugriffsrechte erfordern eine Genehmigung und werden nach einem definierten Zeitraum automatisch widerrufen. Systemverantwortliche führen quartalsweise Zugriffsprüfungen durch. 

Statische Datenbankpasswörter sind nicht zulässig. Anwendungsdienste verbinden sich über ManagedIdentity-Token, die von Azure AD ausgegeben werden. Menschlicher Zugriff erfordert eine formelle, zeitlich begrenzte Anfrage und wird vollständig protokolliert. Datenbankzugriffsprotokolle werden für den Audit-Trail aufbewahrt. 

Produktionsknoten laufen auf Azure Kubernetes Service. Direkter Knotenzugriff ist für Routinevorgänge deaktiviert. Notfallzugriff erfolgt über kurzlebige Zugangsdaten aus einem PAM-Workflow mit vollständiger Sitzungsaufzeichnung. Knoten sind nach CIS-Benchmarks gehärtet und werden automatisch gepatcht. 

Azure VNets erzwingen strenge eingehende und ausgehende Regeln. Produktionssubnetze sind aus dem öffentlichen Internet nicht erreichbar, ohne WAF- und Firewall-Regelwerke zu passieren. Änderungen, die Netzwerkgrenzen beeinflussen, erfordern vor dem Deployment die Freigabe des Sicherheitsteams. 

Alle Firewall-Änderungen durchlaufen vor dem Deployment peer-reviewte Pull Requests. Nicht genutzte Regeln werden markiert und im Rahmen quartalsweiser Reviews entfernt. Azure-NSG-Flow-Logs werden zur kontinuierlichen Bedrohungsanalyse in das SIEM exportiert.

Kubernetes-Netzwerkrichtlinien beschränken die Pod-zu-Pod-Kommunikation auf explizit definierte Pfade. Azure VNet Peering und private Endpunkte stellen sicher, dass Speicher- und Datenbankverkehr niemals über das öffentliche Internet läuft. Isolation auf Namespace-Ebene wird in der Compute-Schicht durchgesetzt. 

VPN- und Bastion-Zugriff erfordern phishing-resistente MFA (FIDO2 oder TOTP). Conditional Access in Azure AD erzwingt MFA für alle produktionsbezogenen Konten unabhängig vom Netzwerkstandort. SSH mit zertifikatsbasierter Authentifizierung ist das einzige genehmigte Serverzugriffsprotokoll. Legacy-Protokolle (RDP über Internet, Telnet, FTP) werden durch Firewall-Richtlinien blockiert.

Automatisierte Konto-Audits erkennen und markieren gemeinsam genutzte Konten. Dienstkonten nutzen Azure Managed Identities oder Workload Identity. Menschliche Konten sind in Azure AD einer namentlich benannten Person zugeordnet. Konten, die 90 Tage inaktiv sind, werden bis zur Zugriffsprüfung automatisch deaktiviert. 

Cloudflare stellt L3/L4-DDoS-Abwehr, WAF-Regeldurchsetzung und Rate Limiting am Edge bereit. Azure DDoS Protection Standard ist auf VNet-Ebene aktiviert. Verkehrsanomalien lösen automatisierte Alarmierungen und Response-Playbooks aus, die nach dem Incident überprüft werden. 

Protokolle aus AKS, Azure Firewall, Key Vault und Anwendungsdiensten werden an ein zentrales SIEM übertragen. Alarmregeln decken Authentifizierungsanomalien, Rechteausweitungen, ungewöhnlichen Datenabfluss und fehlgeschlagene Zugriffsmuster ab. Bereitschafts-Runbooks definieren Reaktionsverfahren für jede Alarmklasse. Alle Alarme werden nach der Behebung überprüft und zur Reduzierung von Fehlalarmen angepasst. 

Drei Anwendungsrollen (Organisationsadministrator, Workspace-Administrator, regulärer Benutzer) und drei Inhaltsrollen (Betrachter, Mitwirkender, Verantwortlicher) decken die Mehrheit der Anwendungsfälle ab. Benutzerdefinierte Rollen können innerhalb einer vorab genehmigten Berechtigungsmatrix erstellt werden. Alle Rollenzuweisungen werden protokolliert und sind prüfbar.

EmpowerGPT unterstützt die Föderation mit Azure AD, Okta, Google Workspace und jedem kompatiblen Identitätsanbieter (IdP). Bei einer föderierten Anmeldung wird die Authentifizierung — einschließlich MFA — vollständig an den IdP des Kunden delegiert. Von Keycloak ausgestellte Sitzungstoken sind kurzlebig und werden bei jeder Anfrage validiert.

Für Enterprise-Benutzer mit einem IdP wird MFA durch den Identitätsanbieter des Kunden erzwungen. Für lokale Authentifizierungskonten ist TOTP-basierte MFA über Keycloak verpflichtend. Organisationsadministratoren können phishing-resistente MFA-Richtlinien für ihre Mandanten verlangen.

Die SCIM-Provisionierung unterstützt ein automatisiertes Benutzer-Lifecycle-Management über den IdP des Kunden. Plattformkonten, die seit 90 Tagen inaktiv sind, werden markiert. Organisationsadministratoren können den Zugriff sofort widerrufen und aktive Sitzungen beenden. Der Entzug des Zugriffs auf EmpowerGPT ist ein verpflichtender Schritt in der internen Offboarding-Checkliste.

Azure AD Privileged Identity Management (PIM) steuert erhöhte Zugriffsrechte auf Produktionsressourcen. Permanente Besitzer- oder Mitwirkender-Rollen sind für Produktionsabonnements nicht zulässig. Jeder erhöhte Zugriff erfordert eine Begründung, eine Freigabe durch einen zweiten Engineer und läuft spätestens nach 8 Stunden ab.

Vierteljährliche Zugriffsprüfungen decken alle Produktionssysteme ab. Prüfer erhalten strukturierte Zugriffsberichte und müssen jede Zuweisung entweder als weiterhin erforderlich bestätigen oder zur Entfernung markieren. Die Ergebnisse der Prüfungen werden dokumentiert und als SOC-2-Nachweise aufbewahrt. Konten, die seit mehr als 60 Tagen nicht genutzt wurden, werden bei der Prüfung priorisiert.

Keycloak erzwingt eine Mindestlänge von 12 Zeichen, Komplexitätsanforderungen und ein Wiederverwendungsverbot über 12 Passwortzyklen. Passwörter werden als gesalzene bcrypt-Hashes gespeichert — niemals im Klartext. Administratorkonten müssen einen genehmigten Passwortmanager verwenden. Ein progressiver Backoff sperrt Konten nach wiederholten fehlgeschlagenen Anmeldeversuchen.

Azure Storage und PostgreSQL verwenden AES-256-Verschlüsselung für ruhende Daten mit kundenseitig verwalteten Schlüsseln in Azure Key Vault. Die Verschlüsselung auf Festplattenebene ist auf allen Compute-Knoten aktiviert. Backups werden mit derselben Schlüsselhierarchie verschlüsselt. Die Funktionstrennung stellt sicher, dass der Zugriff auf verschlüsselte Daten sowohl Speicherzugriffsrechte als auch Zugriffsrechte auf den Key Vault erfordert.

TLS 1.3 wird auf allen öffentlichen Endpunkten erzwungen. Zusätzlich wird auf Anwendungsebene AES-256-Verschlüsselung mit ephemeren Sitzungsschlüsseln auf Anfrage-Payloads angewendet — die Schlüssel werden lokal abgeleitet und niemals übertragen, wodurch Inhalte selbst im Falle einer TLS-Kompromittierung geschützt bleiben. HSTS wird erzwungen. TLS 1.2 und niedrigere Versionen werden abgelehnt.

Jede API-Anfrage enthält ein mandantenbezogenes JWT, das von Keycloak validiert wird. Datenbankabfragen enthalten verpflichtende tenant_id-Prädikate, die auf ORM-Ebene erzwungen werden — deren Umgehung löst eine Sicherheitsausnahme aus. Storage-Container sind nach Mandanten partitioniert. Die mandantenübergreifende Isolation ist ein ausdrücklich definiertes Ziel der jährlichen Penetrationstests.

Benutzerprofildaten sind auf Name, E-Mail-Adresse und Organisation beschränkt. Es erfolgt kein Ad-Targeting und kein verhaltensbasiertes Profiling. PostHog Analytics erfasst ausschließlich Produktnutzungsereignisse — niemals Prompt-Inhalte. Betroffene Personen können jederzeit über das Datenschutzportal der Plattform den Export oder die Löschung ihrer Daten beantragen.

Das primäre Hosting erfolgt in Azure Germany West Central. Die Azure-OpenAI-Inferenz nutzt dieselbe Region. Google Cloud AI ist auf ausschließlich EU-basierte Endpunkte konfiguriert. Die Auswahl eines global bereitgestellten Modells, dem einzigen Weg zu einer Inferenz außerhalb der EU, ist eindeutig gekennzeichnet und wird im Audit-Trail protokolliert.

Die Vereinbarung für Microsofts Azure OpenAI Service untersagt ausdrücklich das Training mit Kundendaten sowie deren Weitergabe an OpenAI. Dieselbe Einschränkung gilt für Google Cloud AI. EmpowerGPT selbst verwendet Kundengesprächsdaten nicht für das Fine-Tuning von Modellen, es sei denn, es liegt eine ausdrückliche schriftliche Zustimmung der Kundenorganisation vor.

Automatisierte tägliche Backups mit Point-in-Time-Recovery decken die vergangenen 30 Tage ab. Backups werden in einer geografisch getrennten Azure-Region gespeichert. Wiederherstellungsverfahren sind dokumentiert und werden jährlich getestet. RTO- und RPO-Ziele sind im Disaster-Recovery-Plan definiert und Enterprise-Kunden auf Anfrage verfügbar.

Anfragen werden über das Datenschutzportal der Plattform oder per E-Mail an den Datenschutzbeauftragten entgegengenommen, innerhalb von 72 Stunden bestätigt und innerhalb von 30 Tagen erfüllt (Artikel 12 DSGVO). Organisationsadministratoren können alle Benutzerdaten direkt über das Admin-Panel exportieren oder löschen. Die Löschung wird nach Ablauf der Aufbewahrungsfrist auf alle Speicherebenen einschließlich Backups übertragen.

Prüfungen werden über einen zertifizierten Screening-Anbieter durchgeführt und umfassen Identitätsprüfung, Arbeitsberechtigung und Beschäftigungsverlauf. Für Rollen mit erhöhten Zugriffsrechten gelten erweiterte Prüfungen. Die Ergebnisse werden von der Personalabteilung und dem CISO geprüft, bevor das Onboarding abgeschlossen wird. Eine erneute Überprüfung wird durch wesentliche Rollenänderungen ausgelöst.

Schulungen werden über eine verwaltete Plattform mit Nachverfolgung des Abschlussstatus bereitgestellt. Die Module umfassen Phishing-Erkennung, Umgang mit Daten, Meldung von Vorfällen und akzeptable Nutzung. Rollenspezifische Inhalte behandeln sicheres Programmieren und Secrets Management für Engineers. Vierteljährliche Phishing-Simulationen ergänzen die formalen Schulungen. Abschlussquoten werden an das Management und den Vorstand berichtet.

Mitarbeitende unterzeichnen im Rahmen ihres Arbeitsvertrags eine Vertraulichkeitsklausel. Auftragnehmer und Lieferanten unterzeichnen eine eigenständige Vertraulichkeitsvereinbarung (NDA), bevor sie Systemzugriff erhalten. Die Verpflichtungen bleiben auch nach Beendigung der Arbeitsbeziehung bestehen. Bestätigungsnachweise werden im HR-System aufbewahrt und sind prüfbar.

Unternehmenseigene Laptops und mobile Geräte müssen in Microsoft Intune registriert sein, bevor sie sich an Produktionssystemen authentifizieren können. Die MDM-Richtlinie erzwingt: vollständige Festplattenverschlüsselung, einen Mindeststand bei Betriebssystem-Patches, eine Bildschirmsperre nach 5 Minuten sowie die Installation eines EDR-Agenten. Nicht verwaltete Geräte werden durch Azure AD Conditional Access blockiert.

Die Richtlinie untersagt die Speicherung von Kundendaten auf unverschlüsselten Wechseldatenträgern. MDM erzwingt die Verschlüsselung auf jedem zulässigen USB-Speichergerät. Mitarbeiterschulungen behandeln die zulässige Nutzung von Speichermedien im Rahmen des Onboardings. Richtlinienverstöße lösen eine automatische Benachrichtigung an das Sicherheitsteam aus.

Jährliche Beurteilungen erfolgen anhand eines strukturierten Rahmens, der von den direkten Führungskräften verwaltet wird. Sicherheitsrelevante Verhaltensweisen — Abschluss von Schulungen, Meldung von Vorfällen, Zugriffshygiene — sind in den Rollenprofilen für technische und operative Mitarbeitende enthalten. Die Ergebnisse der Beurteilungen fließen, sofern relevant, in Entscheidungen zur Rezertifizierung von Zugriffsrechten ein.

Die Richtlinie zur akzeptablen Nutzung (AUP) umfasst: Einschränkungen bei der Installation nicht genehmigter Software, verbotene Inhalte, Weitergabe von Zugangsdaten und den Umgang mit Kundendaten. Die Bestätigung wird im HR-System nachverfolgt. Verstöße unterliegen Disziplinarmaßnahmen bis hin zur Kündigung.

Terraform und Helm-Charts definieren die gesamte Azure- und Kubernetes-Infrastruktur. Änderungen erfolgen über Pull Requests, die die Genehmigung von mindestens einem Senior Engineer erfordern und vor dem Merge automatisiertes Security-Linting (tfsec, checkov) bestehen müssen. Direkte Infrastrukturänderungen außerhalb der IaC-Pipeline werden blockiert und überwacht.

Die CI/CD-Pipeline umfasst: SAST über Semgrep, Dependency-Scanning über Dependabot und OWASP Dependency-Check, Container-Image-Scanning über Trivy sowie Infrastruktur-Security-Scanning. Kritische und hohe Befunde blockieren das Deployment. Scan-Ergebnisse werden im Vulnerability-Management-Backlog mit zugewiesenen Verantwortlichen nachverfolgt.

Standardänderungen erfordern ein Ticket, einen Testplan, die Freigabe durch einen autorisierten Change Approver sowie ein dokumentiertes Rollback-Verfahren. Notfalländerungen werden von diensthabenden Engineering-Leads genehmigt und nach dem Deployment überprüft. Änderungsnachweise werden zu Audit-Zwecken aufbewahrt. Fehlgeschlagene Deployments erstellen automatisch ein Incident-Ticket.

Dependabot scannt täglich alle Repositories und erstellt Pull Requests für verwundbare Abhängigkeiten. SLAs: Kritisch — 72 Stunden; Hoch — 7 Tage; Mittel — 30 Tage. Der Patch-Status wird wöchentlich vom Sicherheitsteam überprüft. Ausnahmen erfordern die Genehmigung des CISO mit einer dokumentierten kompensierenden Kontrolle.

Baselines für AKS-Knoten, Azure-VM-Images und Container-Basis-Images sind an CIS-Benchmarks ausgerichtet. Azure Policy erzwingt konforme Konfigurationen und alarmiert bei Abweichungen. Die Compliance wird monatlich an das Sicherheitsteam berichtet. Nicht konforme Ressourcen werden innerhalb des definierten SLA behoben oder eskaliert.

Pre-Commit-Hooks und CI-Scanning lehnen Commits ab, die Zugangsdatenmuster oder Private-Key-Formate enthalten. Application Secrets werden in Azure Key Vault gespeichert und beim Pod-Start über den External Secrets Operator abgerufen. Kubernetes Secrets werden für ruhende Daten mit einem von Key Vault verwalteten Schlüssel verschlüsselt. Die Rotation von Secrets wird automatisiert, soweit dies technisch möglich ist.

Geplante Wartungsfenster werden mit einer Vorankündigung von mindestens 48 Stunden auf der EmpowerGPT-Statusseite veröffentlicht. Änderungen an Unterauftragsverarbeitern, Datenflüssen oder wesentlichen Sicherheitskontrollen werden per In-App-Benachrichtigung und E-Mail an den benannten Sicherheitskontakt des Kunden kommuniziert. Notfallwartungen werden so früh wie praktikabel mitgeteilt.

Die Risikomethodik ist an ISO 27001 Anhang A ausgerichtet und folgt einem asset-basierten Ansatz. Für jedes identifizierte Risiko werden Risikoverantwortliche zugewiesen. Behandlungspläne (akzeptieren, mindern, übertragen, vermeiden) werden dokumentiert und vierteljährlich überprüft. Das Risikoregister wird im jährlichen Sicherheitsbriefing für den Vorstand zusammengefasst.

Jährliche Black-Box- und Grey-Box-Tests decken Anwendungssicherheit, API-Sicherheit, Umgehung der Authentifizierung, Rechteausweitung und mandantenübergreifende Isolation ab. Kritische Befunde werden innerhalb von 72 Stunden behoben; hohe Befunde innerhalb von 30 Tagen. Testberichte stehen Enterprise-Kunden unter einer Vertraulichkeitsvereinbarung (NDA) zur Verfügung. Befunde und der Status der Behebung werden dem Vorstand berichtet.

EmpowerGPT unterhält eine E-Mail-Adresse für die Meldung von Sicherheitslücken. Eingehende Meldungen werden innerhalb von 5 Werktagen bestätigt. Es gelten behebungsfristen basierend auf dem Schweregrad. Forschende, die qualifizierende Schwachstellen in gutem Glauben melden, werden öffentlich anerkannt, sofern sie dies nicht anders wünschen.

Der Plan folgt den Phasen des NIST-Frameworks. Zu den Rollen gehören Incident Commander, Security Lead, Communications Lead und Legal. Jährliche Tabletop-Übungen beziehen Engineering, Sicherheit und Führungsebene ein. Erkenntnisse aus Übungen und realen Vorfällen fließen in Aktualisierungen des Plans ein.

Erkennungsregeln decken Folgendes ab: Authentifizierungsanomalien, ungewöhnliche API-Aufrufvolumina, Spitzen beim Datenabfluss, Rechteausweitung und laterale Bewegung. Schweregradstufen für Alarme (P1–P4) sind definierten Reaktionszielen zugeordnet. Ein Bereitschaftsdienstplan stellt sicher, dass rund um die Uhr ein qualifizierter Security Responder erreichbar ist. Die Abstimmung der Alarme wird nach jedem Vorfall überprüft.

Assessments sind anhand der SOC 2 Trust Service Criteria und ISO 27001 Anhang A strukturiert. Kontrollverantwortliche führen Walkthroughs durch und stellen Nachweisstichproben bereit. Lücken werden als Maßnahmen zur Behebung mit Verantwortlichen und Zielterminen erfasst. Die Ergebnisse der Selbsteinschätzungen fließen in den Umfang des jährlichen externen Audits ein.

Das Verfahren zur Reaktion auf Datenschutzverletzungen umfasst: eine erste Triage zur Bestimmung des Umfangs; einen 72-Stunden-Entscheidungspunkt zur Benachrichtigung der Aufsichtsbehörde; Verfahren zur Kundenbenachrichtigung; sowie die Eskalation an den Datenschutzbeauftragten (DPO) und die Rechtsberatung. Aufzeichnungen zu Datenschutzverletzungen werden gemäß Artikel 30 DSGVO geführt. Alle Personen mit Produktionszugriff werden in der Erkennung von Datenschutzverletzungen und den internen Meldepflichten geschult.

Die Bewertung umfasst: Sicherheitszertifizierungen (SOC 2, ISO 27001 oder gleichwertig), Datenresidenzstandorte, Offenlegung von Unterauftragsverarbeitern, Verpflichtungen zur Meldung von Datenschutzverletzungen sowie Klauseln zum Prüfungsrecht. Die Ergebnisse werden vom Sicherheitsteam geprüft. Hochrisiko-Anbieter benötigen vor dem Onboarding die Genehmigung des CISO.

Auftragsverarbeitungsverträge (DPAs) umfassen: Zweckbindung, Datenminimierung, Sicherheitsverpflichtungen, Löschfristen, Prüfungsrechte und Anforderungen zur Meldung von Datenschutzverletzungen. Wenn sich Unterauftragsverarbeiter außerhalb des EWR befinden, sind Standardvertragsklauseln oder gleichwertige Mechanismen vorhanden. Die Liste der Unterauftragsverarbeiter wird jährlich überprüft und auf der EmpowerGPT-Trust-Seite veröffentlicht.

Enterprise-Kunden erhalten bei Änderungen an Unterauftragsverarbeitern eine E-Mail-Benachrichtigung mit einer Vorankündigung von mindestens 30 Tagen. Die Benachrichtigung enthält die Art des Unterauftragsverarbeiters, die verarbeiteten Datenkategorien und den Verarbeitungsstandort. Kunden mit spezifischen vertraglichen Rechten gemäß Artikel 28 Absatz 2 DSGVO steht ein Widerspruchsverfahren zur Verfügung.

Der Zugriff von Anbietern erfolgt über einen separaten Kontotyp mit ausdrücklich abgegrenzten Berechtigungen. Permanenter Anbieterzugriff ist nicht zulässig. Alle Sitzungen werden protokolliert. Der Zugriff wird unmittelbar nach Abschluss des Engagements beendet. Anbieter mit aktiven Engagements unterliegen vierteljährlichen Zugriffsprüfungen.

Die Vereinbarung für Microsoft Azure OpenAI bestätigt: kein Training mit Kundendaten, keine Weitergabe an OpenAI, regionale Verarbeitung innerhalb der ausgewählten Azure-Region und Eigentum des Kunden an feinabgestimmten Modellen. Diese Verpflichtungen werden jährlich sowie bei jeder wesentlichen Änderung der Bedingungen des Anbieters überprüft. Entsprechende Prüfungen gelten für Google Cloud AI.

Das Rahmenwerk umfasst: Informationssicherheitsrichtlinie, Richtlinie zur akzeptablen Nutzung, Datenklassifizierungsrichtlinie, Richtlinie zur Reaktion auf Sicherheitsvorfälle, Zugriffskontrollrichtlinie, Schwachstellenmanagement-Richtlinie und Change-Management-Richtlinie. Richtlinien werden versioniert und allen Mitarbeitenden veröffentlicht. Eine Überprüfung wird durch wesentliche organisatorische oder regulatorische Änderungen sowie in einem festen jährlichen Zyklus ausgelöst.

Das jährliche Briefing umfasst: den Status des Risikoregisters, die Wirksamkeit von Kontrollen, wesentliche Vorfälle, Audit-Feststellungen sowie bevorstehende regulatorische Entwicklungen oder Entwicklungen der Bedrohungslage. Der Vorstand umfasst oder bezieht Mitglieder mit ausreichender technischer Expertise ein, um das Briefing zu bewerten. Sicherheitsbezogene Vorstandsprotokolle werden aufbewahrt.

Die Satzung legt Folgendes fest: Anforderungen an die Beschlussfähigkeit, Sitzungsfrequenz, Entscheidungsbefugnisse, Eskalationsschwellen für Sicherheitsvorfälle sowie den Prozess zur Einbindung externer Sicherheitsexpertise. Die Satzung wird jährlich überprüft. Eine Kopie steht Enterprise-Kunden auf Anfrage zur Verfügung.

Das Organigramm wird im HR-System gepflegt und vierteljährlich überprüft. Sicherheitsrollen — CISO, Datenschutzbeauftragter (DPO), Systemverantwortliche, Datenverwalter — werden formal mit dokumentierten Verantwortlichkeiten zugewiesen. Für zentrale Sicherheitsprozesse bestehen RACI-Matrizen. Der CISO berichtet direkt an den CEO und zusätzlich über eine gestrichelte Berichtslinie an den Vorstand.

Der Versicherungsschutz wird jährlich überprüft, um sicherzustellen, dass die Deckungsgrenzen weiterhin im angemessenen Verhältnis zum geschäftlichen Risikoprofil und zu den vertraglichen Verpflichtungen stehen. Versicherungszertifikate stehen Enterprise-Kunden auf Anfrage zur Verfügung. Der Erneuerungsprozess des Underwritings bietet selbst eine unabhängige Validierung zentraler Sicherheitskontrollen.

Der Disaster-Recovery-Plan definiert RTO- und RPO-Ziele nach Service-Tier. Wiederherstellungsverfahren decken den Ausfall der primären Azure-Region, Datenbankbeschädigung und die Nichtverfügbarkeit von Schlüsselpersonal ab. Jährliche Disaster-Recovery-Tests umfassen Failover-Simulationen und die Validierung der Backup-Wiederherstellung. Testergebnisse werden vom Management überprüft und in die jährliche Sicherheitszusammenfassung aufgenommen, die Enterprise-Kunden zur Verfügung steht.

Der Kanal wird von einem Drittanbieter verwaltet, um Anonymität sicherzustellen. Meldungen werden vom Datenschutzbeauftragten (DPO) und vom CISO geprüft. Vergeltungsmaßnahmen gegen meldende Personen sind in Arbeits- und Auftragnehmervereinbarungen ausdrücklich untersagt und werden als Disziplinarangelegenheit behandelt. Der Kanal wird im Onboarding und in der jährlichen Sicherheitsschulung kommuniziert.

Das Audit wird von einer akkreditierten CPA-Prüfungsgesellschaft über einen Zeitraum von 12 Monaten kontinuierlicher Kontrollausführung durchgeführt. Die Systembeschreibung wird gepflegt und zu Beginn jedes Audit-Zyklus überprüft. Der Type-II-Bericht — der die operative Wirksamkeit über einen Zeitraum nachweist — steht Enterprise-Kunden auf Anfrage unter einer Vertraulichkeitsvereinbarung (NDA) zur Verfügung.