Technische und organisatorische Maßnahmen (TOM) nach Art. 32 DSGVO

Stand: 30.10.2026 · Version 1.10

Anlage 2 zum Auftragsverarbeitungsvertrag für leitstelle.live (https://leitstelle.live/avv)

Auftragsverarbeiter: Wulffapps, Inhaber Jan Wulff, Alte Str. 5e, 50769 Köln

0. Systemüberblick

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

1.1 Zutrittskontrolle

Maßnahmen, die Unbefugten den Zutritt zu Datenverarbeitungsanlagen verwehren.

• Die Server stehen ausschließlich in Rechenzentren in der Europäischen Union: das Produktivsystem einschließlich der Telefonie-Brücke bei der one.com Group AB in den Niederlanden, Mailserver sowie Entwicklung und Test bei der IONOS SE in Deutschland. Wulffapps betreibt keine eigenen Serverräume; Zutrittskontrolle, Videoüberwachung, Wachdienst, Vereinzelungsanlagen und Besucherregelungen verantwortet der jeweilige Rechenzentrumsbetreiber. IONOS weist hierfür eine Zertifizierung nach ISO/IEC 27001 aus.
• Kundendaten werden in den Geschäftsräumen von Wulffapps nicht dauerhaft gespeichert. Entschlüsselte Sicherungskopien dürfen nach interner Vorgabe nur auf verschlüsselten Datenträgern abgelegt und müssen nach Gebrauch gelöscht werden.
• Arbeitsplatzrechner: Festplattenverschlüsselung (BitLocker), Bildschirmsperre und Zutrittssicherung der Büroräume.

1.2 Zugangskontrolle

Maßnahmen, die verhindern, dass Datenverarbeitungssysteme von Unbefugten genutzt werden können.

Anwendung

• Persönliche Benutzerkonten; keine Sammelkonten für Nutzer.
• Passwörter werden ausschließlich als Hash gespeichert (bcrypt, Kostenfaktor 12).
• Passwortrichtlinie: Mindestlänge 12 Zeichen (plattformweit einstellbar, nicht unter 8), Prüfung gegen bekannte kompromittierte Passwörter (k-Anonymitätsverfahren von „Have I Been Pwned“), optionales Ablaufdatum. Mandanten können die Richtlinie nur verschärfen, nicht lockern.
• Mehr-Faktor-Authentifizierung: Authenticator-App (TOTP), Passkeys (WebAuthn/FIDO2), Wiederherstellungscodes, Einmalcode per E-Mail; SMS-Code plattformweit abschaltbar (derzeit aus).
• Pflicht zur Mehr-Faktor-Authentifizierung: für Betreiberkonten (Konsole) zwingend ohne Übergangsfrist; für Kunden durch den Mandanten einstellbar, für die gesamte Organisation oder je Rolle, mit Übergangsfrist (Standard 7 Tage). Bei Mitgliedschaft in mehreren Organisationen gilt die strengste Vorgabe.
• Schutz gegen Ausprobieren: Begrenzung der Anmeldeversuche auf 5 je Minute je Kennung und IP-Adresse, ebenso für den zweiten Faktor; Kontosperre nach 10 Fehlversuchen innerhalb von 15 Minuten (plattformweit einstellbar), Entsperrung durch Administratoren protokolliert.
• Zurücksetzen des Passworts über einen Link mit 60 Minuten Gültigkeit, begrenzt auf 6 Anfragen je Minute.
• Sitzungen: Sitzungscookies mit den Attributen Secure, HttpOnly und SameSite=Lax; Sitzungsablauf nach 120 Minuten Inaktivität; Schutz gegen Cross-Site-Request-Forgery.
• Zugangstoken mobiler Geräte mit begrenzter Laufzeit: Einsatz-App 12 Stunden, mit „angemeldet bleiben“ 30 Tage; Leitstelle Mobil (Tablet-App) 24 Stunden; Alarmmonitor 90 Tage mit gleitender Verlängerung.
• Geräte- und Sitzungsverwaltung: Nutzer und Administratoren des Kunden können einzelne Geräte und Sitzungen widerrufen oder alle Zugänge eines Kontos beenden; dabei werden Zugangstoken, Push-Token und Sitzungen entfernt.
• Schnittstellenschlüssel werden nur einmal im Klartext angezeigt und als SHA-256-Hash gespeichert; Begrenzung auf 60 Aufrufe je Minute je Schlüssel; nach 20 ungültigen Schlüsseln je Minute wird die IP-Adresse vorübergehend abgewiesen. Schlüssel sind jederzeit widerrufbar.
• Registrierung neuer Organisationen ist durch ein Captcha (Cloudflare Turnstile) geschützt, ebenso die Formulare für Support-Anfragen ohne Anmeldung (Hilfe, Website); diese nehmen keine Anhänge an.

Server und Administration

• Administrativer Zugang zu den Servern nur über SSH mit Schlüsselauthentifizierung durch den Inhaber.
• Schutz gegen Anmeldeangriffe auf SSH und SIP durch fail2ban (Sperre über nftables).
• Datenbank und Redis sind nur lokal angebunden. Redis lauscht nur lokal.
• Firewall: Der Zugang aus dem Internet ist auf die benötigten Ports (80/443 TCP, SIP/TURN/RTP-Bereiche, 25 TCP für den Empfang von E-Mails) beschränkt; die Einlieferung ausgehender E-Mails an den Mailserver (587 TCP) ist nur von den eigenen Servern möglich; das Regelwerk ist dokumentiert.
• Zugangsdaten für Server und Backup-Schlüssel werden in einem Passwort-Tresor verwahrt.

1.3 Zugriffskontrolle

Maßnahmen, die gewährleisten, dass Berechtigte nur auf die ihrer Berechtigung unterliegenden Daten zugreifen können.

• Rollen- und Rechtekonzept je Mandant (rollenbasiert, je Organisation getrennt). Standardrollen „Administrator“ und „Mitglied“; der Kunde kann eigene Rollen mit feingranularen Rechten anlegen, z. B. getrennte Rechte zum Lesen und Schreiben von Patientendaten, Einsatzdokumentation, Telefonie, Gruppenalarm, Schnittstellen und Audit-Log.
• Prüfung von Rechten serverseitig bei jeder Anfrage; die Oberflächen blenden nicht berechtigte Funktionen zusätzlich aus.
• Betreiberzugriff: Plattform-Administratoren (Super-Admins) sind ein eng begrenzter Personenkreis mit verpflichtender Mehr-Faktor-Authentifizierung. Ein Wechsel eines Betreiberkontos in einen Mandanten wird im Audit-Log des Mandanten protokolliert; die einzelnen Zugriffe danach werden nicht gesondert protokolliert, und der Kunde erhält dabei keinen Hinweis in den Anwendungen. Zugriffe auf Kundendaten erfolgen nur für Betrieb, Fehlerbehebung und Support (§ 5 Abs. 3 AVV).
• Support-Zugang: Zusätzlich kann der Kunde zu einer Support-Anfrage eine Einsicht freigeben (Inhaber oder Nutzer mit dem Recht „Support-Zugang erteilen“; ein Betreiberkonto kann sich keine Freigabe selbst erteilen). Die Freigabe gilt 24, 48 oder 72 Stunden, höchstens eine je Anfrage, und endet automatisch mit Ablauf, mit dem Schließen der Anfrage oder mit dem Widerruf durch den Kunden; laufende Einsichten werden dann sofort beendet. Die Einsicht läuft als eigene, an die Freigabe gebundene Sitzung des Betreiberkontos, wird über einen einmal verwendbaren Link gestartet und endet nach 60 Minuten ohne Aktivität. Sie erlaubt nur lesende Zugriffe auf Portal und Leitstelle; schreibende Anfragen werden serverseitig abgewiesen. Gesperrt sind außerdem Patientendaten, Downloads von Dokumenten, Exporte und Drucke, Rechnungsdateien, Abrechnung, Abo und Guthaben, Zugangsdaten für Telefonie, mandantenübergreifende Funktionen sowie Dienste, die Daten an Dritte übermitteln (Geokodierung, Routen, Warnungen). Während der Einsicht erscheint das Betreiberkonto nicht als anwesend in der Leitstelle, belegt keinen Arbeitsplatz und verändert keinen Lesestatus. Portal und Leitstelle zeigen allen Nutzern des Kunden einen Hinweis, solange eine Einsicht läuft.
• Eingang: Ein Postfach sehen nur Nutzer, denen der Kunde es zugeordnet hat (alle Disponenten oder einzeln ausgewählte Nutzer), getrennt nach Lesen sowie Lesen und Senden; verwalten können es nur der Inhaber und Nutzer mit dem Recht zur Verwaltung der Postfächer. Voraussetzung ist die Mitgliedschaft in der Organisation; Betreiberkonten erhalten über den Wechsel in einen Mandanten keinen Zugriff auf dessen Postfächer, der Support-Zugang umfasst den Eingang nicht. Das Fernmeldegeheimnis ist zu wahren (§ 5 Abs. 4 AVV).
• Downloads von Datensicherungen nur durch Plattform-Administratoren; jeder Download wird protokolliert.
• Exporte für den Kunden enthalten keine Passwort-Hashes, Token, Postfach-Zugangsdaten oder API-Schlüssel; der Download-Link ist 24 Stunden gültig, danach wird die Datei gelöscht.
• Vertrauliche Konfigurationswerte in der Datenbank werden verschlüsselt gespeichert (u. a. SIP-Passwörter, Webhook-Geheimnisse, Zugangsdaten von E-Mail-Postfächern einschließlich der eingebundenen eigenen Postfächer im Eingang, Geheimnis der Authenticator-App, Telefonnummer für SMS-Codes).
• Inhaltsdaten (einschließlich Patientendaten) und hochgeladene Dokumente werden nicht zusätzlich feldweise verschlüsselt; ihr Schutz beruht auf Zugangs-, Zugriffs- und Trennungskontrolle. Eine Verschlüsselung der Datenträger bzw. der Datenbank auf Speicherebene ist nicht eingerichtet (keine Verschlüsselung der Datenbank, keine Datenträgerverschlüsselung auf Betriebssystemebene).

1.4 Trennungskontrolle

Maßnahmen, die gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden.

• Logische Mandantentrennung: Jeder Datensatz ist einem Mandanten zugeordnet. Der aktuelle Mandant wird je Anfrage serverseitig gesetzt, nachdem Mitgliedschaft und Aktivstatus geprüft wurden; Objekte werden über die URL nur innerhalb des aktuellen Mandanten aufgelöst; Rollen und Rechte gelten je Mandant.
• Automatisierte Tests prüfen die Trennung an ausgewählten Stellen (Zugriff auf Personen, Rollen, Gruppen und Benachrichtigungen anderer Mandanten).
• Echtzeitkanäle (WebSocket) werden je Mandant und Einsatz autorisiert.
• Trennung der Umgebungen Entwicklung, Test und Produktion: eigene Datenbanken mit eigenen Datenbankbenutzern, eigene Konfiguration, eigene PHP-Prozesspools und eigene Backup-Schlüssel. Testdaten sind grundsätzlich synthetisch (Demo- und Simulationsmandanten).
• Trennung von Verantwortlichkeiten: Vertrags- und Abrechnungsdaten von Wulffapps (eigene Verantwortung) und Inhaltsdaten der Kunden (Auftragsverarbeitung) liegen in getrennten Tabellen; Rechnungen bleiben bei Löschung eines Mandanten ohne Inhaltsdaten erhalten.

1.5 Pseudonymisierung und Datenminimierung

• Das Schnittstellenprotokoll speichert Anfrageinhalte nur maskiert (Namen, Telefonnummern, E-Mail-Adressen, Patientenangaben, Geburtsdaten, Freitexte, Adressen und Koordinaten, Geheimnisse werden durch *** ersetzt) und auf 1.000 Zeichen gekürzt; Aufbewahrung 30 Tage.
• Ausgehende Webhooks enthalten nie Meldungstexte, Melder- oder Kontaktdaten; Namen und Koordinaten werden nur nach ausdrücklicher Freischaltung je Schnittstelle übertragen.
• Fehlgeschlagene Anmeldungen werden mit maskierter Kennung protokolliert, ohne Passwort.
• Protokolle und Audit-Log schwärzen Passwörter, Token, Wiederherstellungscodes und Geheimnisse.
• Im Webserver-Zugriffsprotokoll werden Schlüssel in Abfrageparametern der externen Schnittstelle maskiert. IP-Adressen werden im Zugriffsprotokoll ungekürzt gespeichert und nach 8 Wochen gelöscht.
• Gruppenalarm: Freitexte in Rückmeldungen werden nach Ablauf der Frist geleert, der Standortverlauf nach 24 Stunden gelöscht.
• Eingang: Empfangsbestätigungen speichern nur den Zeitpunkt und die gekürzte IP-Adresse (IPv4 ohne das letzte Byte, IPv6 auf /48 gekürzt); der Link bestätigt erst nach einem Klick auf der Bestätigungsseite, nicht schon beim Aufruf, und enthält kein Zählpixel. HTML-Inhalte eingehender E-Mails werden serverseitig bereinigt (keine Skripte, Formulare oder eingebetteten Seiten), Zählpixel entfernt und externe Bilder erst geladen, wenn der Nutzer es wählt.
• Registrierung externer Kräfte: das Einsatztagebuch enthält nur die Personenzahl, keine Namen.
• Standortübermittlung der Einsatz-App nur nach Freigabe durch die Einsatzkraft; Widerruf der Freigabe löscht den Positionsverlauf der Person an der Einheit.
• Eine Pseudonymisierung der Inhaltsdaten findet darüber hinaus nicht statt, da die Zwecke (Einsatzführung, Patientenversorgung) den Personenbezug erfordern.

1.6 Schutz vor Schadsoftware in hochgeladenen Dateien

• Dateien, die Nutzer hochladen, und Anhänge eingehender E-Mails werden vor der Freigabe mit ClamAV auf Schadsoftware geprüft. Das betrifft Einsatzdokumente und Fotos (Portal, Leitstelle, Einsatz-App), Anhänge von Support-Anfragen und Beta-Feedback einschließlich Anhängen aus E-Mails sowie Nachweise der Gemeinnützigkeit.
• Der Scanner läuft auf dem Produktivserver; die Anwendung übergibt die Datei über eine lokale Schnittstelle. Dateien werden dafür nicht an Dritte übermittelt. Die Virensignaturen werden automatisch aktualisiert.
• Bis zum Ergebnis ist eine Datei nicht abrufbar und wird nicht weitergegeben (auch nicht als E-Mail-Anhang, in Exporten oder Kopien). Wird Schadsoftware gefunden oder kann eine Datei nicht geprüft werden (zum Beispiel weil sie zu groß ist), wird sie gelöscht; die Anwendung zeigt einen Hinweis, die Plattform-Administratoren werden benachrichtigt und der Vorgang wird protokolliert.
• Eingang: Anhänge mit Schadsoftware werden nicht abgelegt; die E-Mail selbst wird zugestellt und zeigt den Fund. Anhänge, die beim Empfang nicht geprüft werden konnten, prüft die Anwendung vor der Freigabe erneut. E-Mails mit Hinweisen auf Fälschung oder Gefahr (fehlgeschlagene Absenderprüfung nach SPF, DKIM oder DMARC, Absenderdomain ähnlich einer bekannten, ausführbare Anhänge oder Anhänge mit Makros) werden gekennzeichnet; Anhänge, Links und auslösende Aktionen bleiben gesperrt, bis ein Nutzer sie bewusst freigibt, was protokolliert wird.
• Eingang: Der Mailserver nimmt E-Mails von Servern, die auf einer gängigen Sperrliste (Spamhaus) stehen, sowie E-Mails mit gefälschtem Absender aus den Domänen der Plattform nicht an; der einliefernde Server erhält eine Fehlermeldung. Er leitet keine E-Mails für fremde Domänen weiter (kein offenes Relay). Texterkennung von Faxen und das Auslesen von PDF-Anhängen für den Alarm-Mail-Parser laufen auf den eigenen Servern; dafür werden keine Daten an Dritte übermittelt.
• Ist der Scanner nicht erreichbar, bleiben neue Dateien gesperrt; die Prüfung wird automatisch wiederholt und die Plattform-Administratoren werden benachrichtigt.
• Nicht gesondert geprüft werden Dateien, die der Server selbst erzeugt, Bilder, die beim Hochladen neu kodiert werden (Profilbilder, Logos, Einheiten-Symbole), Kartenhintergründe, die sofort als Kartenebene geladen werden, sowie Karten-Importe und eingespielte Datensicherungen, die sofort verarbeitet und nicht als Datei abgelegt werden.

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

2.1 Weitergabekontrolle

Maßnahmen, die gewährleisten, dass Daten bei der Übertragung oder Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können.

• Transportverschlüsselung aller Web- und API-Verbindungen mit TLS 1.2 oder TLS 1.3; ältere Protokolle (TLS 1.0, 1.1) sind abgeschaltet (geprüft am 21.10.2026). Zertifikate von Let's Encrypt.
• HTTP Strict Transport Security (HSTS, 180 Tage, einschließlich Subdomains) für die API und die Web-Anwendungen.
• Sicherheits-Header: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy; Content Security Policy derzeit im Beobachtungsmodus (Report-Only).
• Echtzeitverbindungen über verschlüsselte WebSockets (wss).
• Telefonie: Verbindung zwischen Browser bzw. App und Telefonie-Brücke über WSS, Sprachdaten DTLS-SRTP-verschlüsselt. Die Verbindung von der Brücke zum vom Kunden gewählten SIP-Anbieter erfolgt derzeit unverschlüsselt per SIP über UDP.
• Datensicherungen werden vor dem Speichern und vor der Übertragung an den externen Speicherort vollständig verschlüsselt (AES-256-GCM in Blöcken von 1 MiB mit eigener Authentifizierung je Block, Schutz gegen Vertauschen und Abschneiden). Ohne Schlüssel startet in der Produktion keine Sicherung. Der Schlüssel liegt getrennt vom Speicherort im Passwort-Tresor.
• Jede Kopie am externen Speicherort wird nach dem Schreiben zurückgelesen und gegen eine SHA-256-Prüfsumme verglichen.
• Ausgehende Webhooks sind mit HMAC-SHA256 signiert; Zieladressen müssen HTTPS verwenden und werden gegen interne Netze geprüft (Schutz gegen Server-Side Request Forgery), Weiterleitungen werden nicht verfolgt.
• Die Übermittlung an Unterauftragsverarbeiter (Push, SMS, Sprachanrufe) erfolgt ausschließlich über verschlüsselte Programmierschnittstellen (HTTPS).
• E-Mails übergibt die Plattform verschlüsselt an den eigenen Mailserver; für die Postfächer der Organisationen werden ausgehende E-Mails mit DKIM signiert, und die Domäne veröffentlicht SPF- und DMARC-Einträge. Der Mailserver nimmt eingehende E-Mails auch verschlüsselt (STARTTLS) entgegen. Verbindungen zu eingebundenen eigenen Postfächern (IMAP, SMTP) laufen verschlüsselt mit Prüfung des Zertifikats. Dieser überträgt sie per SMTP mit TLS an die empfangenden Mailserver, soweit diese TLS unterstützen (opportunistische Verschlüsselung); andernfalls erfolgt die Zustellung unverschlüsselt. Push-Mitteilungen können auf Wunsch der Organisation ohne Einsatzinhalte versendet werden („Push nur mit Hinweis, Inhalt nach Abruf in der App“, § 7 Abs. 3 AVV).
• Auf Android-Geräten werden Zugangstoken im App-Speicher abgelegt.
• Leitstelle Mobil ist von der Android-Datensicherung ausgenommen; beim Abmelden löscht die App Zugangstoken, App-Sperre und alle zwischengespeicherten Einsatzdaten.
• Notbetrieb: Der lokal vorgehaltene Einsatzstand ist auf das Erforderliche beschränkt (keine Personal- und Kontaktdaten, Patienten nur mit Kennung, Sichtung, Zuordnung und Verbleib), an Mandant, Nutzer und Einsatz gebunden und wird beim Abmelden, nach Ablauf der Anmeldung, beim Einsatzwechsel und spätestens 24 Stunden nach der letzten Aktualisierung gelöscht. Zusätzlich hält die Anwendung die E-Mails und Faxe des laufenden Einsatzes der letzten 24 Stunden vor (mit Absender, Empfängern und Text, damit sie im Notbetrieb lesbar sind; im Browser Anhänge bis 1 MB je Datei, zusammen höchstens 20 MB); sie sind ebenso gebunden und werden zusätzlich beim Ausschalten des Notbetriebs gelöscht. Der Service Worker der Leitstelle hält nur Anwendungsdateien vor, keine Daten aus der Schnittstelle.

2.2 Eingabekontrolle

Maßnahmen, die gewährleisten, dass nachträglich überprüft werden kann, ob und von wem Daten eingegeben, verändert oder entfernt worden sind.

• Audit-Log: Anlage, Änderung und Löschung bei 33 fachlichen Datenmodellen werden mit Akteur, Zeitpunkt, Quelle, IP-Adresse, User-Agent sowie alten und neuen Werten protokolliert.
• Sicherheitsereignisse werden gesondert protokolliert, u. a. erfolgreiche und fehlgeschlagene Anmeldungen, Abmeldung, Kontosperren, Einrichtung und Entfernung von Mehr-Faktor-Verfahren und Passkeys, Passwortänderungen, Änderungen von Rollen und Rechten, Änderungen der Anmelderichtlinie, Mandantenwechsel von Betreiberkonten, Erstellen, Prüfen und Herunterladen von Datensicherungen, Funde und nicht prüfbare Dateien der Prüfung auf Schadsoftware.
• Eingang: Das Freigeben gesperrter verdächtiger E-Mails („Trotzdem verwenden“), Auslösungen durch Regeln (zum Beispiel ein aus einer E-Mail angelegter Einsatz) und die Freigabe vor dem Versand werden mit Nutzer und Zeitpunkt protokolliert; jede Ausführung einer Regel steht 90 Tage im Protokoll der Regeln.
• Support-Zugang: Erteilung, Widerruf und Ablauf der Freigabe, Beginn und Ende jeder Einsicht, die aufgerufenen Ansichten (je Ansicht und Minute zusammengefasst) sowie abgewiesene Zugriffe werden als Sicherheitsereignisse im Audit-Log des Kunden protokolliert, mit dem Betreiberkonto als Akteur und der zugehörigen Anfrage. Der Kunde sieht diese Einträge im Portal unter „Protokoll“; der Akteur erscheint dort als „Support leitstelle.live“.
• Das Einsatztagebuch dokumentiert fachliche Vorgänge mit Zeitpunkt und Urheber, Telefonate werden automatisch eingetragen.
• Einsicht: Administratoren des Kunden mit dem Recht zur Einsicht in das Audit-Log sehen das Audit-Log ihres Mandanten; Plattform-Administratoren mandantenübergreifend.
• Aufbewahrung: Änderungsprotokoll 180 Tage (mindestens 90), Sicherheitsereignisse einschließlich Support-Zugang 365 Tage (Mindestwert), fehlgeschlagene Anmeldungen 90 Tage.
• Rechnungen werden nach Ausstellung durch einen Hash gegen Veränderung gesichert.

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b DSGVO)

