Information Security Policy

Diese Informationssicherheitsrichtlinie beschreibt die Zertifizierungen, die Didit besitzt, die technischen und organisatorischen Kontrollen, die Didit betreibt, und die Vertrauensartefakte, die Kunden, potenziellen Kunden, Aufsichtsbehörden und Auditoren zur Verfügung stehen. Sie wird mindestens alle sechs Monate überprüft.

• Sicherheitskontakt: security@didit.me
• Datenschutzbeauftragter: dpo@didit.me
• Statusseite (Echtzeit): status.didit.me
• Trust Pack (unter NDA): E-Mail an security@didit.me

1. Zertifizierungen und Bestätigungen

Um die zugrunde liegenden Berichte oder Zertifikate anzufordern, sende eine E-Mail an security@didit.me. Berichte, die gemäß den Bedingungen ihres Ausstellers eingeschränkt sind (z. B. SOC 2 Typ 1), werden nach Unterzeichnung einer Geheimhaltungsvereinbarung (NDA) am selben Werktag geteilt.

2. Geltungsbereich

Diese Richtlinie gilt für alle Didit-Mitarbeiter (Angestellte, Auftragnehmer und autorisierte Dritte), alle Didit-Produktions- und Unternehmensinformationssysteme sowie die kundenorientierten Dienste, die in den Geschäftsbedingungen beschrieben sind. Sie wird durch die Erklärung zur Anwendbarkeit unterstützt, die das ISO/IEC 27001:2022 Managementsystem von Didit untermauert.

3. Governance

• Informationssicherheits- und Datenschutzmanagementsystem ausgerichtet an ISO/IEC 27001:2022 und ISO/IEC 27701 Kontrollen, mit einer dokumentierten Erklärung zur Anwendbarkeit.
• Der Chief Technology Officer ist der benannte Informationssicherheits-Executive Sponsor; der Datenschutzbeauftragte (dpo@didit.me) ist für die Governance des Datenschutzprogramms verantwortlich.
• Jährliches externes Sicherheitsaudit durch unabhängige Auditoren (ISO 27001 Überwachung und SOC 2 Prüfungen).
• Risikoregister wird vierteljährlich überprüft und aktualisiert. Wesentliche Risiken werden an den Verwaltungsausschuss eskaliert.
• Kontinuierliche Verbesserung, jeder Vorfall, jedes Auditergebnis und jede Risikobewertung fließt in den Backlog für Korrekturmaßnahmen und die nächste Richtlinienaktualisierung ein.

4. Verschlüsselung und Schlüsselverwaltung

• Ruhend: AES-256 über jede Produktionsdatenbank, jeden Objektspeicher und jedes Backup-Volume.
• In Übertragung: TLS 1.3 für jeden externen API-Aufruf, Webhook und jede Business Console-Sitzung. Ältere TLS-Versionen und schwache Chiffren sind deaktiviert. HTTP Strict Transport Security (HSTS) wird websiteweit erzwungen und vorgeladen.
• Schlüsselverwaltung: AWS Key Management Service (KMS) verwaltet und rotiert die Schlüssel. Anwendungscode berührt niemals rohes Schlüsselmaterial. Sandbox- und Produktionsschlüssel sind vollständig getrennt.
• Hashing: Kundenanmeldeinformationen werden mit branchenüblichen adaptiven Funktionen (bcrypt oder gleichwertig) gehasht. API-Schlüssel werden als Einweg-Hashes gespeichert; der Rohwert wird dem Bediener nur zum Zeitpunkt der Erstellung angezeigt.

5. Identität, Zugriff und Zero-Trust-Architektur

• Standardmäßig Zero-Trust, jede Anfrage an jedes interne System wird authentifiziert und autorisiert. Es gibt kein implizites Vertrauen basierend auf dem Netzwerkstandort.
• Rollenbasierte Zugriffskontrolle (RBAC) mit dem Prinzip der geringsten Privilegien. Zugriffsüberprüfungen werden vierteljährlich durchgeführt.
• Multi-Faktor-Authentifizierung (MFA) ist für jeden Mitarbeiter, jedes Produktionssystem, jede Cloud-Konsole und jedes Code-Hosting-Konto obligatorisch.
• Single Sign-On (SSO) für interne Anwendungen, mit Hardware-Token-MFA für privilegierte Rollen.
• Just-in-Time-Zugriff für die Produktion: Stehende privilegierte Zugriffe sind die Ausnahme, nicht die Regel.
• Audit-Logging, jede privilegierte Aktion wird in einer manipulationssicheren, nur einmal beschreibbaren Audit-Pipeline protokolliert, die mindestens 12 Monate lang aufbewahrt wird.

