Technische und organisatorische Maßnahmen (TOM)

veridu UG (haftungsbeschränkt), Strübelhorn 3, 22559 Hamburg, HRB 194849, AG Hamburg

1. Zweck und Geltungsbereich

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO, die die veridu UG (haftungsbeschränkt) zum Schutz personenbezogener Daten trifft. Es gilt für sämtliche Systeme der veridu-Lernplattform.

Das Dokument hat zwei Funktionen. Gegenüber Verantwortlichen, mit denen ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO besteht, ist es in der jeweils vereinbarten Fassung Anlage 2 dieses Vertrages und damit Vertragsbestandteil (siehe dort § 7). Unabhängig davon dient es als eigenständiger Nachweis gegenüber Schulen, Schulträgern und deren Datenschutzbeauftragten. Eine inhaltsgleiche Zweitfassung im Vertragstext besteht nicht; dieses Dokument ist die allein maßgebliche Beschreibung der Maßnahmen.

Die Auswahl der Maßnahmen berücksichtigt den Stand der Technik, die Implementierungskosten sowie Art, Umfang, Umstände und Zwecke der Verarbeitung, insbesondere den Umstand, dass die Plattform im schulischen Umfeld mit Bezug zu Minderjährigen eingesetzt wird. Leitprinzip ist, Risiken architektonisch zu vermeiden statt sie nachträglich abzusichern (siehe Abschnitt 4).

2. Systemübersicht

Die gesamte Plattform wird auf dedizierten Servern der Hetzner Online GmbH in Deutschland betrieben (ISO-27001-zertifiziertes Rechenzentrum Falkenstein; Object Storage im ISO-27001-zertifizierten Rechenzentrum Nürnberg). Es kommen keine Hyperscaler (AWS, Azure, Google Cloud) zum Einsatz.

Sämtliche Verarbeitung und Speicherung personenbezogener Daten erfolgt in Deutschland bzw. der EU.

3. Maßnahmen nach Kontrollzielen

3.1 Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

Zutrittskontrolle

• Betrieb ausschließlich in ISO-27001-zertifizierten Rechenzentren (Hetzner, Deutschland: Falkenstein/Nürnberg, siehe Abschnitt 2); Zutrittsschutz, Videoüberwachung und Vereinzelungsanlagen gemäß RZ-Zertifizierung
• Kein physischer Serverzugang durch veridu-Personal erforderlich (Remote-Administration)
• Geschäftsräume: verschlossene Räume, Geräte mit Festplattenverschlüsselung und Bildschirmsperre

Zugangskontrolle

• Zentrales Identity-Management über Keycloak (self-hosted) mit Passwort-Richtlinien
• Für Anmeldungen an der Anwendung wird kein zweiter Faktor eingesetzt. Die Absicherung der Lehrkraftzugänge beruht auf Passwort-Richtlinien, Session-Timeouts und den unter Zugriffs-, Trennungs- und Pseudonymisierungskontrolle beschriebenen Maßnahmen (Beschränkung auf die eigenen Klassen, Mindestgruppengröße 5, Architektur ohne Schüleridentifikatoren). Ein kompromittierter Lehrkraftzugang legt dadurch keine Schüleridentitäten offen
• Serverzugriff ausschließlich über SSH-Public-Key-Authentifizierung; kein Passwort-Login
• Personalisierte Administrationszugänge; Zugriff auf Produktivsysteme auf zwei benannte Personen beschränkt (Stand 08/2026: Geschäftsführung)
• Für sämtliche privilegierten Zugänge von veridu ist Mehr-Faktor-Authentifizierung aktiviert: Identity-Management-Administration, Infrastruktur (Hosting), Zahlungsdienstleister und Quellcodeverwaltung
• Automatische Session-Timeouts (dokumentierte Keycloak-Session-Lifespans, max. 180 Tage „Remember Me“, Standard 2 Tage)

Zugriffskontrolle

• Rollenbasiertes Berechtigungskonzept (Lehrkraft / Administration) mit Prinzip der minimalen Rechtevergabe
• Lehrkräfte sehen ausschließlich die eigenen Klassen ihrer Schule
• Auswertungen von Check-ins erst ab fünf abgegebenen Antworten (technisch erzwungene Mindestgruppengröße, ohne Ausnahme in Produktion)
• Kein Zugriff des Redaktionssystems auf personenbezogene Endnutzerdaten (strikte Trennung von Content und Fachdaten)

Zwischenspeicherung auf Endgeräten