• Datensicherung:
  • Datenbank stündlich, Vollsicherung (Datenbank, Dateien, verschlüsselte Konfiguration) täglich um 02:15 Uhr.
  • Aufbewahrung lokal: stündliche Sicherungen 48 Stunden; Vollsicherungen 7 Tage, 4 Wochen, 3 Monate.
  • Aufbewahrung extern: Vollsicherungen 14 Tage, 8 Wochen, 12 Monate.
  • Der lokale Sicherungsbereich liegt auf demselben Server und demselben Datenträger wie die Produktivdaten; er dient der schnellen Wiederherstellung nach Fehlbedienung. Der externe Speicherort ist ein Objektspeicher der Amazon Web Services EMEA SARL in der Region Stockholm (Schweden), außerhalb des Rechenzentrums; die Sicherungen werden nicht in andere Regionen kopiert (siehe Anlage 3, https://leitstelle.live/unterauftragsverarbeiter).
• Jede geplante Sicherung wird nach Erstellung automatisch auf Lesbarkeit geprüft.
• Überwachung der Sicherungen alle 10 Minuten (Alter, Fehlschläge, fehlende externe Kopie, fehlender Schlüssel); Warnung per E-Mail an die Plattform-Administratoren, Erinnerung alle 6 Stunden; externer Heartbeat-Dienst für den Ausfall des Servers oder Mailwegs.
• Überwachung von Auslastung und Systemzustand minütlich (Anfragen, Fehlerquoten, Antwortzeiten, Warteschlangen, Datenbank, CPU, Arbeitsspeicher, Plattenplatz) mit Warnschwellen und Benachrichtigung.
• Schutz vor Überlast und Missbrauch: Begrenzung der Anfragerate an Anmeldung, Registrierung, Passwort-Zurücksetzen, Schnittstellen und weiteren Endpunkten.
• Mailserver: Überwachung von Dienst, Warteschlange, Zustellfehlern, DNS-Einträgen, Zertifikat und Sperrlisten sowie eine Kontroll-E-Mail alle 15 Minuten durch den eigenen Mailweg; Tagesgrenze für den Versand je Organisation und automatische Sperre des Versands bei auffälliger Quote von Rückläufern oder Beschwerden. Regeln, die Einsätze oder Alarme aus E-Mails auslösen, sind auf eine Absenderliste mit bestandener Absenderprüfung beschränkt, gegen Dubletten geschützt und in ihrer Zahl je Stunde begrenzt.
• Automatische Sicherheitsupdates des Betriebssystems (unattended-upgrades aktiv).
• Wartungsmodus für geplante Eingriffe; Ankündigung von Wartungen nach Hauptvertrag.
• Leitstelle und Einsatz-App werden bei Zahlungsverzug oder Kündigung nicht gesperrt, um die Einsatzfähigkeit nicht zu gefährden; der Kunde behält Lese- und Exportzugriff.
• Notbetrieb (je nach Paket): Bei einer Störung der Verbindung zum Server zeigen Leitstelle und Leitstelle Mobil den zuletzt geladenen Stand des aktiven Einsatzes weiter an (Lesemodus) und halten neue Einträge für das Einsatztagebuch bis zur Rückkehr der Verbindung auf dem Gerät vor. Der Notbetrieb ersetzt nicht die Rückfallebene des Kunden.
• Grenzen: Der Betrieb erfolgt auf einem einzelnen Server ohne automatische Ausfallumschaltung. Bei einem Ausfall wird aus der Datensicherung auf neuer Infrastruktur wiederhergestellt. Der Kunde hält nach Hauptvertrag eine Rückfallebene vor.

4. Rasche Wiederherstellbarkeit (Art. 32 Abs. 1 lit. c DSGVO)

• Dokumentierter Notfallablauf für Wiederherstellung auf dem laufenden Server, für den Totalausfall und für die Wiederherstellung einzelner Mandanten.
• Wiederherstellungspunkte: Datenbank höchstens etwa 1 Stunde, Dateien höchstens etwa 24 Stunden Datenverlust.
• Vor jeder Wiederherstellung wird automatisch eine Sicherung des aktuellen Stands erstellt; Wiederherstellung nur im Wartungsmodus und nach ausdrücklicher Bestätigung.
• Der Backup-Schlüssel ist getrennt vom Server und vom Speicherort im Passwort-Tresor hinterlegt, mit Fingerprint zur Kontrolle; Schlüsselwechsel ohne Verlust älterer Sicherungen möglich.
• Vierteljährliche Probe-Wiederherstellung ist vorgesehen.
• Nach einer Wiederherstellung werden zwischenzeitlich bearbeitete Löschersuchen erneut ausgeführt.

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

• Datenschutzmanagement: Ansprechpartner für Datenschutz ist der Inhaber; ein Datenschutzbeauftragter ist nicht benannt.
• Dokumentiertes Löschkonzept mit Fristen und automatisierten Löschläufen (täglich): u. a. Betriebs- und Nebendaten, Gruppenalarm, Registrierungen externer Kräfte, Positionsmeldungen, Push-Token, fehlgeschlagene Anmeldungen, Exporte, Protokolle, Sicherungen. Mindestfristen werden technisch erzwungen; Daten zu laufenden Einsätzen werden nicht gelöscht. Fehler einzelner Löschläufe werden angezeigt. Der Eingang wird täglich nach der Aufbewahrungsfrist des Pakets bereinigt (Papierkorb nach 30 Tagen, Protokoll der Regeln nach 90 Tagen).
• Regelmäßige Prüfungen des Quellcodes und der Anwendungslogik auf Fehler und Sicherheitsmängel mit dokumentierten Befunden; automatisierte Tests in der Auslieferungskette.
• Änderungen am Code werden versioniert, über Pull Requests geprüft und getrennt nach Umgebung ausgeliefert (Entwicklung → Test → Produktion).
• Datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO): Standortfreigabe nur nach Einwilligung, Webhooks ohne Namen und Koordinaten als Standard, kurze Fristen für Standortverläufe, Mehr-Faktor-Pflicht für Betreiber.
• Überprüfung dieser TOM mindestens jährlich sowie anlassbezogen bei wesentlichen Änderungen.
• Verfahren bei Datenschutzverletzungen: Meldung an den Kunden unverzüglich, möglichst innerhalb von 24 Stunden (§ 12 AVV).

6. Auftragskontrolle

Maßnahmen, die gewährleisten, dass Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können.

• Verarbeitung ausschließlich auf Grundlage des AVV und der dokumentierten Weisungen (Konfiguration der Plattform durch den Kunden).
• Auswahl von Unterauftragsverarbeitern unter Berücksichtigung ihrer Sicherheitsmaßnahmen; Abschluss von Auftragsverarbeitungsverträgen nach Art. 28 Abs. 4 DSGVO; bei Drittlandbezug Angemessenheitsbeschluss bzw. EU-US Data Privacy Framework oder Standardvertragsklauseln (Anlage 3, https://leitstelle.live/unterauftragsverarbeiter).
• Verpflichtung aller mit der Verarbeitung befassten Personen auf Vertraulichkeit.
• Keine Nutzung von Kundendaten zu eigenen Zwecken; Testumgebungen arbeiten mit Demo-Daten.
• Unterstützung des Kunden bei Betroffenenrechten durch Funktionen der Plattform (Export im JSON-Format, Löschung, Widerruf von Geräten und Sitzungen).
• Rückgabe und Löschung nach Vertragsende: Export innerhalb von 30 Tagen, danach Löschung; Sicherungen laufen spätestens nach 12 Monaten aus.