Technische und organisatorische Maßnahmen

Diese Übersicht beschreibt die technischen und organisatorischen Maßnahmen (TOM) nach Art. 32 DSGVO, mit denen wir personenbezogene Daten in Livo Handwerk schützen. Sie ist Teil des Auftragsverarbeitungsvertrags (/avv) und wird bei wesentlichen Änderungen aktualisiert.

Zutritt: Serverbetrieb im Rechenzentrum von IONOS SE in Deutschland; die physische Sicherung liegt beim Hoster.

Zugang: Anmeldung mit E-Mail und Passwort. Passwörter werden ausschließlich als scrypt-Hash mit Zufallssalz gespeichert, nie im Klartext. Sitzungen laufen über zufällige, serverseitig beendbare Token, ausgeliefert nur über HTTPS.

Zugriff — Rollen: Sieben Rollen als Vorlage (Inhaber, Büro, Bauleiter, Buchhaltung, Steuerberater mit reinem Lesezugriff, Monteur, Azubi); der Betrieb kann die Rechte je Rolle anpassen. In der Vorlage sieht ein Monteur zum Beispiel keine Preise, Umsätze oder Belege. Jede schreibende Aktion prüft die Rechte serverseitig, nicht nur die Oberfläche.

Zugriff — Mandantentrennung: Jede Datenbankabfrage filtert auf die Betriebskennung. Ein Kundenportal-Link zeigt genau einen Auftrag, nicht alle Aufträge eines Kunden; neun besonders sensible Datenfelder (u. a. Einkaufspreise, Nachkalkulation, DATEV- und Debitorennummern, Personaldaten) sind dort grundsätzlich gesperrt.

Geheimnisse nur als Hash: API-Schlüssel, Links ohne Anmeldung (Kundenportal, Fremdzugang, Kalender-Abo, Kundendisplay), Einladungen und Links zum Zurücksetzen des Passworts werden in der Datenbank ausschließlich als SHA-256-Hash gespeichert — auch im Sendeprotokoll und im Zugriffsprotokoll des Webservers steht der Link nicht. Der Klartext steht nur in der Antwort oder E-Mail, die ihn erzeugt. Der QR-Code auf Belegen wird aus einem Serverschlüssel abgeleitet, der nicht in der Datenbank liegt, damit jeder Ausdruck denselben Link trägt.

Zugriff — Betreiber und KI-Werkzeuge: Als Nutzer der Software mit Zugriff auf Kundeninhalte tritt ausschließlich der Betreiber selbst auf. Zur Entwicklung und zum technischen Betrieb setzt er zusätzlich KI-gestützte Assistenzwerkzeuge mit technischem Serverzugriff ein. Diese sind angewiesen, keine Kundeninhalte zu lesen oder zu verwenden: keine Inhalte aus der Datenbank der Betriebe, keine Postfächer mit Kundendaten, bei Prüfungen des laufenden Betriebs nur Zählungen. Eine technische Trennung, die das zusätzlich erzwingt, gibt es nach heutigem Stand nicht. Einzelheiten im AVV (/avv), Abschnitt 5 und 7.

Festgeschriebene Belege sind unveränderlich; Korrekturen laufen ausschließlich über eine Storno-Gegenbuchung. Belegnummern sind lückenlos und werden unter Datenbanksperre vergeben. Transportverschlüsselung durchgehend über HTTPS.

Die Datenbank wird täglich als vollständiger Dump gesichert — einmal lokal, einmal an einem getrennten Speicherort (Offsite-Kopie). Zusätzlich zeichnet die Datenbank fortlaufend ein Änderungsprotokoll (Binlog) auf, dessen abgeschlossene Dateien stündlich an denselben getrennten Speicherort hochgeladen werden — das Zeitfenster für einen möglichen Datenverlust sinkt dadurch von bis zu 24 Stunden auf die Zeit seit der letzten stündlichen Sicherung. Vor jeder Datenbankänderung (Migration) läuft zusätzlich eine eigene Sicherung. Hochgeladene Dateien (Fotos, Belege, Logos, Briefpapier, Formulare) werden stündlich verschlüsselt an denselben getrennten Speicherort übertragen. Gelöschte Dateien werden dort spätestens 31 Tage nach der Löschung endgültig entfernt. Verschwindet auf einmal ein großer Teil der Dateien (etwa wenn ein Betrieb sein Konto löscht), gibt der Betreiber die Löschung am Speicherort erst nach Prüfung frei; die 31 Tage beginnen dann mit der Freigabe. Einmal täglich wird eine zufällig gewählte Datei von dort zurückgeholt, entschlüsselt und mit dem Original verglichen.

Was wir NICHT haben und deshalb nicht zusichern: eine Wiederherstellung auf einen beliebigen Zeitpunkt (Point-in-Time-Recovery), eine vertraglich zugesicherte Verfügbarkeit (SLA), eine zweite, sofort übernahmefähige Serverumgebung, sowie eine geübte Wiederherstellung auf einer zweiten, unabhängigen Maschine und einen durchgespielten Binlog-Replay auf einen frei gewählten Zeitpunkt. Die Wiederherstellung eines Volldumps auf dem bestehenden Server haben wir dagegen gemessen (12,8 Sekunden, 19.09.2026). Wenn Sie eines der fehlenden Stücke benötigen, sprechen Sie uns vor Vertragsschluss an.

Jede Codeänderung durchläuft Typprüfung, Stilprüfung, einen vollständigen Bau sowie automatisierte Prüfungen, die unter anderem Mandantentrennung, Rollenrechte, Rechenwege, die Unveränderlichkeit festgeschriebener Belege und die Vollständigkeit der Löschung gegen den tatsächlichen Datenbankstand abdecken. Änderungen sind vollständig versioniert.