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

Anlage 1 zum Vertrag zur Auftragsverarbeitung – Mein Baubüro

Abschnitte 1 bis 6 beschreiben Maßnahmen, die im System umgesetzt sind. Abschnitt 7 enthält die Maßnahmen, die der Auftragnehmer vor Beginn des Pilotbetriebs umsetzt (Zusagen); bis zu ihrer Umsetzung gelten sie als nicht erfüllt. Organisatorische Angaben des Auftragnehmers sind als Platzhalter markiert.

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

1.1 Zutrittskontrolle

  • Server, Datenbank und Dateispeicher werden in Rechenzentren der Hetzner Online GmbH betrieben ({{HETZNER_STANDORTE}}). Die physische Sicherung (Zutrittskontrolle, Videoüberwachung, Brandschutz, Stromversorgung) erfolgt durch den Rechenzentrumsbetreiber nach dessen Sicherheitskonzept {{HETZNER_ZERTIFIZIERUNG}}.
  • Büroräume des Auftragnehmers: {{BUERO_ZUTRITTSKONTROLLE}}.

1.2 Zugangskontrolle (Nutzer der Anwendung)

  • Anmeldung mit E-Mail-Adresse und Passwort; Passwörter werden ausschließlich als Hashwert mit dem Verfahren Argon2id gespeichert. Mindestlänge 8 Zeichen.
  • Zwei-Faktor-Anmeldung (TOTP) für alle Nutzer verfügbar und für die Rollen „Administrator“ und „Büro“ verpflichtend einzurichten. Das TOTP-Geheimnis wird verschlüsselt gespeichert; der Schlüssel liegt nur in der Server-Konfiguration.
  • Kurzlebige Zugriffstoken (15 Minuten) und rotierende Erneuerungstoken (höchstens 7 Tage). Erneuerungstoken werden nur als Hashwert gespeichert; die Anmelde-Cookies der Web-Anwendung sind für Skripte nicht lesbar (httpOnly).
  • Sitzungen sind je Gerät einsehbar und können sofort widerrufen werden (z. B. bei Geräteverlust). Der Widerruf wird bei jeder Anfrage ohne Zwischenspeicher geprüft; eine Passwortänderung beendet alle Sitzungen des Kontos.
  • Begrenzung von Anmeldeversuchen und ähnlichen sicherheitskritischen Anfragen (Anmeldung, Zwei-Faktor-Prüfung, Registrierung, Passwort-Zurücksetzen, Einladung) über einen gemeinsamen Zählspeicher für alle Serverinstanzen. Ist der Zählspeicher gestört, werden diese Anfragen im Produktivbetrieb abgewiesen statt ohne Begrenzung zugelassen.
  • Kontoweite Bremse für Zwei-Faktor-Codes: höchstens 10 Prüfungen je Konto und Stunde, danach 15 Minuten Sperre mit Hinweis-E-Mail an die Person.
  • Schutz vor dem Ausspähen bestehender Konten: Anmeldung und Passwort-Zurücksetzen antworten unabhängig davon gleich, ob ein Konto existiert, auch hinsichtlich der Antwortzeit.
  • Links zum Zurücksetzen des Passworts sind 30 Minuten gültig, nur einmal verwendbar und werden nur als Hashwert gespeichert. Registrierungslinks sind 48 Stunden gültig.
  • Die Anwendung verweigert im Produktivbetrieb den Start, wenn Platzhalter- oder Entwicklungswerte als Geheimnisse, unverschlüsselte Adressen für den Dateispeicher oder eine Rechtstext-Vorlage konfiguriert sind.