• Die Web-Anwendung ist als installierbare Progressive Web App ausgelegt und hält abgerufene Inhalte im Browser der Lehrkraft vor, damit sie bei unterbrochener Verbindung nutzbar bleibt; betroffen sind die Antworten der Programmschnittstelle einschließlich Klassen-, Einheiten- und Auswertungsdaten
• Ablage im Anwendungsspeicher des Browsers sowie im Offline-Zwischenspeicher; beide werden bei der Abmeldung vollständig geleert
• Die Absicherung der Endgeräte selbst (Bildschirmsperre, persönliche Benutzerkonten, Abmeldung an gemeinsam genutzten Rechnern) obliegt dem Verantwortlichen

Trennungskontrolle

• Logische Mandantentrennung über Schul- und Klassenzuordnung auf Datenbankebene
• Getrennte Datenbanken je Teilsystem (PostgreSQL: Fachdaten; Keycloak: Identitäten; MongoDB: ausschließlich redaktionelle Inhalte ohne Personenbezug)
• Strikt getrennte Umgebungen für Entwicklung, Test/Staging und Produktion mit getrennten Zugangsdaten

Pseudonymisierung und Datenminimierung

• Architektur ohne Schüleridentifikatoren: keine Schüler-Accounts, keine Namen, keine Kontaktdaten; Check-in-Antworten ausschließlich mit Klassenbezug (siehe Abschnitt 4)
• Data-Scrubbing im Fehler-Monitoring: automatisierte Entfernung von Nutzer-IDs, E-Mail-Adressen, URLs mit Parametern und Auth-Headern vor Übertragung; keine IP-Speicherung im Fehler-Monitoring (sendDefaultPii deaktiviert)
• Kein IP-Logging auf Anwendungsebene: das HTTP-Zugriffsprotokoll (Loki) reduziert jeden Request fest auf Methode und Pfad; IP-Adressen, Header und remoteAddress werden nie protokolliert, durchgesetzt durch einen zentralen Log-Serializer, regressionsgetestet
• IP-Anonymisierung auf Reverse-Proxy-Ebene (Nginx, ein einziger Hop vor dem Backend, kein CDN davor): Access-Logs werden nicht im Klartext, sondern maskiert geschrieben (IPv4 letztes Oktett, IPv6 ab dem 4. Hextet); Aufbewahrung auf 30 Tage begrenzt (Logrotate), analog zur Loki/Prometheus-Retention
• Nutzungsanalysen nur für Lehrkräfte, nur nach Einwilligung (Opt-in), mit maskierten Eingabefeldern und pseudonymer Kennung; kein Tracking im Schüler-Antwortbereich

3.2 Integrität (Art. 32 Abs. 1 lit. b DSGVO)

Weitergabekontrolle

• Transportverschlüsselung (TLS) für sämtliche externen und internen Dienstverbindungen
• Verschlüsselte Backups (Restic-Repository-Verschlüsselung) vor Übertragung an den Offsite-Speicher
• Kein Transport unverschlüsselter Datenträger; keine lokalen Datenexporte im Regelbetrieb

Eingabekontrolle

• Zentrale Protokollierung sicherheitsrelevanter Ereignisse (Log-Aggregation in Loki, Aufbewahrung 30 Tage)
• Nachvollziehbare Datenbank-Schemaänderungen ausschließlich über versionierte Migrationen
• Vier-Augen-Prinzip für Codeänderungen (Review-Pflicht im Versionskontrollsystem); vollständige Änderungshistorie

3.3 Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c DSGVO)

• Automatisierte tägliche Backups (Restic, verschlüsselt) auf S3-Speicher bei IONOS (DE), zusätzlich lokale Pre-Deployment-Backups (max. 3 Stände)
• Backup-Rotation: täglich 7 Tage, wöchentlich 4 Wochen, monatlich 6 Monate; physische Löschung nach Fristablauf
• Restore-Tests mindestens halbjährlich auf isolierter Testumgebung (nicht auf dem Produktivsystem), dokumentiert mit Datum, getestetem Snapshot, Ergebnis und Verantwortlichem
• Wiederherstellung gelöschter Daten wird durch ein automatisiertes Lösch-Audit-Verfahren verhindert: erneuter Löschdurchlauf nach jedem Restore anhand eines separaten Audit-Logs
• Kontinuierliches Monitoring (Prometheus-Metriken, Loki-Logs, Health-Checks aller Dienste) mit automatisierter Alarmierung und dokumentierter Eskalation (24-Stunden-Bestätigungsfenster, Primary-/Deputy-Ownership)

3.4 Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art. 32 Abs. 1 lit. d DSGVO)