6. Datenresidenz und -trennung

• Standardmäßig Europäische Union. Produktionsdaten werden in der Europäischen Union auf Amazon Web Services verarbeitet und gespeichert. Eine spezifische regionale oder länderspezifische Residenz ist für Enterprise-Verträge verfügbar, vorbehaltlich der Verfügbarkeit, für Gerichtsbarkeiten, deren Aufsichtsbehörden dies verlangen.
• Umgebungstrennung. Sandbox, Staging und Produktion sind auf Netzwerk-, Identitäts- und Schlüsselverwaltungsebene isoliert. Kein Mensch oder Dienst in einer Umgebung kann Daten in einer anderen lesen, ohne einen expliziten, auditierten Zugriffspfad.
• Mandantentrennung. Mehrmandantenfähige Daten werden logisch mit mandantenspezifischen Verschlüsselungsschlüsseln getrennt, wo zutreffend. Mandantenübergreifende Abfragen werden auf Anwendungs- und Datenbankebene blockiert.

7. Sicherer Entwicklungslebenszyklus (SDLC)

• Code-Review ist für jede Produktionsänderung erforderlich. Kein einzelner Ingenieur kann unüberprüften Code in die Produktion mergen.
• Statische Anwendungssicherheitsprüfung (SAST), Abhängigkeitsscanning und Software Composition Analysis (SCA) laufen automatisch bei jedem Pull Request.
• Container- und Infrastruktur-Scanning bei jedem Build und nach einem wiederkehrenden Zeitplan für bereitgestellte Images.
• Sicherheitstests vor der Produktion für Änderungen mit hoher Auswirkung (Authentifizierung, Schlüsselverwaltung, biometrische Pipelines, Zahlungsabläufe).
• Interne Penetrationstests kontinuierlich; externe Penetrationstests mindestens einmal jährlich durch unabhängige Spezialisten. Wesentliche Ergebnisse werden nach einem SLA-gebundenen Zeitplan bis zur Behebung verfolgt.
• Bug-Bounty / Responsible-Disclosure-Kanal, melde Sicherheitsprobleme an security@didit.me.

8. Schwachstellenmanagement

• Patching-SLA nach Schweregrad, kritisch (innerhalb von 72 Stunden nach Offenlegung durch den Anbieter), hoch (innerhalb von 7 Tagen), mittel (innerhalb von 30 Tagen), niedrig (innerhalb von 90 Tagen).
• Kontinuierliches Schwachstellenscanning über die gesamte Produktionsinfrastruktur, Container und Abhängigkeiten.
• Bedrohungsmodellierung für neue Produktoberflächen, biometrische Pipelines und umgebungsübergreifende Integrationen.

9. Überwachung, Erkennung und Incident Response

• 24x7 Überwachung jedes Produktionssystems mit Alarmierung bei Verfügbarkeits-, Fehler- und Sicherheitssignalen.
• Security Information and Event Management (SIEM) aggregiert und korreliert Sicherheitsereignisse; anormale Muster werden an Bereitschafts-Sicherheitsingenieure eskaliert.
• Dokumentierter Incident Response Plan mit benannten Rollen, Kommunikationsbaum, Schweregradmatrix und Post-Incident-Review-Prozess. Der Plan wird mindestens jährlich durch Tabletop-Übungen getestet.
• Benachrichtigung bei Verletzungen des Schutzes personenbezogener Daten. Didit benachrichtigt betroffene Kunden unverzüglich und in jedem Fall rechtzeitig, damit Kunden ihre eigene 72-Stunden-Benachrichtigungspflicht gemäß Artikel 33 der Datenschutz-Grundverordnung (DSGVO) erfüllen können. Unternehmenskunden erhalten einen benannten Bereitschaftsingenieur und einen dedizierten Kommunikationskanal.
• Öffentliche Statusseite unter status.didit.me, jeder Produktionsvorfall, jedes Post-Mortem, kein Login erforderlich.

10. Geschäftskontinuität und Notfallwiederherstellung

• Multi-AZ aktive Redundanz in jeder Produktionsregion; automatisches Failover für zustandslose Dienste.
• Backups sind verschlüsselt, geografisch innerhalb der gewählten Residenzgrenze getrennt und werden regelmäßig getestet.
• Recovery Point Objective (RPO) ≤ 1 Stunde und Recovery Time Objective (RTO) ≤ 4 Stunden für die Kern-Verifizierungs-API und die Business Console.
• Disaster Recovery (DR) Tests mindestens jährlich.

11. Personalsicherheit

• Hintergrundüberprüfungen für jeden Mitarbeiter und jeden Auftragnehmer mit Zugang zu Produktionsdaten oder personenbezogenen Daten, sofern dies nach geltendem Recht zulässig ist.
• Vertraulichkeitsvereinbarungen bei Einstellung für jeden Mitarbeiter und Auftragnehmer.
• Obligatorische Sicherheits- und Datenschutzschulungen beim Onboarding und mindestens jährlich für jeden Mitarbeiter aufgefrischt. Gezielte Schulungen (sichere Codierung, Umgang mit biometrischen Daten, Betrugsbekämpfung, Geldwäschebekämpfung) für die Rollen, die sie benötigen.
• Phishing-Simulationen nach einem wiederkehrenden Zeitplan.
• Joiner / Mover / Leaver Prozess widerruft den Zugang innerhalb von 24 Stunden nach Rollenwechsel oder Ausscheiden.

12. Anbieter- und Unterauftragsverarbeiter-Management

• Jeder Unterauftragsverarbeiter wird vor dem Onboarding einer Risikobewertung unterzogen und mindestens jährlich erneut überprüft.
• Jeder Unterauftragsverarbeiter unterzeichnet eine Datenverarbeitungsvereinbarung (DPA), die Datenschutzpflichten auferlegt, die im Wesentlichen denen ähneln, die Didit seinen eigenen Kunden schuldet.
• Die aktuelle Liste der Unterauftragsverarbeiter wird Kunden und potenziellen Kunden per E-Mail nach Unterzeichnung einer Geheimhaltungsvereinbarung (NDA) mitgeteilt. Sende eine E-Mail an security@didit.me, um sie anzufordern. Kunden, die Benachrichtigungen über Änderungen bei Unterauftragsverarbeitern abonniert haben, werden per E-Mail mit ausreichend Vorlauf benachrichtigt, um Einspruch erheben zu können.

13. Rechte der betroffenen Person und Löschung

• Recht auf Zugang und Datenübertragbarkeit, `GET /v3/sessions/:session_id/decision/`.
• Recht auf Löschung, `POST /v3/sessions/:session_id/delete/`. Entfernt die Sitzung und jedes verknüpfte Artefakt über jede Replik hinweg.
• Anwendungsspezifische Aufbewahrung ist in der Business Console zwischen 30 Tagen und 10 Jahren konfigurierbar; die Standardeinstellung ist unbegrenzt, es sei denn, der Kunde konfiguriert einen kürzeren Zeitraum. Die Aufbewahrung biometrischer Daten unterliegt in jedem Fall den geltenden Gesetzen und Vorschriften zum Schutz biometrischer Daten und wird durch diese begrenzt, einschließlich Artikel 9 der EU-Datenschutz-Grundverordnung (DSGVO), des Illinois Biometric Information Privacy Act (BIPA), des Texas Capture or Use of Biometric Identifier Act (CUBI), Washington H.B. 1493 und aller anderen anwendbaren Gesetze zum Schutz biometrischer Daten; wo ein solches Gesetz eine kürzere Aufbewahrungsfrist oder eine frühere Vernichtungspflicht vorschreibt, hat diese kürzere oder strengere Regel Vorrang vor jeder Standard- oder vom Kunden konfigurierten Aufbewahrungsfrist.
• Den vollständigen Prozess der Rechte der betroffenen Person findest du in der Datenschutzrichtlinie und im Datenschutzhinweis zur Verifizierung.

14. Meldung eines Sicherheitsproblems

Wenn du glaubst, eine Sicherheitslücke in einem Didit-Produkt oder -Dienst gefunden zu haben, sende eine E-Mail an security@didit.me mit einer Beschreibung, Schritten zur Reproduktion und den beobachteten Auswirkungen. Didit bestätigt Sicherheitsmeldungen innerhalb von 2 Werktagen und arbeitet in gutem Glauben mit Meldern zusammen, die verantwortungsvolle Offenlegungspraktiken befolgen.

15. Kontakt

• Sicherheit: security@didit.me
• Datenschutzbeauftragter: dpo@didit.me
• Datenschutz: privacy@didit.me
• Rechtliches / Verträge: legal@didit.me
• Anfrage für Trust Pack (unter NDA): security@didit.me