1.3 Zugriffskontrolle

  • Rollen- und Berechtigungskonzept: Jede Funktion ist an Berechtigungen gebunden; Rollen werden je Betrieb vergeben. Funktionen (Module) können je Betrieb und je Person abgeschaltet werden; die Abschaltung wird serverseitig durchgesetzt.
  • Mitarbeiter sehen grundsätzlich nur eigene Daten und die ihnen zugewiesenen Projekte; Daten mit besonderer Sensibilität (z. B. Krankmeldungen, persönliche Dokumente wie Lohnabrechnungen) sind nur für die betroffene Person und ausdrücklich berechtigte Rollen sichtbar.
  • Persönliche Dokumente sind zusätzlich auf Datenbankebene personenbezogen abgesichert (zusätzliche, nicht aufweichbare Zugriffsregel).
  • Dateien werden über zeitlich begrenzte, signierte Download-Adressen ausgeliefert; vor jeder Ausgabe wird die Berechtigung an dem zugehörigen Datensatz geprüft.
  • Der KI-Assistent arbeitet ausschließlich mit den Berechtigungen der anfragenden Person. Schreibende Aktionen werden nur als Vorschlag erzeugt und erst nach ausdrücklicher Bestätigung durch die Person ausgeführt. Der Assistent hat keine Werkzeuge mit Außenwirkung (kein Versand von E-Mails oder Nachrichten, keine Freigaben).
  • Die Anwendung enthält keine betreiberseitige Oberfläche mit Zugriff auf Daten der Betriebe. Zugriffe von Mitarbeitern des Auftragnehmers auf Kundendaten (z. B. im Support oder über die Datenbank): {{SUPPORT_ZUGRIFFSKONZEPT}}.

1.4 Trennungskontrolle (Mandantentrennung)

  • Jeder Datensatz ist einem Betrieb (Mandanten) zugeordnet. Die Trennung wird zusätzlich zur Prüfung in der Anwendung auf Datenbankebene durch Zeilenschutzregeln (PostgreSQL Row-Level Security, erzwungen auch für den Tabelleneigentümer) durchgesetzt. Ohne gesetzten Mandantenkontext liefert die Datenbank keine Zeilen.
  • Die Anwendung arbeitet mit einer Datenbankrolle ohne Umgehungsrechte; mandantenübergreifende Wartungsläufe nutzen eine getrennte Rolle und sind auf festgelegte Aufgaben beschränkt.
  • Für die Mandantentrennung gibt es eine eigene automatisierte Testsuite gegen eine echte Datenbank. Echtzeit-Benachrichtigungen werden nur innerhalb des jeweiligen Mandanten verteilt.
  • Auf dem Endgerät legt die App für jede Kombination aus Betrieb und Person einen eigenen lokalen Datenbereich an.
  • Entwicklung und Tests arbeiten mit Beispieldaten, nicht mit Produktionsdaten.

1.5 Verschlüsselung und Pseudonymisierung

  • Der E-Mail-Versand verweigert eine Anmeldung am Mailserver ohne Verschlüsselung. Verbindungen zum Zwischenspeicher (Redis) können verschlüsselt werden.
  • Auf dem Endgerät: Anmeldedaten im geschützten Schlüsselspeicher des Betriebssystems; die lokale Datenbank ist durch die App-Sandbox und die Geräteverschlüsselung des Betriebssystems geschützt (keine zusätzliche anwendungseigene Verschlüsselung).
  • Pseudonymisierung: Das Nutzungsprotokoll der KI enthält keine Inhalte; der Personenbezug wird nach 13 Monaten entfernt. Bei der Löschung einer Person werden ihr Konto und ihre Daten anonymisiert, soweit Aufbewahrungspflichten eine vollständige Löschung ausschließen.
  • Transportverschlüsselung zwischen Endgeräten und Servern sowie Verschlüsselung ruhender Daten: siehe Zusagen in Abschnitt 7.

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

2.1 Weitergabekontrolle

  • Exporte und Datenkopien werden über zeitlich begrenzte Download-Adressen bereitgestellt; Datenkopien für Betroffenenanfragen werden nach Ablauf der Abholfrist (voreingestellt 30 Tage) automatisch entfernt.
  • An den KI-Vermittlungsdienst werden nur die für die jeweilige Anfrage erforderlichen Daten übermittelt; zulässige Zieladressen sind fest begrenzt. {{REQUESTY_EU_ERZWUNGEN_SATZ}} Sprachaufnahmen werden voreingestellt unmittelbar nach der Umwandlung in Text gelöscht (vom Betrieb auf bis zu 30 Tage einstellbar), bei Fehlern spätestens 24 Stunden nach dem ersten Fehlschlag.
  • An den Wetterdienst werden nur Postleitzahl, Ort, Koordinaten und Datum übermittelt, keine Personendaten.
  • Push-Benachrichtigungen enthalten Titel und kurzen Text; bei Erwähnungen im Chat den Namen der absendenden Person, den Namen des Projekts bzw. der Gruppe und bis zu 140 Zeichen des Nachrichtentextes.

