Technische und organisatorische Maßnahmen (TOMs)
Maßnahmen gemäß Art. 32 DSGVO zur Sicherheit der Verarbeitung personenbezogener Daten auf der NISD2.eu-Plattform.
Stand: 26.09.2026. Am Code geprüft und korrigiert; die Fassung ist Anhang III des Auftragsverarbeitungsvertrags.
Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen, die die Kardashev Catalyst UG (haftungsbeschränkt) als Betreiberin der Plattform NISD2.eu tatsächlich umsetzt. Es ist eine ehrliche Bestandsaufnahme, keine Wunschliste - wir nennen nur, was bereits implementiert ist.
Die Maßnahmen orientieren sich an IT-Grundschutz (BSI) und werden mit dem Wachstum der Plattform erweitert.
Server, Datenbank und Dateispeicher liegen in der EU. Ein Dienst sitzt in den USA und erhält nur die Daten für seine Funktion:
- Anwendungsserver und PostgreSQL-Datenbank: Hetzner Online GmbH, Rechenzentrum Falkenstein/Nürnberg, Deutschland
- Speicherung hochgeladener Nachweisdokumente: AWS S3, EU-Region
- In den USA: Resend, über das wir E-Mails versenden. Grundlage der Übermittlung sind die EU-Standardvertragsklauseln (Art. 46 DSGVO).
- Transportverschlüsselung: TLS für sämtliche Verbindungen zur Plattform (HTTPS)
- Verschlüsselung im Ruhezustand: AWS S3 Server-Side Encryption (AES256, bei jedem Upload ausdrücklich gesetzt, auch für archivierte Rechnungen). Die PostgreSQL-Datenbank verschlüsselt die Anwendung nicht zusätzlich.
- Zugangsdaten und API-Schlüssel werden über Server-Umgebungsvariablen verwaltet, nicht im Quellcode oder in Datenbanken gespeichert
Maßnahmen zur Sicherstellung der Vertraulichkeit:
- Zutrittskontrolle: Rechenzentren der eingesetzten Hoster (Hetzner, AWS) verfügen über ISO 27001-Zertifizierungen
- Personelle Maßnahmen: Zugriff auf Produktivsysteme und personenbezogene Daten ist auf einen kleinen, namentlich benannten Personenkreis beschränkt, der zur Vertraulichkeit verpflichtet ist. Zugänge folgen dem Prinzip der minimalen Rechte und werden bei Beendigung der Tätigkeit entzogen.
- Authentifizierung: Anmeldung per E-Mail und Passwort oder über Google OAuth 2.0. Passwörter speichern wir ausschließlich als bcrypt-Hash mit Kostenfaktor 12, nie im Klartext. Bei der Registrierung per Passwort wird die E-Mail-Adresse einmalig über einen Einmalcode bestätigt. Anmeldeversuche sind je E-Mail-Adresse und Anwendungsinstanz auf 10 in 15 Minuten begrenzt; gezählt wird jeder Versuch. Sitzungen enden nach acht Stunden. Eine zweite Stufe bietet die Plattform für den Passwortweg nicht an. Wer sich über Google anmeldet, nutzt die MFA des eigenen Google-Kontos.
- Rollenbasierte Berechtigungen: Admin, Reviewer, Legal Reviewer, Member; durchgesetzt in der Anwendungsschicht über tRPC-Middleware
- Mandantentrennung in der Anwendung: jede datentragende Abfrage filtert auf die Company-ID aus der Sitzung des angemeldeten Nutzers. Eine zusätzliche Trennung in der Datenbank (Row Level Security) gibt es nicht.
- Passwörter werden nie im Klartext gespeichert. Der Abgleich läuft immer gegen einen bcrypt-Hash, auch wenn zu der angefragten E-Mail-Adresse kein Konto existiert, damit sich aus der Antwortzeit nicht ableiten lässt, wer registriert ist.
- Eingabekontrolle: Jede Änderung, die ein angemeldeter Nutzer über die Programmierschnittstelle der Plattform auslöst, wird mit Benutzer-ID, Aktion, Entitätstyp, Zeitstempel, IP-Adresse, User-Agent und den Eingabewerten protokolliert (sensible Felder entfernt). Den vorherigen Wert speichern nur ausgewählte Vorgänge.
- Prüfsumme im Audit-Trail: Jede Audit-Zeile erhält beim Schreiben eine SHA-256-Prüfsumme über ihren Inhalt. Ein Werkzeug, das diese Prüfsummen später nachrechnet, gibt es noch nicht.
- Weitergabekontrolle: Datenübertragung ausschließlich über TLS; alle authentifizierten Endpunkte erfordern eine gültige Session
- Nachweisdokumente: Speicherort und Metadaten werden bei Upload festgeschrieben; ein Datei-Hash kann optional vom Client mitgesendet und gespeichert werden
- Sign-Off-Mechanismus: zum Zeitpunkt einer Freigabe wird der Zustand der Anforderung in eine Sign-Off-Historie geschrieben, deren Einträge eine SHA-256-Kette bilden (jede Zeile schließt die Prüfsumme der Vorgängerzeile ein) - Manipulationen am Verlauf werden Ende-zu-Ende erkannt
- Datenbanksicherungen richtet der Betreiber in der Hosting-Umgebung ein. Sie sind nicht Teil des Quellcodes. Die aktuelle Konfiguration nennen wir auf Anfrage.
- Speicherung von Nachweisdokumenten in AWS S3 mit der von AWS bereitgestellten Objekt-Haltbarkeit
- Begrenzung der Anfragen (in der Datenbank gezählt und damit über Neustarts und alle Anwendungsinstanzen hinweg wirksam; IP-Adressen und E-Mail-Adressen werden dabei nur als Hash gespeichert) auf Login-Versuchen, öffentlichen Endpunkten (Anwendbarkeitsprüfung, Lieferantenportal) sowie aufwendigen authentifizierten Endpunkten (PDF-Exporte, Erstellung von Zertifikaten)
- Hochgeladene Dateien sind auf 50 MB pro Datei begrenzt
- Verfügbarkeitsanzeige: nisd2.eu/status prüft die Erreichbarkeit der Datenbank höchstens alle 30 Sekunden und zeigt das Ergebnis öffentlich an. Eine durchgehende Überwachung mit automatischer Alarmierung betreiben wir nicht.
- Diese TOMs werden anlassbezogen sowie mindestens jährlich überprüft und aktualisiert
- Aktualisierung von Abhängigkeiten: Dependabot schlägt wöchentlich neue Versionen der npm-Pakete und GitHub Actions als Pull-Requests vor
- Meldepflichten: Datenschutzverletzungen werden gemäß Art. 33 DSGVO innerhalb von 72 Stunden an die zuständige Aufsichtsbehörde gemeldet
- Entwicklungspraxis: Codeänderungen laufen über Pull-Requests; TypeScript strict-mode wird durchgesetzt; automatisierte Tests bestehen für sicherheitskritische Logik (z. B. Anwendbarkeits-Klassifizierung)
Alle Unterauftragsverarbeiter sind durch Verträge gemäß Art. 28 DSGVO verpflichtet. Die vollständige Liste finden Sie im AVV-Dokument.
Anfragen zu diesen TOMs oder zur Datenverarbeitung richten Sie bitte an: