Recht und Datenschutz

Technische und organisatorische Maßnahmen (TOM)

Technische und organisatorische Grundlagen für Zugriff, Betrieb, Entwicklung, Lifecycle und Incident Management.

1.0 · Stand 28.08.2026

1. Organisation und Zugriff

Produktivzugriff nur für berechtigte administrative Personen nach Need-to-know.
Mandanten- und Tenant-Kontext sowie Berechtigungen werden serverseitig geprüft.
Rollenbasierte Zugriffssteuerung; Admin- und Owner-Rechte sind von normalen Nutzerrechten getrennt.
Secrets und Runtime-Geheimnisse liegen nicht im Quellcode-Repository.
Produktionscontainer laufen als nicht privilegierter Nutzer.
Staging und Production sind logisch getrennt.
Für Web Push bestehen getrennte VAPID-Schlüsselpaare für Staging und Production.

Account- und Session-basierte Authentifizierung.
Tenant-gebundene Autorisierung und serverseitige Permission-Prüfungen.
Kritische Billing- und Adminaktionen sind nicht nur durch UI-Verbergen geschützt.
Self-Service-Billing wird gegen den autoritativen Stripe-Zustand synchronisiert.

TLS für Datenübertragung.
Dokumentenspeicher in AWS S3 eu-central-1.
Erwartete serverseitige S3-Verschlüsselung AES-256.
Produktionsgeheimnisse mit restriktiven Dateiberechtigungen außerhalb des Repositories.
Vollständige Kartendaten werden über Stripe verarbeitet und sollen nicht in Kerniva gespeichert werden.

Betriebs- und Security-Logs für Fehleranalyse und Angriffserkennung.
Standardaufbewahrung 90 Tage.
Logs sollen keine VAPID-Private-Keys, Push-Endpoints oder Push-Schlüssel, Zahlungsgeheimnisse, Sessiontokens oder andere Secrets im Klartext enthalten.
Web- und Worker-Healthchecks sowie Release-Preflights.
Stripe-Vertrag, Stripe Tax und Web Push werden im Production-Preflight fail-closed geprüft.

Backup-Retention 30 Tage.
Datenbank-Backups in wiederherstellbarem Format; Restore-Verifikation ist Teil des Betriebskonzepts.
Restore ausschließlich für Recovery; fällige Löschungen anschließend erneut anwenden.

Web-Push-Payloads sind generisch und enthalten keine Diagnose-, Dokument-, Billing- oder sonstigen sensitiven Detailinhalte.
Push-Berechtigung nur nach ausdrücklicher Nutzeraktion.
Keine Marketing- oder Analytics-Tags in der Kerniva-App.
Krankheitsinformationen auf erforderliche Abwesenheitsinformationen begrenzen; keine Diagnosepflicht.
Rollen und Berechtigungen begrenzen die Sichtbarkeit von Mitarbeiter- und Abwesenheitsdaten.

Exportartefakte: 24 Stunden.
Trial- oder Vertragsende allein löst keine automatische Planung einer Organisationslöschung aus.
Organisationslöschung nur nach beendeter Subscription, abgeschlossenen offenen Billingvorgängen und ohne laufenden Payment- oder Checkout-Vorgang.
Aktiver Owner fordert die Löschung an und bestätigt sie über den vorgesehenen E-Mail-Link.
30-tägige Karenz beginnt erst nach der Bestätigung; innerhalb der Karenz ist eine sichere Rücknahme vorgesehen.
Löschworker verarbeitet ausschließlich bestätigte und bereits zur Löschung vorgemerkte Anträge nach Ablauf der Karenz.
Backups: 30-Tage-Rotation.
Gesetzlich aufzubewahrende Abrechnungs- und Steuerunterlagen werden getrennt vom operativen Mandantenbestand behandelt.

Versionskontrolle und Pull-Request-Prozess.
Automatisierte Format-, Lint-, Typecheck-, Unit-, Integrations-, Build- und Security- beziehungsweise Audit-Prüfungen.
Immutable Production-Releases mit Commit- und Build-Identität.
Production-Preflight vor Release.
Datenbankmigrationen getrennt vom Webstart.
Rollback auf vorherige immutable Images vorgesehen.

Sicherheitsvorfälle technisch eingrenzen, protokollieren und bewerten.
Bei möglicher Datenschutzverletzung unverzügliche interne Eskalation.
Auftragskunden bei Verletzungen von Kundendaten unverzüglich mit verfügbaren Informationen für Art. 33 und 34 DSGVO unterstützen.