2.2 Eingabekontrolle

  • Änderungsprotokoll (nur anfügbar): Änderungen an Zeit- und Lohndaten und weiteren wichtigen Daten werden mit Person, Zeitpunkt, Quelle (App, Verwaltung, System, KI) sowie altem und neuem Wert protokolliert. Die Anwendung hat auf das Protokoll keine Änderungs- oder Löschrechte.
  • Von der KI vorbereitete und bestätigte Einträge sind als solche gekennzeichnet.
  • Abrechnungssperren verhindern nachträgliche Änderungen in abgeschlossenen Zeiträumen; auch offline erfasste Änderungen werden serverseitig geprüft und gegebenenfalls zur manuellen Klärung zurückgestellt.
  • Zustellprotokolle für E-Mails und Push-Benachrichtigungen.
  • Sicherheitsrelevante Ereignisse der Zwei-Faktor-Anmeldung werden als strukturierte Protokolleinträge ausgegeben; Protokolle enthalten keine Passwörter, Codes oder Token.
  • Die Zustimmung zu AGB und Datenschutzerklärung wird mit Fassung und Zeitpunkt am Konto und im Änderungsprotokoll festgehalten.

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

  • Die App ist offline nutzbar; Einträge werden lokal gepuffert und bei Verbindung übertragen. Wiederholte Übertragungen führen nicht zu Doppelungen.
  • Hintergrundaufgaben (z. B. E-Mail-Versand, PDF-Erzeugung) laufen über eine Warteschlange mit automatischer Wiederholung; beim Neustart werden laufende Aufgaben geordnet zurückgestellt.
  • Begrenzung der Anfragen je Absender und Kontingente für KI-Anfragen je Betrieb und Person.
  • Belege und erzeugte PDF-Dokumente sind während der Vertragslaufzeit von der automatischen Löschung ausgenommen; nach Vertragsende werden sie mit allen übrigen Daten des Betriebs gelöscht (Abschnitt 5).
  • Datensicherung, Wiederherstellung und Überwachung: siehe Zusagen in Abschnitt 7.

4. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)

  • Automatisierte Testsuiten liegen vor, darunter eine Suite zur Mandantentrennung und eine Prüfung, dass jede Datentabelle einer Aufbewahrungsklasse und der Betroffenenauskunft zugeordnet ist. Eine automatische Ausführung in einer zentralen Build-Kette besteht noch nicht (siehe Abschnitt 7).
  • Prüfung der Server-Konfiguration beim Start; unsichere oder unvollständige Konfiguration verhindert den Start im Produktivbetrieb.
  • Code-Prüfung: Fachlich relevante Änderungen werden vor der Übernahme von einer unabhängigen, KI-gestützten Prüfinstanz begutachtet; Befunde werden vor der Übernahme behoben oder begründet zurückgewiesen. Ein zusätzliches menschliches Vier-Augen-Review findet nicht regelmäßig statt.
  • Überprüfung dieser Maßnahmen mindestens jährlich sowie bei wesentlichen Änderungen: {{TOM_REVIEW_VERANTWORTLICH}}.