• Präventiv: Schwachstellen-Scans (Trivy) in der CI-Pipeline für jeden Code- und Image-Stand, blockierend für Findings der Stufen HIGH/CRITICAL; automatisierte Dependency-Updates (Renovate) mit Review-Prozess
• Detektiv: tägliche Schwachstellen-Scans der Produktivsysteme (systemd-Timer), log-basierte Security-Alerts in Grafana/Loki
• Korrektiv: dokumentierter Incident-Response-Prozess mit Reaktionsfristen (CRITICAL: Triage am selben Arbeitstag; HIGH: innerhalb eines Arbeitstags), priorisierte Security-Rollouts
• Ausnahmen (Risikoakzeptanzen) nur mit benannter CVE, technischer Begründung, Ablaufdatum und Verantwortlichem; monatliches Review aller Ausnahmen
• Dokumentiertes Löschkonzept mit definierten Fristen je Datenkategorie; jährliches Review der Sicherheits- und Datenschutzdokumentation sowie bei jeder Architekturänderung
• Nachweisartefakte (Audit-Evidence): CI-Workflow-Läufe, Scan-Reports, Server-Logs, Alert-Historie, Review-Protokolle

3.5 Organisatorische Maßnahmen

• Vertraulichkeitsverpflichtung aller mit personenbezogenen Daten befassten Personen, fortgeltend über das Tätigkeitsende hinaus
• Benannter Ansprechpartner für Datenschutz (Bendix Behn); definierte Zuständigkeiten für Sicherheitskontrollen (Gesamtverantwortung: Geschäftsführung)
• Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen als verbindliches Architekturprinzip (siehe Abschnitt 4)
• Auftragskontrolle: Auftragsverarbeitungsverträge mit sämtlichen Subunternehmern; Subunternehmer ausschließlich mit Verarbeitungsort Deutschland/EU; ein US-Anbieter für Fehler-Monitoring ausschließlich mit EU-Datenhaltung und Kapitel-V-Garantien
• Meldeprozess für Datenschutzverletzungen: Meldung an betroffene Verantwortliche unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung
• Regelmäßige Schulung und Sensibilisierung des Teams
• Datensparsame Konfiguration der Dienste in der Eigensphäre: Fehler-Monitoring ohne Personenbezug (Data-Scrubbing, keine IP-Speicherung); Nutzungsanalyse nur nach Opt-in der Lehrkraft, mit maskierten Elementtexten, maskierten Eingabefeldern und maskierten Sitzungsaufzeichnungen, ohne Übermittlung besonderer Kategorien und ohne Nutzerkennung bei serverseitig erzeugten Ereignissen; keine Analyse im Schüler-Antwortbereich
• Gesonderte Zugriffsbeschränkung für die klassenbezogenen Angaben zu Kontraindikationen (besondere Kategorien nach Art. 9 DSGVO, siehe AVV Anlage 1 Nr. 3): Auslieferung ausschließlich an Lehrkräfte mit der Rolle Eigentümer:in oder Klassen-Administration der betreffenden Klasse, serverseitig erzwungen; Verwendung ausschließlich zum Ausschluss kontraindizierter Übungsinhalte

4. Datenschutz durch Architektur

Die wirksamste Maßnahme der Plattform ist die Vermeidung von Risiken durch Systemdesign:

1. Keine Schüleridentitäten im System. Es existieren keine Schüler-Accounts, keine Namenslisten und keine Kontaktdaten von Schüler:innen oder Eltern. Schüler:innen nehmen an Check-ins ausschließlich über einen anonymen Sitzungscode teil; Antworten werden ohne Identifikator gespeichert und sind nur der Klasse zugeordnet.
2. Aggregation mit Mindestgruppengröße. Auswertungen werden erst ab fünf abgegebenen Antworten angezeigt. Rückschlüsse auf Einzelpersonen werden dadurch technisch erschwert.
3. Deterministische Auswertung ohne KI. Kompetenzübersichten und Übungsempfehlungen entstehen durch regelbasierte, von Menschen definierte Logik. Personenbezogene Daten werden weder durch KI-Systeme verarbeitet noch zu deren Training verwendet.
4. Digitale Souveränität. Self-hosted-Betrieb auf deutscher Infrastruktur ohne Hyperscaler; sämtliche Subunternehmer mit Verarbeitungsort Deutschland/EU.
5. Opt-in statt Opt-out. Nutzungsanalysen betreffen ausschließlich Lehrkräfte und erfolgen nur nach ausdrücklicher, widerruflicher Einwilligung.