5. Datenschutzfreundliche Voreinstellungen und Löschung (Art. 25 DSGVO)

  • Der Aufnahmeort von Bautagebuch-Fotos wird nur gespeichert, wenn die Person dies auf ihrem Gerät einschaltet (standardmäßig aus); die App fragt den Standort nie im Hintergrund ab. Bei aktivierter Betriebseinstellung und Vordergrundfreigabe wird beim Ein-/Ausstempeln höchstens ein Punkt erfasst; Messung endet nach dem ersten Punkt oder 800 ms, auch bei verspäteter Initialisierung. Ohne Punkt wird weitergestempelt. Keine Hintergrundortung oder Messung dazwischen; Offline-Punkte reisen im Stempelpuffer mit. Anzeige nur mit dem Recht zum Lesen aller Zeiten. Keine eigene GPS-Frist im aktuellen Löschkatalog: Punkte teilen technisch die Zeitdatenfrist (Standard acht Jahre ab Jahresende; Purge nach Löschmarkierung/Karenz). Getrennte kürzere Frist und Rechtsgrundlage sind Prüfpunkt der Rechtsberatung.
  • KI-Funktionen sind je Betrieb und Person abschaltbar; Sprachaufnahmen werden standardmäßig nicht aufbewahrt.
  • Automatische Löschung (täglicher Löschlauf) nach Aufbewahrungsfristen je Datenklasse, die der Betrieb einstellt; gesetzliche Mindestfristen können nicht unterschritten werden, jeder Löschlauf wird mit Frist und Umfang protokolliert. Dabei gilt:
    • Grundsätzlich beginnt die Frist erst, wenn ein Eintrag im Dienst gelöscht (als gelöscht markiert) wird. Nicht gelöschte Einträge bleiben bis zur Löschung bzw. bis zum Vertragsende gespeichert. Endgültig entfernt wird ein gelöschter Eintrag nach Ablauf der Frist, frühestens 180 Tage nach dem Löschen. Bei Zeit- und Lohndaten beginnt die Frist mit dem Ende des Kalenderjahres der Löschung.
    • Chatnachrichten werden nach Ablauf der Frist ab dem Versand unkenntlich gemacht (Text und Anhänge entfernt) und 180 Tage danach endgültig gelöscht.
    • Einladungen, E-Mail- und Push-Zustellprotokolle, Gerätesitzungen, Passwort-Links und das Übertragungsprotokoll der App werden ab ihrer Erstellung gelöscht, sobald sie erledigt bzw. abgelaufen sind und die Frist verstrichen ist.
    • Das Änderungsprotokoll und Statusverläufe werden derzeit nicht automatisch gelöscht.
    • Benutzerkonten werden bei der Löschung einer Person anonymisiert, nicht entfernt.
  • Nie bestätigte Registrierungen und abgelaufene Registrierungslinks werden automatisch gelöscht.
  • Löschung nach Vertragsende: 30 Tage nach Vertragsende endet die Exportfrist, 30 Tage danach werden sämtliche Daten des Betriebs gelöscht — Datenbank in Chargen einschließlich aller Belege und erzeugten Dokumente, alle Dateien im Dateispeicher und die zugehörigen Zwischenspeicher-Einträge. Vor Fristende erinnern E-Mails an alle Administratoren 30, 7 und 1 Tag vorher an den Export. Der Löschlauf ist wiederaufnehmbar, prüft zum Abschluss, dass keine Daten des Betriebs mehr vorhanden sind, und protokolliert Umfang und Zeitpunkte ohne Klartextdaten; ab Löschbeginn ist keine Anmeldung mehr möglich. Eine Löschsperre (z. B. bei Rechtsstreit) setzt nur der Betreiber, begründet und protokolliert. Eine Löschliste (nur Kennungen) außerhalb der Datenbanksicherung stellt sicher, dass nach einer Wiederherstellung aus einer Sicherung bereits gelöschte Betriebe erneut gelöscht werden; Sicherungen werden nach 30 Tagen überschrieben.
  • Funktionen für Datenkopie, Berichtigung und Löschung bzw. Anonymisierung je Person (Umfang und Grenzen siehe Vertrag zur Auftragsverarbeitung, § 7).

6. Organisatorische Maßnahmen

  • Verpflichtung aller Personen mit Zugriff auf Kundendaten auf Vertraulichkeit: {{VERTRAULICHKEIT_VERPFLICHTUNG}}.
  • Datenschutzbeauftragter: Matthias Jäger, datenschutz@hiprocall.de, +49 (0)89 4200 188-0.
  • Prozess für Datenschutzverletzungen (Erkennung, Bewertung, Meldung an Auftraggeber und ggf. Behörde): {{INCIDENT_PROZESS}}.
  • Auswahl und Kontrolle von Unterauftragsverarbeitern: nur mit Vertrag nach Art. 28 DSGVO, Prüfung der Garantien vor Einsatz (siehe Anlage 2).
  • Verzeichnis von Verarbeitungstätigkeiten als Auftragsverarbeiter (Art. 30 Abs. 2 DSGVO): {{VVT_STATUS}}.

7. Zusagen: vor Beginn des Pilotbetriebs umzusetzen

Der Auftragnehmer setzt folgende Maßnahmen vor Beginn des Pilotbetriebs um und bestätigt dem Auftraggeber die Umsetzung in Textform:

  1. Verschlüsselung aller Verbindungen zwischen Endgeräten und Servern mit TLS (mindestens Version 1.2) einschließlich HSTS; Betrieb des Reverse-Proxys durch den Auftragnehmer.
  2. Verschlüsselung bzw. Abschottung der Verbindungen zu Datenbank und Zwischenspeicher: {{INTERNE_NETZ_VERSCHLUESSELUNG}}.
  3. Verschlüsselung ruhender Daten (Datenträger der Datenbank, serverseitige Verschlüsselung des Dateispeichers): {{VERSCHLUESSELUNG_AT_REST}}.
  4. Tägliche Datensicherung der Datenbank mit fortlaufender Archivierung der Transaktionsprotokolle, Sicherung des Dateispeichers, Aufbewahrung der Sicherungen 30 Tage an einem getrennten Standort ({{BACKUP_STANDORT}}). Ziele: Datenverlust höchstens 24 Stunden (RPO), Wiederherstellung innerhalb von 12 Stunden (RTO); dokumentierte, regelmäßig geübte Wiederherstellung ({{RESTORE_TEST_INTERVALL}}).
  5. Überwachung der Erreichbarkeit, zentrale Protokollierung und Alarmierung, auch auf Sicherheitsereignisse: {{MONITORING_LOESUNG}}; Löschung der Sicherheitsprotokolle nach {{SICHERHEITSLOG_FRIST_TAGE}} Tagen.
  6. Administrative Zugänge zu Servern und Hosting-Konsole: {{ADMIN_ZUGANG_SERVER}} (z. B. SSH nur mit Schlüssel, Zwei-Faktor-Anmeldung an der Konsole).
  7. Zentraler Geheimnisspeicher; keine Geheimnisse im Quellcode oder in Container-Images.
  8. Sicherheits-HTTP-Header (u. a. Content-Security-Policy).
  9. Automatische Ausführung der Testsuiten sowie Abhängigkeits- und Container-Prüfung auf bekannte Schwachstellen in einer zentralen Build-Kette.
  10. Unveränderbare Ablage von Belegen und PDF-Dokumenten im Dateispeicher (Object Lock): nicht im Pilot (F34).
  11. Penetrationstest durch einen externen Dienstleister: {{PENTEST_TERMIN}}.

Stand: {{STAND_DATUM}}

Technische Fehlerberichte der Mobile-App

  • Fehleranalyse nur bei bestätigter serverseitiger Aktivierung (30 Minuten Konfigurationscache, Offline-Freigabe höchstens sieben Tage). Transportfehler widerrufen diese Freigabe nicht. Geräteschalter unter „Mehr“ → „Datenschutz“, standardmäßig an; Abschalten sperrt die Erfassung und löscht den Puffer, geräteweite Einstellung als Ja/Nein in AsyncStorage. Rechtliche Freigabe der lokalen Ablage vor Aktivierung weiterhin erforderlich.
  • Datenminimierung bereits auf dem Gerät und erneute Redaktion auf dem Server: feste JavaScript-Fehlerkategorien, Bundle-Positionen, App-/Betriebssystemversion, Plattform, pseudonyme Konto-ID und Fehlerzählung. Keine Namen, E-Mails, Zugangsdaten, Arbeitsinhalte, Nutzungsverläufe oder nativen Absturzberichte.
  • Begrenzte lokale Ablage (20 Berichte, jeweils weniger als 4 KiB, Ablauf nach sieben Tagen mit Bereinigung bei nächster App-Ausführung), gebündelte Übertragung über die TLS-geschützte API mit Wiederholungsabständen und Löschung erfolgreich übertragener Berichte. Öffentlicher Diagnose-Endpunkt mit IP-basiertem Rate-Limit und Größen-/Schema-Prüfung vor Verarbeitung; zusätzlich globales Redis-Budget von 100 Mobile-Events je 60-Sekunden-Zählerfenster über alle IPs/Instanzen, Überschuss verwerfen, höchstens eine Warnung pro Minute. Bei Redis-Ausfall keine Weiterleitung. Keine Mandantendatenbank-Zugriffe. Bei Abmeldung, Kontolöschung und Nutzerwechsel Konto-UUID aus wartenden Berichten entfernen; beim Kaltstart ebenso. Fatale JS-Fehler in Release können vor Abschluss der asynchronen Ablage verloren gehen.
  • Server-Protokolle höchstens {{SERVER_LOG_FRIST_TAGE}} Tage, Fehleranalyse höchstens {{FEHLERTRACKING_FRIST_TAGE}} Tage; Empfänger und Standort gemäß der vor Veröffentlichung auszufüllenden Fehleranalyse-Entscheidung. Ohne aktivierte Fehleranalyse keine ersatzweise Diagnose-Protokollierung.