Auftragsverarbeitungsvertrag
Stand: 30.08.2026
nach Artikel 28 Absatz 3 der Verordnung (EU) 2016/679 (DSGVO) Produkt: Instandio (Instandhaltungs- und Prüffristenmanagement)
Dokumentfassung: AVV-Version 1.2 · Stand 30.08.2026 Anlagen: Anlage 1 (Verarbeitungsübersicht), Anlage 2 (Technische und organisatorische Maßnahmen), Anlage 3 (Unterauftragsverarbeiter)
Empfehlung vorweg: die EU-Standardvertragsklauseln statt dieses Vertrags
Ein eigener Vertragstext ist nicht erforderlich. Art. 28 Abs. 6 und 7 DSGVO lassen zu, dass ein Auftragsverarbeitungsvertrag ganz oder teilweise auf von der Kommission erlassenen Standardvertragsklauseln beruht. Diese Klauseln liegen vor:
Durchführungsbeschluss (EU) 2021/915 der Kommission vom 04.06.2021 über Standardvertragsklauseln zwischen Verantwortlichen und Auftragsverarbeitern gemäß Artikel 28 Absatz 7 der Verordnung (EU) 2016/679, Amtsblatt L 199 vom 07.06.2021, Seiten 18 bis 30.
Was das bringt: Der Text steht fest und darf inhaltlich nicht verändert werden. Damit entfällt jede Diskussion über die Wirksamkeit einzelner Klauseln, insbesondere über die Beschränkung des Prüfungsrechts (§ 9) und über die Änderungsklausel (§ 2). Eine prüfende Rechtsabteilung erkennt das Dokument wieder und muss es nicht zeilenweise lesen. Kosten: 0,00 €.
Die Anhänge lassen sich unmittelbar aus diesem Satz übernehmen:
Anhang der Standardvertragsklauseln Inhalt Quelle bei uns Anhang I Parteien, Beschreibung der Verarbeitung, Kategorien betroffener Personen und Datenarten, Zwecke, Dauer 11_Anlage-1-Verarbeitungsuebersicht.md, direkt einsetzbarAnhang II Technische und organisatorische Maßnahmen 12_Anlage-2-TOM.md: nur die Maßnahmen mit dem Stand✔ umgesetzt. Die Standardvertragsklauseln kennen keine Freizeichnung wie § 6 Absatz 2 dieses VertragsAnhang III Liste der Unterauftragsverarbeiter 13_Anlage-3-Unterauftragsverarbeiter.md, führt seit dem 15.08.2026 die Supabase Pte. Ltd.Was die Standardvertragsklauseln nicht lösen: Sie beseitigen das Risiko der Vertragsform, nicht das Risiko der Substanz. Ein Anhang II mit fast ausschließlich geplanten Maßnahmen bleibt ein Anhang II mit fast ausschließlich geplanten Maßnahmen, ohne die Möglichkeit, das im Text zu kennzeichnen. Deshalb gilt auch bei ihrer Verwendung § 6 Absatz 5 dieses Vertrags: kein Produktivbetrieb, solange eine als kritisch gekennzeichnete Maßnahme nicht den Stand
✔trägt.Was aus diesem Vertrag erhaltenswert bleibt und als ergänzende Vereinbarung neben die Standardvertragsklauseln gehört, weil diese es nicht regeln: die Versionierung des Vertrags (§ 2), die Karenzzeit mit Exportfenster und Löschprotokoll (§ 11 Absatz 2), der Verzicht auf ein Zurückbehaltungsrecht (§ 11 Absatz 7) und die Abgrenzung der aggregierten Produktkennzahlen (§ 4 Absatz 7). Ergänzende Regelungen sind zulässig, solange sie den Klauseln nicht widersprechen.
Vertragsparteien
Auftragsverarbeiter (nachfolgend „vdw“ oder „Auftragsverarbeiter“)
vdw GmbH Fichtenstr. 49 57368 Lennestadt Telefon: 02723/719334 E-Mail: info@v-d-w.de Geschäftsführer: Olaf von Deines, Dorian Wolf Handelsregister: HRB Siegen 13974 USt-ID: DE369550121
Verantwortlicher (nachfolgend „Kunde“ oder „Verantwortlicher“)
Vom Kunden auszufüllen:
Firma: ______________________________________________ Anschrift: ___________________________________________ Vertreten durch: _____________________________________ Handelsregister: _____________________________________ Ansprechpartner Datenschutz (Name, E-Mail, Telefon): ______________________________________________
§ 1 Gegenstand, Rangfolge und Dauer
(1) Gegenstand. Der Kunde nutzt die Software Instandio als von vdw betriebene Anwendung (Software as a Service) zur Verwaltung von Prüf- und Wartungspflichten an technischen Arbeitsmitteln und Anlagen. vdw verarbeitet dabei personenbezogene Daten ausschließlich im Auftrag und nach Weisung des Kunden. Der Kunde bleibt Verantwortlicher im Sinne des Art. 4 Nr. 7 DSGVO; vdw ist Auftragsverarbeiter im Sinne des Art. 4 Nr. 8 DSGVO.
(2) Verhältnis zum Hauptvertrag. Dieser Vertrag konkretisiert die datenschutzrechtlichen Pflichten aus dem zwischen den Parteien geschlossenen Nutzungsvertrag über Instandio (nachfolgend „Hauptvertrag“) einschließlich der zugehörigen Leistungsbeschreibung und der Allgemeinen Geschäftsbedingungen.
(3) Rangfolge. Bei Widersprüchen gilt: dieser Vertrag mit seinen Anlagen vor dem Hauptvertrag vor den Allgemeinen Geschäftsbedingungen. Innerhalb dieses Vertrags gehen die Anlagen dem Vertragstext vor, soweit sie ihn konkretisieren, nicht jedoch, soweit sie ihm widersprechen.
(4) Dauer. Dieser Vertrag beginnt mit seiner Annahme durch den Kunden und läuft für die Dauer des Hauptvertrags. Er endet mit dessen Beendigung; die Pflichten aus § 11 (Löschung und Rückgabe), § 5 (Vertraulichkeit) und § 13 (Haftung) bestehen darüber hinaus fort.
(5) Kündigung. Eine gesonderte Kündigung dieses Vertrags ohne gleichzeitige Beendigung des Hauptvertrags ist ausgeschlossen, weil die Nutzung von Instandio ohne Auftragsverarbeitung nicht möglich ist. Unberührt bleibt das außerordentliche Kündigungsrecht des Kunden nach § 8 Absatz 5 (Widerspruch gegen einen Unterauftragsverarbeiter) und bei schwerwiegenden, nicht abgestellten Verstößen von vdw gegen diesen Vertrag.
§ 2 Annahme, Versionierung und Änderung dieses Vertrags
(1) Technisch erzwungene Annahme. Der Produktivbetrieb von Instandio setzt die Annahme dieses Vertrags voraus. Die Anwendung speichert dazu je Mandant
| Feld im Datenbestand | Inhalt |
|---|---|
mandant.avv_version | die Versionsnummer der angenommenen Fassung, z. B. 1.0 |
mandant.avv_akzeptiert_am | Datum und Uhrzeit der Annahme |
mandant.avv_akzeptiert_von | Kennung der annehmenden Person beim Kunden |
Ohne gesetzte Werte in diesen Feldern schaltet die Anwendung den Mandanten nicht produktiv. Der Kunde kann die angenommene Fassung, das Annahmedatum und alle früheren Fassungen jederzeit in der Anwendung einsehen und als PDF abrufen.
○ geplant, Stand 07.08.2026: die Felder sind im Datenmodell vorgesehen, die Anwendung besitzt weder Mandantenverwaltung noch Zustimmungsdialog.
(2) Versionsnummern. Fassungen dieses Vertrags werden nach dem Muster Hauptversion.Nebenversion gezählt.
| Änderungsart | Beispiel | Wirkung |
|---|---|---|
Nebenversion (1.0 → 1.1) | redaktionelle Klarstellung, Aufnahme oder Wechsel eines Unterauftragsverarbeiters, Ergänzung einer zusätzlichen technischen Maßnahme in Anlage 2 | Ankündigung nach Absatz 3; keine erneute Annahme erforderlich; Widerspruchsrecht nach § 8 Absatz 5 bleibt unberührt |
Hauptversion (1.x → 2.0) | Änderung von Gegenstand, Zweck, Datenarten, Verarbeitungsort, Löschfristen oder Haftung; Wegfall einer bisher zugesicherten Maßnahme | erneute ausdrückliche Annahme durch den Kunden erforderlich; ohne Annahme bleibt die bisherige Fassung für den laufenden Vertrag maßgeblich |
(3) Ankündigung. vdw kündigt jede neue Fassung mindestens 30 Tage vor ihrem Wirksamwerden in Textform an den beim Kunden hinterlegten Datenschutz-Ansprechpartner sowie in der Anwendung an. Die Ankündigung nennt die Versionsnummer, das Wirksamkeitsdatum und eine Gegenüberstellung der Änderungen.
(4) Nachweis. Die Versionierung nach diesem Paragraphen dient zugleich dem Nachweis nach Art. 5 Abs. 2 DSGVO. vdw bewahrt jede Fassung dieses Vertrags mit dem Zeitpunkt ihrer Gültigkeit und den Annahmen der Kunden für die Dauer des Vertragsverhältnisses und zehn Jahre darüber hinaus auf.
§ 3 Art, Umfang und Zweck der Verarbeitung; Datenarten; betroffene Personen
(1) Art, Umfang, Zweck der Verarbeitung, die Arten der verarbeiteten personenbezogenen Daten und die Kategorien betroffener Personen ergeben sich abschließend aus Anlage 1 (Verarbeitungsübersicht).
(2) Zusammenfassung. Die Verarbeitung umfasst das Erheben, Erfassen, Organisieren, Speichern, Anpassen, Auslesen, Abfragen, Verwenden, Übermitteln innerhalb des Systems, Einschränken, Löschen und Vernichten personenbezogener Daten zum Zweck des Betriebs von Instandio für den Kunden.
(3) Keine Verarbeitung besonderer Kategorien. Die Parteien sind sich einig, dass Instandio nicht für die Verarbeitung besonderer Kategorien personenbezogener Daten nach Art. 9 DSGVO bestimmt ist. Zu arbeitsmedizinischen Vorsorgen sollen weder Untersuchungsergebnisse noch Befunde erfasst werden, sondern ausschließlich das Faktum „Eignungsnachweis liegt vor, gültig bis TT.MM.JJJJ“ ohne Dokument.
Keine Zusicherung einer technischen Sperre. ○ geplant, Stand 07.08.2026: die technische Sperre des Dokumentuploads für Qualifikationen der Kategorie „Eignung“ (Anlage 2 Nr. 1.5.6) ist in ARCHITEKTUR.md §2.5 vorgesehen, in der Anwendung 1.1 jedoch nicht gebaut. Der Datentyp Zertifikat erlaubt derzeit den Upload beliebiger Nachweisdateien ohne Kategorieprüfung. vdw sichert eine solche Sperre für den Stand dieses Vertrags nicht zu. Die Einhaltung des Absatzes 4 obliegt bis zu ihrer Umsetzung allein dem Kunden; vdw weist ihn hierauf vor der Aufnahme der Nutzung gesondert und in Textform hin und lässt den Hinweis gegenzeichnen.
(4) Pflicht des Kunden. Der Kunde verpflichtet sich, in Instandio keine Daten nach Art. 9 DSGVO und keine Daten über strafrechtliche Verurteilungen und Straftaten (Art. 10 DSGVO) einzugeben oder hochzuladen. Erlangt vdw Kenntnis von einem Verstoß, teilt vdw dies dem Kunden unverzüglich mit; die Entfernung obliegt dem Kunden.
(5) Ort der Verarbeitung. Die Verarbeitung findet ausschließlich in Mitgliedstaaten der Europäischen Union oder in Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum statt. Der konkrete Verarbeitungsort ergibt sich aus Anlage 1 und Anlage 3. Jede Verlagerung in ein Drittland bedarf der vorherigen Zustimmung des Kunden und setzt das Vorliegen der Voraussetzungen der Art. 44 bis 49 DSGVO voraus.
§ 4 Weisungsrecht und Weisungsbindung
(1) Verarbeitung nur auf Weisung. vdw verarbeitet personenbezogene Daten ausschließlich auf dokumentierte Weisung des Kunden, einschließlich in Bezug auf die Übermittlung in Drittländer, es sei denn, vdw ist hierzu nach dem Recht der Union oder eines Mitgliedstaats verpflichtet, dem vdw unterliegt. In einem solchen Fall teilt vdw dem Kunden diese rechtlichen Anforderungen vor der Verarbeitung mit, sofern das betreffende Recht eine solche Mitteilung nicht wegen eines wichtigen öffentlichen Interesses verbietet (Art. 28 Abs. 3 lit. a DSGVO).
(2) Weisungen im Regelbetrieb. Als Weisung gelten:
a) dieser Vertrag einschließlich seiner Anlagen sowie der Hauptvertrag mit Leistungsbeschreibung: sie bilden die Grunddauerweisung, b) die vom Kunden in der Anwendung vorgenommenen Einstellungen, insbesondere Aufbewahrungsfristen, Sichtbarkeitsstufe des QR-Portals, Benachrichtigungsregeln, Rollen- und Rechtevergabe, Freischaltung personenbezogener Auswertungen, c) Einzelweisungen in Textform nach Absatz 3.
(3) Einzelweisungen. Einzelweisungen erteilt der Kunde in Textform an datenschutz@v-d-w.de, solange dieses Postfach nicht eingerichtet ist an info@v-d-w.de. Mündliche Weisungen bestätigt der Kunde unverzüglich in Textform. vdw dokumentiert jede Einzelweisung mit Eingang, Inhalt, ausführender Person und Ausführungszeitpunkt und bewahrt diese Dokumentation für die Vertragsdauer und drei Jahre darüber hinaus auf.
(4) Weisungsberechtigte. Weisungsberechtigt sind auf Seiten des Kunden die in Anlage 1 Abschnitt 8 benannten Personen. Der Kunde hält diese Liste aktuell. vdw benennt als weisungsempfangende Stelle Olaf von Deines, Geschäftsführer, in Vertretung Dorian Wolf, Geschäftsführer.
(5) Hinweispflicht bei rechtswidriger Weisung. Ist vdw der Auffassung, dass eine Weisung gegen die DSGVO oder gegen andere Datenschutzbestimmungen der Union oder der Mitgliedstaaten verstößt, informiert vdw den Kunden unverzüglich (Art. 28 Abs. 3 Satz 3 DSGVO). vdw ist berechtigt, die Ausführung der betreffenden Weisung bis zu deren Bestätigung oder Änderung durch den Kunden auszusetzen. Bestätigt der Kunde die Weisung schriftlich, führt vdw sie aus; die Verantwortung trägt insoweit der Kunde.
(6) Mehraufwand. Weisungen, die über den vertraglich vereinbarten Leistungsumfang hinausgehen und bei vdw einen Aufwand von mehr als zwei Stunden verursachen, vergütet der Kunde nach dem im Hauptvertrag vereinbarten Stundensatz. vdw weist auf die Vergütungspflicht vor der Ausführung hin. Unentgeltlich bleiben stets Weisungen, die auf die Herstellung eines datenschutzkonformen Zustands gerichtet sind, den vdw zu vertreten hat.
(7) Kein eigener Zweck. vdw verwendet die im Auftrag verarbeiteten Daten nicht für eigene Zwecke. Zulässig bleibt die Erhebung aggregierter, nicht personenbezogener Produkt- und Nutzungskennzahlen (Anzahl der Objekte, gebuchte Module, Zahl der Anmeldungen je Mandant) zur Abrechnung, zur Kapazitätsplanung und zur Produktverbesserung. Eine Auswertung von Inhalten findet nicht statt.
§ 5 Vertraulichkeit
(1) Verpflichtung der Beschäftigten. vdw verpflichtet alle zur Verarbeitung der personenbezogenen Daten befugten Personen zur Vertraulichkeit, soweit sie nicht bereits einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO). Die Verpflichtung erfolgt in Textform vor der ersten Tätigkeitsaufnahme, spätestens jedoch vor der Aufnahme des Produktivbetriebs für den Kunden, wirkt über das Ende des Beschäftigungsverhältnisses hinaus und wird dokumentiert. vdw legt dem Kunden die Verpflichtungserklärungen auf Verlangen als Nachweis nach § 9 vor.
(2) Datengeheimnis. Die Verpflichtung umfasst das Verbot, personenbezogene Daten unbefugt zu verarbeiten, sowie die Belehrung über § 42 BDSG und Art. 83 DSGVO.
(3) Schulung. vdw schult die mit der Verarbeitung befassten Personen bei Aufnahme der Tätigkeit und danach mindestens jährlich zu Datenschutz und Datensicherheit. Die Teilnahme wird dokumentiert.
○ Stand 07.08.2026: Vertraulichkeitsverpflichtungen und Schulungsnachweise für die vdw-Beschäftigten liegen noch nicht in dokumentierter Form vor (Anlage 2 Nr. 4.1.4 und 4.1.5). Die Absätze 1 und 3 beschreiben insoweit eine zu erfüllende Pflicht, nicht einen bestehenden Zustand. Sie ist vor der Aufnahme des Produktivbetriebs für den ersten Kunden herzustellen; § 6 Absatz 5 gilt entsprechend.
(4) Kreis der Zugriffsberechtigten. Zugriff auf Kundendaten erhalten ausschließlich Personen, die ihn zur Erfüllung der vertraglichen Leistung benötigen. vdw führt eine dokumentierte Liste dieser Personen und aktualisiert sie bei jeder Änderung.
(5) Kein anlassloser Zugriff. vdw greift nicht ohne Anlass auf Inhalte des Kunden zu. Ein Support-Zugriff erfolgt ausschließlich nach vorheriger Freischaltung durch den Kunden, ist auf den Anlass und die Dauer der Unterstützung beschränkt und wird von vdw dokumentiert. Diese Beschränkung gilt ab Vertragsschluss als vertragliche und organisatorische Pflicht von vdw.
(6) Technische Umsetzung des Absatzes 5. Die technische Absicherung dieser Pflicht (gesonderte Rolle vdw_support, Freischaltung durch den Kunden in der Anwendung, automatische zeitliche Befristung, vollständige Protokollierung und Anzeige jeder Support-Aktion im Mandanten) ist in Anlage 2 Nr. 1.3.6 als kritisch gekennzeichnet und trägt den Stand ○ geplant, Stand 07.08.2026. Sie ist bis zur Aufnahme des Produktivbetriebs herzustellen (§ 6 Absatz 5) und ist bis dahin nicht Gegenstand einer Zusicherung. Die Pflicht aus Absatz 5 bleibt davon unberührt.
§ 6 Technische und organisatorische Maßnahmen (Art. 32 DSGVO)
(1) vdw trifft die zur Sicherheit der Verarbeitung erforderlichen technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO. Diese sind in Anlage 2 beschrieben.
(2) Kennzeichnung des Umsetzungsstands. Anlage 2 kennzeichnet jede Maßnahme mit ihrem tatsächlichen Umsetzungsstand (✔ umgesetzt, ◑ teilweise umgesetzt, ○ geplant). Maßnahmen mit dem Stand ○ geplant sind nicht Gegenstand einer Zusicherung und begründen keinen Anspruch des Kunden, solange sie diesen Stand tragen. Der Kunde erkennt an, dass er den Umsetzungsstand vor Vertragsschluss zur Kenntnis genommen hat.
(3) Fortschreibung. vdw darf die Maßnahmen fortentwickeln, solange das vereinbarte Schutzniveau nicht unterschritten wird. Wesentliche Änderungen dokumentiert vdw und teilt sie dem Kunden nach § 2 Absatz 3 mit. Eine Absenkung des Schutzniveaus ist eine Änderung der Hauptversion nach § 2 Absatz 2 und bedarf der erneuten Annahme.
(4) Angemessenheit. Die Parteien sind sich einig, dass die Maßnahmen dem Stand der Technik, den Implementierungskosten und der Art, dem Umfang, den Umständen und den Zwecken der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen zu entsprechen haben. vdw überprüft die Angemessenheit mindestens jährlich sowie anlassbezogen bei wesentlichen Änderungen der Verarbeitung.
(5) Umsetzungsstand als Vertragsvoraussetzung. vdw sichert zu, den Produktivbetrieb für einen Kunden erst aufzunehmen, wenn die in Anlage 2 als kritisch gekennzeichneten Maßnahmen den Stand ✔ umgesetzt tragen. Dies betrifft insbesondere Mandantentrennung, Verschlüsselung im Transport und im Ruhezustand, Rollen- und Rechtekonzept, Ereignisprotokoll und Datensicherung mit erprobter Wiederherstellung.
(6) Freigabe des Produktivbetriebs. Die Annahme dieses Vertrags nach § 2 Absatz 1 allein schaltet einen Mandanten nicht produktiv. Zusätzlich zu den dort genannten Feldern setzt die Freischaltung eine dokumentierte, von beiden Geschäftsführern der vdw GmbH gegengezeichnete Bestätigung voraus, dass die Voraussetzung des Absatzes 5 im Zeitpunkt der Freischaltung vorliegt. Die Bestätigung wird mit dem Prüfdatum und dem zugrunde liegenden Stand der Anlage 2 aufbewahrt und dem Kunden auf Verlangen vorgelegt.
§ 7 Unterstützung des Verantwortlichen
7.1 Betroffenenrechte (Art. 28 Abs. 3 lit. e DSGVO)
(1) vdw unterstützt den Kunden mit geeigneten technischen und organisatorischen Maßnahmen dabei, seiner Pflicht zur Beantwortung von Anträgen auf Wahrnehmung der Rechte der betroffenen Person nach Kapitel III der DSGVO nachzukommen, insbesondere Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Einschränkung (Art. 18), Datenübertragbarkeit (Art. 20) und Widerspruch (Art. 21).
(2) Selbstbedienung: Zielzustand, derzeit keine Zusicherung. Die Unterstützung soll vorrangig über Funktionen der Anwendung erfolgen, die der Mandantenadministrator des Kunden selbst bedient:
| Funktion | Ausgabe | Stand 07.08.2026 |
|---|---|---|
| „Alle Daten zu Mitarbeiter X“ | PDF (lesbare Auskunft nach Art. 15) und JSON (maschinenlesbar nach Art. 20) | ○ geplant |
| Berichtigung | direkte Bearbeitung der Stammdaten mit Protokollierung | ◑ teilweise: Bearbeitung möglich, serverseitige Protokollierung ○ geplant |
| Löschung und Pseudonymisierung | siehe § 11 und das Löschkonzept (Dokument 15) | ○ geplant |
| Einschränkung | Statuswechsel auf gesperrt mit Sperrvermerk | ◑ teilweise |
○ Stand 07.08.2026: Export-, Auskunfts- und Pseudonymisierungsfunktionen sind in ARCHITEKTUR.md §12.4 vorgesehen und noch nicht gebaut. Sie sind bis zu ihrer Fertigstellung nicht Gegenstand einer Zusicherung; § 6 Absatz 2 gilt entsprechend.
(2a) Unterstützung bis zur Fertigstellung dieser Funktionen. Solange die Funktionen nach Absatz 2 nicht zur Verfügung stehen, unterstützt vdw den Kunden bei Anträgen betroffener Personen manuell: durch Zusammenstellung der zu einer Person gespeicherten Daten, durch Berichtigung, Einschränkung oder Löschung auf Weisung des Kunden und durch Erstellung der erforderlichen Auszüge. Die Unterstützung erfolgt so rechtzeitig, dass der Kunde die Frist des Art. 12 Abs. 3 DSGVO einhalten kann, und ist insoweit unentgeltlich (§ 4 Absatz 6 letzter Satz).
(3) Anträge, die bei vdw eingehen. Wendet sich eine betroffene Person unmittelbar an vdw, leitet vdw den Antrag unverzüglich, spätestens innerhalb von drei Werktagen, an den Kunden weiter und beantwortet ihn nicht selbst. vdw teilt der betroffenen Person lediglich mit, dass die Weiterleitung erfolgt ist und wer Verantwortlicher ist.
(4) Aufwand. Unterstützungsleistungen, die über die Bereitstellung der Selbstbedienungsfunktionen hinausgehen, vergütet der Kunde nach § 4 Absatz 6, es sei denn, der Aufwand beruht auf einem Umstand, den vdw zu vertreten hat.
7.2 Unterstützung bei den Pflichten aus Art. 32 bis 36 DSGVO
vdw unterstützt den Kunden unter Berücksichtigung der Art der Verarbeitung und der vdw zur Verfügung stehenden Informationen bei der Einhaltung der Pflichten aus
| Norm | Unterstützungsleistung von vdw |
|---|---|
| Art. 32: Sicherheit der Verarbeitung | Bereitstellung von Anlage 2 in jeweils aktueller Fassung; Auskunft zu Sicherheitsmaßnahmen; Vorlage von Prüfberichten Dritter, soweit vorhanden |
| Art. 33: Meldung von Verletzungen an die Aufsichtsbehörde | Meldung an den Kunden nach § 10; Bereitstellung aller Informationen nach Art. 33 Abs. 3 DSGVO, soweit vdw sie besitzt |
| Art. 34: Benachrichtigung der betroffenen Personen | Zusammenstellung der Betroffenenkreise und der betroffenen Datenarten; technische Unterstützung bei der Benachrichtigung |
| Art. 35: Datenschutz-Folgenabschätzung | Bereitstellung der Systembeschreibung (Anlage 1 und 2), Beschreibung der Verarbeitungsvorgänge, Risikobetrachtung aus Sicht des Auftragsverarbeiters |
| Art. 36: vorherige Konsultation | Zulieferung der Informationen, die der Kunde für die Konsultation benötigt |
7.3 Mitbestimmung
vdw weist darauf hin, dass die Erfassung personenbezogener Zeitbuchungen und deren Auswertung nach § 87 Abs. 1 Nr. 6 BetrVG der Mitbestimmung des Betriebsrats unterliegen kann.
Kein technischer Schalter im Auslieferungszustand. ○ Stand 07.08.2026: ein Merkmalsschalter, der personenbezogene Auswertungen im Auslieferungszustand abschaltet und dessen Freischaltung protokolliert, ist in ARCHITEKTUR.md R-12 und in Anlage 2 Nr. 1.5.5 vorgesehen und noch nicht gebaut. vdw sichert einen solchen Auslieferungszustand daher nicht zu. vdw teilt dem Kunden auf Anfrage mit, welche personenbezogenen Auswertungen der jeweils eingesetzte Programmstand tatsächlich zulässt; diese Auskunft ist Grundlage der Beteiligung des Betriebsrats.
Der Kunde entscheidet als Verantwortlicher, wer personenbezogene Auswertungen vornehmen darf, und regelt dies erforderlichenfalls mit dem Betriebsrat. Sobald der Schalter zur Verfügung steht, gilt: Auswertungen erfolgen standardmäßig aggregiert, die Freischaltung ist eine Entscheidung des Kunden und wird protokolliert.
§ 8 Unterauftragsverarbeiter (Art. 28 Abs. 2 und 4 DSGVO)
(1) Allgemeine Genehmigung. Der Kunde erteilt vdw die allgemeine schriftliche Genehmigung, weitere Auftragsverarbeiter hinzuzuziehen (Art. 28 Abs. 2 Satz 2 DSGVO). Die zum Zeitpunkt des Vertragsschlusses eingesetzten Unterauftragsverarbeiter sind in Anlage 3 abschließend aufgeführt und mit der Annahme dieses Vertrags genehmigt.
(2) Keine Unterauftragsverarbeitung sind Nebenleistungen, die vdw bei Dritten als reine Nebenleistung in Anspruch nimmt und die nicht auf die Verarbeitung von Kundendaten gerichtet sind, insbesondere Telekommunikationsleistungen, Postdienste, Transport, Wartung von Hardware ohne Datenzugriff und Reinigung. vdw stellt auch für diese Leistungen den Schutz der Daten durch angemessene Maßnahmen sicher.
(3) Anforderungen an Unterauftragsverarbeiter. vdw schließt mit jedem Unterauftragsverarbeiter einen Vertrag, der ihm dieselben Datenschutzpflichten auferlegt, die vdw nach diesem Vertrag treffen, insbesondere hinreichende Garantien für geeignete technische und organisatorische Maßnahmen (Art. 28 Abs. 4 DSGVO). vdw prüft die Eignung vor der Beauftragung und danach mindestens jährlich und dokumentiert die Prüfung.
(4) Ankündigung von Änderungen. vdw teilt dem Kunden jede beabsichtigte Änderung in Bezug auf die Hinzuziehung oder die Ersetzung eines Unterauftragsverarbeiters mindestens 30 Tage vor deren Wirksamwerden in Textform mit. Die Mitteilung nennt Name, Anschrift, Leistung, Ort der Verarbeitung und (bei einem Drittlandbezug) die Rechtsgrundlage der Übermittlung. Die jeweils gültige Liste ist zusätzlich in der Anwendung einsehbar.
(5) Widerspruchsrecht. Der Kunde kann einer Änderung innerhalb von 30 Tagen ab Zugang der Mitteilung aus einem sachlichen, datenschutzbezogenen Grund in Textform widersprechen. Der Widerspruch ist zu begründen. Die Parteien suchen zunächst eine einvernehmliche Lösung. Kommt binnen weiterer 30 Tage keine Einigung zustande, kann der Kunde den Hauptvertrag mit einer Frist von einem Monat zum Monatsende außerordentlich kündigen; bereits gezahlte Entgelte werden zeitanteilig erstattet. Ein Widerspruch ohne sachlichen Grund oder ein nicht begründeter Widerspruch gilt als nicht erfolgt.
(6) Dringende Ersetzung. Muss ein Unterauftragsverarbeiter aus zwingendem Grund kurzfristig ersetzt werden (Ausfall, Insolvenz, Sicherheitsvorfall, Kündigung durch den Unterauftragsverarbeiter), darf vdw die Ersetzung ohne Einhaltung der Frist aus Absatz 4 vornehmen. vdw unterrichtet den Kunden unverzüglich; das Widerspruchsrecht nach Absatz 5 besteht dann nachträglich.
(7) Haftung. Kommt ein Unterauftragsverarbeiter seinen Datenschutzpflichten nicht nach, haftet vdw gegenüber dem Kunden für die Einhaltung der Pflichten dieses Unterauftragsverarbeiters (Art. 28 Abs. 4 Satz 2 DSGVO).
(8) Ort der Verarbeitung und Drittlandbezug. Beides ist auseinanderzuhalten. Der Ort der Verarbeitung liegt bei allen in Anlage 3 aufgeführten Unterauftragsverarbeitern innerhalb der EU beziehungsweise des EWR; eine Verarbeitung außerhalb der EU beziehungsweise des EWR ist derzeit nicht vorgesehen. Ein Drittlandbezug kann gleichwohl bestehen, wenn ein Unterauftragsverarbeiter seinen Sitz in einem Drittland hat, dem Recht dieses Drittlands unterliegt oder von dort auf die Daten zugreifen kann. Anlage 3 weist einen solchen Drittlandbezug für jeden Unterauftragsverarbeiter gesondert aus und benennt die Rechtsgrundlage der Übermittlung. Sowohl eine Verlagerung des Verarbeitungsorts in ein Drittland als auch die Hinzuziehung eines Unterauftragsverarbeiters mit Drittlandbezug setzen einen Angemessenheitsbeschluss nach Art. 45 DSGVO oder geeignete Garantien nach Art. 46 DSGVO (insbesondere Standardvertragsklauseln nebst Übermittlungs-Folgenabschätzung) sowie die vorherige Mitteilung nach Absatz 4 voraus.
§ 9 Nachweis- und Kontrollrechte, Audits (Art. 28 Abs. 3 lit. h DSGVO)
(1) Nachweispflicht. vdw stellt dem Kunden alle Informationen zur Verfügung, die zum Nachweis der Einhaltung der in Art. 28 DSGVO niedergelegten Pflichten erforderlich sind.
(2) Nachweisstufen. Der Nachweis erfolgt vorrangig durch:
a) die jeweils aktuelle Fassung von Anlage 2 mit gekennzeichnetem Umsetzungsstand, b) Selbstauskunft von vdw auf einen schriftlichen Fragenkatalog des Kunden, zu beantworten binnen vier Wochen, c) Berichte anerkannter Dritter (Prüfberichte, Zertifikate, Berichte über Penetrationstests), soweit vorhanden, d) Nachweise über Zertifizierungen der Unterauftragsverarbeiter (insbesondere ISO/IEC 27001, C5-Testat des Hostinganbieters).
○ geplant, Stand 07.08.2026: vdw selbst verfügt über keine Zertifizierung nach ISO/IEC 27001 oder vergleichbaren Normen und plant derzeit keine. Ein Penetrationstest mit Schwerpunkt Mandantenisolation und QR-Portal ist vor dem zweiten Produktivmandanten vorgesehen und noch nicht durchgeführt.
(3) Vor-Ort-Prüfung. Reichen die Nachweise nach Absatz 2 nicht aus, ist der Kunde berechtigt, Überprüfungen (einschließlich Inspektionen) selbst oder durch einen von ihm beauftragten Prüfer durchzuführen. Es gilt:
| Punkt | Regelung |
|---|---|
| Häufigkeit | einmal je Kalenderjahr; darüber hinaus anlassbezogen bei einer Verletzung des Schutzes personenbezogener Daten oder auf Anordnung einer Aufsichtsbehörde |
| Ankündigung | mindestens vier Wochen in Textform, anlassbezogen unverzüglich |
| Zeit | während der üblichen Geschäftszeiten |
| Ort | Geschäftsräume der vdw GmbH; eine Prüfung in Rechenzentren der Unterauftragsverarbeiter richtet sich nach deren Prüfkonzepten |
| Prüfer | kein Wettbewerber von vdw; vorherige Verpflichtung zur Vertraulichkeit |
| Beeinträchtigung | die Prüfung darf den Geschäftsbetrieb nicht unangemessen beeinträchtigen; Einsicht in Daten anderer Kunden ist ausgeschlossen |
| Ergebnis | der Kunde stellt vdw das Prüfergebnis zur Verfügung; vdw beseitigt festgestellte Mängel unverzüglich |
(4) Kosten. Jede Partei trägt die ihr entstehenden Kosten selbst. Für Vor-Ort-Prüfungen ab der zweiten Prüfung innerhalb eines Kalenderjahres kann vdw den eigenen Aufwand mit 150,00 € netto je angefangener Stunde in Rechnung stellen; das gilt nicht, wenn die Prüfung durch einen von vdw zu vertretenden Umstand veranlasst ist oder wenn sie einen Mangel feststellt. Auskünfte, die Bereitstellung von Nachweisen und die erste Vor-Ort-Prüfung im Kalenderjahr sind stets unentgeltlich.
(5) Aufsichtsbehörden. vdw duldet Kontrollen der zuständigen Aufsichtsbehörden und wirkt daran mit. vdw unterrichtet den Kunden unverzüglich über aufsichtsbehördliche Maßnahmen, die die Verarbeitung im Auftrag des Kunden betreffen.
(6) Eigene Überprüfung. vdw überprüft die Wirksamkeit der technischen und organisatorischen Maßnahmen regelmäßig nach Anlage 2 Abschnitt 4 und dokumentiert das Ergebnis.
§ 10 Meldung von Verletzungen des Schutzes personenbezogener Daten
(1) Meldung an den Kunden. vdw meldet dem Kunden jede Verletzung des Schutzes personenbezogener Daten (Art. 4 Nr. 12 DSGVO), die im Verantwortungsbereich von vdw oder eines Unterauftragsverarbeiters eintritt, unverzüglich nach Bekanntwerden, in der Regel binnen 24 Stunden, an Wochenenden und gesetzlichen Feiertagen am Sitz von vdw binnen 48 Stunden (Art. 33 Abs. 2 DSGVO).
Warum diese Fassung. Art. 33 Abs. 2 DSGVO verlangt die Meldung „unverzüglich“ und nennt keine Frist. Die vdw GmbH unterhält keine Rufbereitschaft; eine starre Zusage von 24 Stunden wäre an einem Wochenende nicht sicher zu halten. Eine zugesagte und nicht gehaltene Frist ist schlechter als eine ehrlich längere. Die Regelfrist von 24 Stunden bleibt der Maßstab, an dem sich vdw messen lässt, und sichert dem Kunden den überwiegenden Teil seiner eigenen 72-Stunden-Frist. Richtet vdw eine Rufbereitschaft ein, wird die Wochenendregelung durch Änderung der Nebenversion nach § 2 Absatz 2 gestrichen.
(2) Inhalt der Meldung. Die Meldung erfolgt an den in Anlage 1 Abschnitt 8 benannten Ansprechpartner des Kunden per E-Mail und zusätzlich telefonisch und enthält, soweit bekannt:
a) eine Beschreibung der Art der Verletzung, soweit möglich mit Angabe der Kategorien und der ungefähren Zahl der betroffenen Personen und der betroffenen Datensätze, b) Zeitpunkt des Eintritts und der Entdeckung, c) Namen und Kontaktdaten der Auskunftsstelle bei vdw, d) eine Beschreibung der wahrscheinlichen Folgen, e) eine Beschreibung der ergriffenen und vorgeschlagenen Maßnahmen zur Behebung und zur Abmilderung möglicher nachteiliger Auswirkungen.
Sind nicht alle Angaben verfügbar, meldet vdw zunächst den bekannten Sachverhalt und ergänzt schrittweise, ohne dass sich die Erstmeldung verzögert.
(3) Keine eigene Meldung an die Aufsichtsbehörde. Die Meldung an die Aufsichtsbehörde nach Art. 33 Abs. 1 DSGVO und die Benachrichtigung der betroffenen Personen nach Art. 34 DSGVO obliegen ausschließlich dem Kunden als Verantwortlichem. vdw nimmt eine solche Meldung nicht vor und gibt keine Einschätzung darüber ab, ob eine Meldepflicht des Kunden besteht. Unberührt bleiben Meldepflichten von vdw für Verarbeitungen in eigener Verantwortlichkeit.
(4) Unterstützung. vdw unterstützt den Kunden bei Aufklärung, Bewertung, Eindämmung und Dokumentation. vdw ergreift unverzüglich die erforderlichen Sicherungsmaßnahmen.
(5) Dokumentation. vdw dokumentiert alle Verletzungen einschließlich der damit verbundenen Fakten, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen. Der Ablauf ist im Dokument 16_Meldeprozess-Datenschutzvorfall.md geregelt.
(6) Verdachtsfälle. vdw meldet auch begründete Verdachtsfälle, wenn eine Verletzung nicht ausgeschlossen werden kann. Ein Bruch der Mandantentrennung gilt stets als meldepflichtiger Vorfall.
§ 11 Löschung und Rückgabe nach Beendigung (Art. 28 Abs. 3 lit. g DSGVO)
(1) Wahlrecht des Kunden. Nach Abschluss der Erbringung der Verarbeitungsleistungen löscht vdw nach Wahl des Kunden alle personenbezogenen Daten oder gibt sie zurück und löscht vorhandene Kopien, sofern nicht nach dem Recht der Union oder der Mitgliedstaaten eine Verpflichtung zur Speicherung besteht.
(2) Karenzzeit und Export. Nach Beendigung des Hauptvertrags gilt:
| Frist ab Vertragsende | Vorgang |
|---|---|
| Tag 0 | Der Mandant wird auf gekuendigt gesetzt; schreibende Zugriffe werden gesperrt, lesende Zugriffe und der Export bleiben möglich |
| Tag 0 bis 30 | Karenzzeit. Der Kunde exportiert seine Daten selbst über die Exportfunktion (strukturiertes, gängiges, maschinenlesbares Format sowie Dokumente im Original) |
| Tag 30 | Vollständige Löschung aller Daten des Mandanten einschließlich der Dokumente im Objektspeicher |
| Tag 30 + 5 Werktage | vdw übermittelt dem Kunden ein Löschprotokoll mit Datum, Umfang und ausführender Stelle |
| Tag 30 bis 65 | Auslauf der Sicherungsstände nach Absatz 4 |
(3) Verlängerung. Auf schriftlichen Wunsch des Kunden verlängert vdw die Karenzzeit einmalig um bis zu 30 Tage. Für den Zeitraum der Verlängerung fällt das vertraglich vereinbarte Entgelt anteilig an.
(4) Sicherungen. Daten in Datensicherungen werden nicht gesondert gelöscht, sondern laufen mit dem Sicherungsstand aus. Der letzte Sicherungsstand, der Daten des Kunden enthält, verfällt spätestens 35 Tage nach der Löschung nach Absatz 2. Bis dahin bleiben die Daten in den Sicherungen gesperrt und werden ausschließlich zur Wiederherstellung im Notfall verwendet.
(5) Rückgabeformat. Die Rückgabe erfolgt als strukturierter Export (JSON und CSV) zuzüglich der hinterlegten Dokumente im Originalformat sowie der Prüfprotokolle als PDF. Ein Export in ein bestimmtes Fremdsystem schuldet vdw nicht.
(6) Gesetzliche Aufbewahrungspflichten von vdw. Soweit vdw selbst gesetzlichen Aufbewahrungspflichten unterliegt (insbesondere für Rechnungen und Buchungsbelege nach § 147 AO und § 257 HGB), bleiben die betreffenden Daten von der Löschung ausgenommen. Sie werden in der Verarbeitung eingeschränkt und ausschließlich zu Nachweiszwecken vorgehalten. Diese Daten verarbeitet vdw als eigener Verantwortlicher, nicht im Auftrag.
(7) Kein Zurückbehaltungsrecht. vdw übt an den Daten des Kunden kein Zurückbehaltungsrecht aus, auch nicht wegen offener Forderungen.
§ 12 Datenschutzbeauftragter und Ansprechpartner
(1) vdw. vdw hat keinen Datenschutzbeauftragten bestellt. Die vdw GmbH beschäftigt rund fünf Personen; eine Bestellpflicht nach § 38 Abs. 1 Satz 1 BDSG (in der Regel mindestens 20 mit der automatisierten Verarbeitung ständig beschäftigte Personen) besteht damit nicht. Eine freiwillige Bestellung ist zur Aufnahme des Serverbetriebs vorgesehen; sie wird dem Kunden nach § 2 Absatz 3 mitgeteilt.
(2) Kontakt für Datenschutzfragen bei vdw:
Olaf von Deines, Geschäftsführer
vdw GmbH, Fichtenstr. 49, 57368 Lennestadt
Telefon 02723/719334 · datenschutz@v-d-w.de (einzurichten vor dem ersten Vertragsschluss; bis dahin info@v-d-w.de)
(3) Kunde. Der Kunde benennt in Anlage 1 Abschnitt 8 seinen Ansprechpartner und, sofern vorhanden, seinen Datenschutzbeauftragten. Änderungen teilt er vdw unverzüglich mit.
§ 13 Haftung
(1) Gesetzliche Haftung. Für die Haftung gegenüber betroffenen Personen gilt Art. 82 DSGVO. Die Parteien haften danach gesamtschuldnerisch, soweit sie für denselben Schaden verantwortlich sind. Im Innenverhältnis trägt jede Partei den Anteil, der ihrem Verantwortungsbeitrag entspricht (Art. 82 Abs. 5 DSGVO).
(2) Verantwortungsbereiche. Der Kunde ist verantwortlich für die Rechtmäßigkeit der Verarbeitung, insbesondere für die Rechtsgrundlage, die Erforderlichkeit der eingegebenen Daten, die Information der betroffenen Personen, die Beteiligung des Betriebsrats und die Vergabe der Rollen und Rechte in der Anwendung. vdw ist verantwortlich für die Einhaltung dieses Vertrags, insbesondere für die Weisungsbindung, die Maßnahmen nach Anlage 2 und die Auswahl und Überwachung der Unterauftragsverarbeiter.
(3) Freistellung. Wird eine Partei von einer betroffenen Person oder einer Aufsichtsbehörde für einen Umstand in Anspruch genommen, den die andere Partei zu vertreten hat, stellt diese sie im Innenverhältnis frei. Die in Anspruch genommene Partei unterrichtet die andere unverzüglich und gibt ihr Gelegenheit zur Stellungnahme, bevor sie einen Anspruch anerkennt oder befriedigt.
(4) Haftungsbegrenzung. Im Übrigen gelten die Haftungsregelungen des Hauptvertrags.
§ 14 Schlussbestimmungen
(1) Schriftform. Änderungen und Ergänzungen dieses Vertrags bedürfen der Textform. Das gilt auch für die Aufhebung dieser Klausel. Unberührt bleibt das Verfahren nach § 2.
(2) Salvatorische Klausel. Sollte eine Bestimmung dieses Vertrags unwirksam sein oder werden, bleibt die Wirksamkeit der übrigen Bestimmungen unberührt. Die Parteien ersetzen die unwirksame Bestimmung durch eine wirksame, die dem wirtschaftlichen und datenschutzrechtlichen Zweck am nächsten kommt.
(3) Anwendbares Recht. Es gilt das Recht der Bundesrepublik Deutschland unter Ausschluss des UN-Kaufrechts.
(4) Gerichtsstand. Ausschließlicher Gerichtsstand ist Siegen, soweit der Kunde Kaufmann, juristische Person des öffentlichen Rechts oder öffentlich-rechtliches Sondervermögen ist.
(5) Anlagen. Bestandteil dieses Vertrags sind:
| Anlage | Titel | Dokument |
|---|---|---|
| 1 | Verarbeitungsübersicht: Zwecke, Datenarten, betroffene Personen, Ort, Löschfristen | 11_Anlage-1-Verarbeitungsuebersicht.md |
| 2 | Technische und organisatorische Maßnahmen nach Art. 32 DSGVO | 12_Anlage-2-TOM.md |
| 3 | Unterauftragsverarbeiter | 13_Anlage-3-Unterauftragsverarbeiter.md |
Unterschriften
Dieser Vertrag wird entweder elektronisch in der Anwendung angenommen (§ 2 Absatz 1) oder von beiden Parteien unterzeichnet. Bei elektronischer Annahme ersetzt der Nachweis aus mandant.avv_version, avv_akzeptiert_am und avv_akzeptiert_von die Unterschrift des Kunden.
Für den Verantwortlichen (Kunde)
Ort, Datum
Unterschrift
Name: ____________________________ Funktion: ____________________________
Für den Auftragsverarbeiter (vdw GmbH)
Lennestadt, Datum
Unterschrift
Name: Olaf von Deines Funktion: Geschäftsführer
Änderungsverzeichnis
| Version | Datum | Änderung | Bearbeiter |
|---|---|---|---|
| 1.2 | 30.08.2026 | Vorbemerkung zum Entwicklungsstand auf die Anmeldepflicht ab dem 30.08.2026 umgestellt; Anlagen 1 bis 3 auf Fassung 1.2 fortgeschrieben. Der Vertragstext selbst ist unverändert | vdw GmbH |
| 1.1 | 15.08.2026 | Serverbetrieb aufgenommen: Supabase Pte. Ltd. als Unterauftragsverarbeiter in Anlage 3, Drittlandbezug ausgewiesen, Vorbemerkung auf den tatsächlichen Stand umgestellt | vdw GmbH |
| 1.0-Entwurf | 07.08.2026 | Ersterstellung als Arbeitsgrundlage für die anwaltliche Prüfung | vdw GmbH |
Änderungsprotokoll
| Datum | Geänderte Abschnitte | Behobener Befund |
|---|---|---|
| 07.08.2026 | Neuer, abgesetzter Kasten vor der Vorbemerkung: Empfehlung, statt dieses Vertrags die EU-Standardvertragsklauseln nach Durchführungsbeschluss (EU) 2021/915 zu verwenden, mit Zuordnung der Anhänge I bis III zu den Anlagen 1 bis 3 und Benennung der Regelungen, die als ergänzende Vereinbarung erhalten bleiben | Abschnitt 5.2 des Prüfberichts, Maßnahme 6 |
| 07.08.2026 | Vertragsparteien: Kundenangaben von Platzhaltern auf Ausfüllfelder umgestellt; das Dokument ist damit ohne Kundendaten vollständig | B-06 (analog Anlage 1) |
| 07.08.2026 | § 3 Absatz 3: Präsensaussage zur Erfassung ohne Dokument entschärft; ausdrücklich klargestellt, dass eine technische Sperre nicht zugesichert wird, dazu Pflicht zur gegengezeichneten Belehrung des Kunden | B-02, B-05 |
| 07.08.2026 | § 4 Absätze 3, 4 und 6 sowie § 12: offene Platzhalter durch Festlegungen ersetzt (Weisungspostfach, weisungsempfangende Stelle, Zwei-Stunden-Schwelle, kein Datenschutzbeauftragter bestellt) | redaktionell, Vollständigkeit ohne Kundendaten |
| 07.08.2026 | § 5 Absatz 1 und 3: Zusicherung im Präsens („stellt sicher, dass … verpflichtet haben“) in eine zu erfüllende Pflicht mit Zeitpunkt umformuliert; fehlende Dokumentation ausdrücklich benannt | B-02, B-15 |
| 07.08.2026 | § 5 Absatz 5: technische Merkmale des Support-Zugriffs aus der Zusage herausgelöst; neuer Absatz 6 kennzeichnet die technische Umsetzung als geplant und nicht zugesichert | B-02 |
| 07.08.2026 | § 6, neuer Absatz 6: Freischaltung eines Mandanten nur mit gegengezeichneter Bestätigung beider Geschäftsführer über den Stand der kritischen Maßnahmen | B-04 |
| 07.08.2026 | § 7.1 Absatz 2: Selbstbedienungsfunktionen als Zielzustand mit Umsetzungsstand gekennzeichnet; neuer Absatz 2a regelt die manuelle Unterstützung bis zu ihrer Fertigstellung | B-02 |
| 07.08.2026 | § 7.3: Zusage „personenbezogene Auswertungen im Auslieferungszustand abgeschaltet“ gestrichen; Auskunftspflicht über den tatsächlichen Programmstand aufgenommen | B-02 |
| 07.08.2026 | § 10 Absatz 1: 24-Stunden-Zusage ersetzt durch „unverzüglich, in der Regel binnen 24 Stunden, an Wochenenden und gesetzlichen Feiertagen binnen 48 Stunden“; Prüfpunkt entfernt und durch die Begründung ersetzt | B-07 |
| 23.08.2026 | § 8 Absatz 8: Ort der Verarbeitung und Drittlandbezug ausdrücklich unterschieden, damit der Absatz mit Anlage 3 zusammenpasst; Kopfzeile auf den 23.08.2026 fortgeschrieben; Gedankenstriche aufgelöst und Anführungszeichen vereinheitlicht | Widerspruch zu Anlage 3 (Drittlandbezug), Redaktion |
| 30.08.2026 | Vorbemerkung zum Entwicklungsstand: die Angabe, ohne Kundenkonto bleibe es beim bisherigen Zustand, sämtliche Daten lägen im lokalen Speicher, es finde keine Übermittlung statt und dieser Vertrag sei für solche Kunden gegenstandslos, ist gestrichen und durch den Stand seit dem 30.08.2026 ersetzt: Die Anwendung ist nur nach Anmeldung nutzbar; ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code. Kopfzeile und Dokumentfassung fortgeschrieben. Kein Paragraph des Vertragstextes geändert | Entscheidung der Geschäftsführung vom 30.08.2026: Die Anwendung ist nur nach Anmeldung nutzbar |
08.08.2026: Besetzung der offenen Entscheidungen
| § | Entscheidung | Begründung |
|---|---|---|
| § 8 Abs. 4 | Auskünfte, Nachweise und die erste Vor-Ort-Prüfung im Kalenderjahr bleiben unentgeltlich. Ab der zweiten Vor-Ort-Prüfung im Kalenderjahr kann vdw den eigenen Aufwand mit 150,00 € netto je angefangener Stunde berechnen, nicht jedoch, wenn vdw die Prüfung zu vertreten hat oder wenn sie einen Mangel feststellt | Art. 28 Abs. 3 lit. h DSGVO verlangt, Überprüfungen zu ermöglichen und dazu beizutragen; eine Kostenregel darf das Recht nicht faktisch entwerten. Die erste Prüfung bleibt deshalb frei. Die Rückausnahme bei festgestelltem Mangel verhindert, dass der Kunde für die Aufdeckung eines Fehlers von vdw zahlt. Genau daran scheitern solche Klauseln sonst |
| § 14 Abs. 4 | Gerichtsstand Siegen, soweit der Kunde Kaufmann, juristische Person des öffentlichen Rechts oder öffentlich-rechtliches Sondervermögen ist | Sitz des Registergerichts der vdw GmbH; gleichlautend mit § 23 Abs. 4 der AGB, damit Hauptvertrag und Auftragsverarbeitungsvertrag nicht auseinanderlaufen |
Anlage 1: Verarbeitungsübersicht
Gegenstand, Art und Zweck der Verarbeitung · Datenarten · Kategorien betroffener Personen · Ort der Verarbeitung · Löschfristen Produkt: Instandio · Auftragsverarbeiter: vdw GmbH
Fassung: 1.2 · Stand 30.08.2026 · Anlage zum Auftragsverarbeitungsvertrag
1. Gegenstand und Art der Verarbeitung
Gegenstand. Betrieb der Software Instandio als von der vdw GmbH bereitgestellte Anwendung (Software as a Service) für den Kunden. Instandio unterstützt den Kunden bei der Erfüllung seiner Betreiberpflichten für technische Arbeitsmittel und Anlagen: Prüffristenüberwachung, Dokumentation von Prüfungen, Mängeln und Maßnahmen, Wartungs- und Instandhaltungsaufträge, Schadensmeldungen aus dem Betrieb, Nachweis der Befähigung prüfender Personen und Nachweisführung gegenüber Berufsgenossenschaft und Behörden.
Verantwortung für die Prüffristen bleibt beim Kunden. Welche Prüfungen an welchen Arbeitsmitteln in welchem Abstand erforderlich sind, bestimmt der Kunde als Betreiber auf Grundlage seiner Gefährdungsbeurteilung und der für ihn geltenden Vorschriften. Die von Instandio angezeigten Fristen sind Vorschläge ohne Rechtsverbindlichkeit; sie ersetzen weder die eigene Festlegung noch die eigene Prüfung des Kunden und begründen keine Rechtssicherheit. vdw schuldet insoweit den Betrieb der Anwendung, nicht die Richtigkeit einer Fristenaussage im Einzelfall. Zweck der Verarbeitung ist entsprechend die Unterstützung der Betreiberpflichten des Kunden, nicht deren Übernahme.
Art der Verarbeitung. Erheben, Erfassen, Organisieren, Ordnen, Speichern, Anpassen, Verändern, Auslesen, Abfragen, Verwenden, Offenlegen durch Übermittlung innerhalb des Systems, Abgleichen, Verknüpfen, Einschränken, Löschen und Vernichten, jeweils automatisiert im Rahmen des Anwendungsbetriebs.
Verarbeitungsvorgänge im Einzelnen:
| Nr. | Vorgang | Auslöser |
|---|---|---|
| V1 | Anlegen und Pflegen von Nutzerkonten, Rollen und Geltungsbereichen | Mandantenadministrator des Kunden |
| V2 | Anlegen und Pflegen des Mitarbeiterstamms | Personalstamm-Rolle des Kunden |
| V3 | Erfassen und Überwachen von Qualifikationsnachweisen und Befähigungen | Personalstamm-Rolle des Kunden, nächtliche Neubewertung |
| V4 | Durchführen und Dokumentieren von Prüfungen mit Prüferzuordnung | prüfende Person des Kunden |
| V5 | Erfassen von Mängeln, Maßnahmen und Nachprüfungen mit Bearbeiterzuordnung | Beschäftigte des Kunden |
| V6 | Anlegen, Zuweisen und Rückmelden von Aufträgen | Beschäftigte des Kunden, Fremdfirmen |
| V7 | Erfassen von Zeitbuchungen und Materialverbrauch je Auftrag | Beschäftigte des Kunden, Fremdfirmen |
| V8 | Entgegennehmen von Schadens- und Störungsmeldungen über das QR-Portal | jede Person, die ein Etikett scannt, auch anonym |
| V9 | Verwalten von Fremdfirmen und deren Ansprechpartnern | Beschäftigte des Kunden |
| V10 | Erzeugen und Versenden von Benachrichtigungen und Eskalationen | nächtliche Läufe, Ereignisse |
| V11 | Erzeugen von Prüfprotokollen, Nachweismappen und Etiketten als PDF | Beschäftigte des Kunden |
| V12 | Führen des Ereignisprotokolls (audit_event). Der Begriff „revisionssicher“ wird für den derzeitigen Stand bewusst nicht verwendet, siehe Anlage 2 Abschnitt 2.2 | jede schreibende und ausgewählte lesende Aktion |
| V13 | Ablegen von Dokumenten und Fotos (Typenschilder, Handbücher, Mangelfotos, Nachweise) | Beschäftigte des Kunden, Melder über das QR-Portal |
| V14 | Auskunft und Datenübertragbarkeit als Selbstbedienungsfunktion | Mandantenadministrator des Kunden |
| V15 | Support-Zugriff durch vdw nach Freischaltung durch den Kunden | Kunde schaltet frei, vdw greift befristet zu |
| V16 | Datensicherung und Wiederherstellung | automatisiert |
2. Zweck der Verarbeitung
| Zweck | Fachlicher Hintergrund |
|---|---|
| Unterstützung des Kunden bei der Erfüllung seiner Betreiberpflichten. Die Pflichten selbst und die Festlegung der Prüffristen verbleiben beim Kunden | Betriebssicherheitsverordnung, Arbeitsschutzgesetz, DGUV-Vorschriften, Technische Regeln für Betriebssicherheit |
| Nachweisführung | Nachweis gegenüber Berufsgenossenschaft, Gewerbeaufsicht und im Haftungsfall, dass Prüfungen durchgeführt und Mängel abgestellt wurden |
| Befähigungsnachweis | Nachweis, dass Prüfungen durch befähigte Personen im Sinne der TRBS 1203 durchgeführt wurden |
| Arbeitsorganisation | Planung, Zuweisung und Rückmeldung von Instandhaltungs- und Prüfaufträgen |
| Kostenrechnung | Zuordnung von Arbeitszeit und Material zu Anlagen und Aufträgen |
| Arbeitssicherheit im laufenden Betrieb | Sperren von Arbeitsmitteln bei sicherheitskritischen Mängeln, Freigabeampel am QR-Portal |
| Informationssicherheit und Nachvollziehbarkeit | Ereignisprotokoll, Missbrauchsabwehr am öffentlich erreichbaren QR-Portal |
| Vertragserfüllung durch vdw | Bereitstellung, Betrieb, Wartung und Support der Anwendung |
Nicht Zweck der Verarbeitung sind: Leistungs- oder Verhaltenskontrolle von Beschäftigten, Profilbildung, Werbung, Weitergabe an Dritte zu deren Zwecken, Training von Modellen künstlicher Intelligenz mit Kundendaten.
3. Kategorien betroffener Personen
| Kat. | Kategorie | Beschreibung | Typische Größenordnung je Kunde |
|---|---|---|---|
| B1 | Beschäftigte des Kunden | Instandhalter, Prüfer, Meister, Bereichs- und Werksleitung, Verwaltung, Lagerpersonal, Personalabteilung, IT-Verantwortliche | 20 bis 1.700 |
| B2 | Beschäftigte des Kunden als Melder | Produktionsmitarbeiter, die über das QR-Portal Schäden und Störungen melden, mit oder ohne Namensangabe | potenziell die gesamte Belegschaft |
| B3 | Beschäftigte von Fremdfirmen | Monteure, Servicetechniker, Ansprechpartner beauftragter Unternehmen; Zugang über eigene Anmeldeklasse fremdfirma_extern | 5 bis 100 |
| B4 | Externe Prüfer und Sachverständige | Fachkräfte für Arbeitssicherheit, Sachverständige von TÜV, DEKRA und anderen; erscheinen als Prüfer in Protokollen oder als Aussteller von Nachweisen | 5 bis 30 |
| B5 | Auditoren und Prüfstellen | Berufsgenossenschaft, Gewerbeaufsicht, Wirtschaftsprüfer, interne Revision. Lesender Zugang über die Rolle auditor | 0 bis 10 |
| B6 | Melder über das QR-Portal ohne Beschäftigtenverhältnis | Besucher, Leiharbeitnehmer, Lieferantenpersonal auf dem Werksgelände | unbestimmt |
| B7 | Ansprechpartner bei Lieferanten | Kontaktdaten in der Materialwirtschaft und im Bestellwesen | 5 bis 50 |
| B8 | Mandantenadministratoren und Vertragsansprechpartner | Personen beim Kunden, die den Vertrag annehmen, Nutzer verwalten und Weisungen erteilen | 1 bis 5 |
4. Arten der verarbeiteten personenbezogenen Daten
4.1 Stammdaten
| Datenart | Felder | Betroffene | Rechtsgrundlage beim Kunden (typisch) |
|---|---|---|---|
| Nutzerkonto | Anzeigename, E-Mail, Telefon (optional), Anmeldeart, Entra-Objektkennung und UPN bei SSO, Status, letzter Anmeldezeitpunkt, bevorzugte Sprache | B1, B3, B5, B8 | Art. 6 Abs. 1 lit. b DSGVO |
| Mitarbeiterstamm | Vorname, Nachname, Personalnummer, Abteilung, Standort, Kostenstelle, Eintritts- und Austrittsdatum, E-Mail und Telefon (optional) | B1 | Art. 6 Abs. 1 lit. b und lit. c DSGVO |
| Organisationsbezug | Rollenzuweisungen mit Geltungsbereich und Gültigkeitszeitraum, Vorgesetztenbeziehung, Vertretungsregelung | B1 | Art. 6 Abs. 1 lit. b und f DSGVO |
| Fremdfirmen-Ansprechpartner | Anrede, Vorname, Nachname, Funktion, Telefon, Mobil, E-Mail, Zuständigkeit | B3 | Art. 6 Abs. 1 lit. b DSGVO |
| Lieferanten-Ansprechpartner | Name, Funktion, geschäftliche Kontaktdaten | B7 | Art. 6 Abs. 1 lit. b DSGVO |
Rechtsgrundlage im Beschäftigungsverhältnis. Diese Anlage nennt § 26 Abs. 1 BDSG nicht als Rechtsgrundlage. Der Europäische Gerichtshof hat mit Urteil vom 30.03.2023 (C-34/21) eine wortgleiche Landesnorm als nicht von der Öffnungsklausel des Art. 88 DSGVO gedeckt angesehen; die Bewertung wird auf § 26 Abs. 1 Satz 1 BDSG übertragen. Die Verarbeitungen werden von Art. 6 Abs. 1 lit. b und lit. c DSGVO ohnehin getragen. Besteht beim Kunden eine Betriebsvereinbarung, ist Art. 88 DSGVO die stärkere Grundlage. Die endgültige Zuordnung der Rechtsgrundlagen trifft der Kunde als Verantwortlicher.
Datensparsamkeit als Architekturentscheidung. Instandio erhebt kein Geburtsdatum, keine Privatanschrift, keine Bankverbindung, keine Personalakte und keine Lichtbilder von Beschäftigten. Was für Prüfnachweis, Zuweisung oder Kostenrechnung nicht gebraucht wird, wird nicht erhoben.
4.2 Qualifikations- und Befähigungsdaten
| Datenart | Felder | Betroffene |
|---|---|---|
| Qualifikationsnachweis | Bezeichnung der Qualifikation, Kategorie, Aussteller (z. B. TÜV, DEKRA, Berufsgenossenschaft, IHK), Ausstellungsdatum, Gültigkeitsdatum, Urkundennummer, Status, erfassende Person und Zeitpunkt | B1, B3, B4 |
| Nachweisdokument | eingescannte Schulungsbescheinigung, Sachkundenachweis, Bestellungsurkunde als Datei | B1, B3, B4 |
| Befähigungs-Schnappschuss | Zustand der Befähigung zum Zeitpunkt einer Prüfung, mitgeschrieben im Prüfprotokoll | B1, B4 |
| Unterbesetzungsdaten | Zuordnung von Personen zu Tätigkeiten, Ablaufdaten, Prognose der Unterschreitung einer Mindestbesetzung | B1 |
4.3 Vorgangs- und Tätigkeitsdaten
| Datenart | Felder mit Personenbezug | Betroffene |
|---|---|---|
| Prüfung | prüfende Person (Kennung, Anzeigename als Schnappschuss), Prüfdatum, Ergebnis, Befähigungsstand zum Prüfzeitpunkt, Freitextbemerkungen | B1, B4 |
| Mangel und Maßnahme | erfassende Person, bewertende Person, zugewiesene Person, erledigende Person, verifizierende Person, jeweils mit Zeitstempel; Freigabe- und Ablehnungsbegründungen | B1, B3 |
| Auftrag | anlegende, zuweisende, ausführende, abnehmende Person; zugewiesene Fremdfirma und Ansprechpartner; Übersteuerungsbegründung bei fehlender Befähigung | B1, B3 |
| Zeitbuchung | Person oder Fremdfirma, Datum, Dauer in Minuten, Leistungsart, Tätigkeitsbeschreibung, Zuschlagsart, erfassende Person | B1, B3 |
| Stundensatz | interner Stundensatz je Person oder Gruppe, historisiert | B1 |
| Arbeitsschrittergebnis | erledigende Person, Zeitpunkt, Messwert, Bemerkung, Foto | B1, B3 |
| Pflichtenübertragung | übertragende und empfangende Person, Umfang, Befugnis, Mittel, Gegenzeichnung (§ 13 Abs. 2 ArbSchG) | B1 |
| Gefährdungsbeurteilung | erstellende, freigebende und prüfende Person; Aushangnachweis der Betriebsanweisung | B1 |
Zeitbuchungen sind mitbestimmungsrelevant. Personenbezogene Zeitbuchungen und deren Auswertung können nach § 87 Abs. 1 Nr. 6 BetrVG der Mitbestimmung unterliegen. Vorgesehen ist ein Merkmalsschalter, der die personenbezogene Auswertung im Auslieferungszustand abschaltet. ○ Stand 07.08.2026: nicht gebaut; ein solcher Auslieferungszustand wird daher nicht zugesichert (siehe § 7.3 des Vertrags). Welche personenbezogenen Auswertungen der eingesetzte Programmstand tatsächlich zulässt, teilt vdw dem Kunden auf Anfrage mit.
4.4 Meldedaten aus dem QR-Portal
| Datenart | Felder | Betroffene |
|---|---|---|
| Schadensmeldung | Beschreibung, Schweregrad, bis zu drei Fotos, Meldezeitpunkt, Kanal | B2, B6 |
| Melderangaben, freiwillig | freier Name, freier Kontakt (E-Mail oder Telefon), optional, anonyme Meldung ist möglich und der Regelfall | B2, B6 |
| Störungsmeldung | Beschreibung, Auswirkung, Foto, Meldezeitpunkt | B2, B6 |
| Technische Missbrauchsabwehr | gesalzener Hashwert der IP-Adresse (ip_hash), Portalsitzungskennung, Klasse des Nutzeragenten | B2, B6 |
| Bearbeitung | bearbeitende Person, Zeitpunkt, Ablehnungsgrund | B1 |
Anonymität ist die Voreinstellung. Das Portal verlangt keine Anmeldung und keine Namensangabe. Seit dem 30.08.2026 ist die Anwendung nur nach Anmeldung nutzbar; das Objektportal ist damit der einzige vorgesehene Zugang zu Instandio, der kein Konto voraussetzt. Der Personenbezug entsteht nur, wenn der Melder ihn selbst herstellt. Der
ip_hashdient ausschließlich der Missbrauchsabwehr, soll gesalzen gebildet und nach sieben Tagen gelöscht werden. ○ Stand 07.08.2026: Anlage 2 Nr. 1.5.3geplant; ein Portaldienst existiert nicht.Was das Portal auf der Voreinstellungsstufe nicht zeigt: keine Personennamen (weder Prüfer noch Verantwortlicher), keine Mängeldetails, keine Historie, keine Kosten, keine Dokumente. Auf keiner Sichtbarkeitsstufe sollen Mitarbeiterstamm, Qualifikationen, Zeitbuchungen, Stundensätze und Kostendaten erreichbar sein. Die technische Absicherung dieser Trennung durch einen eigenen Portaldienst mit eingeschränkter Leseberechtigung ist in Anlage 2 Nr. 1.3.8 als kritisch gekennzeichnet und trägt den Stand ○
geplant; sie ist bis dahin keine Zusicherung (§ 6 Absatz 2 des Vertrags).
4.5 Dokumente und Bilddaten
| Datenart | Personenbezug | Betroffene |
|---|---|---|
| Mangel- und Erledigungsfotos | können Personen abbilden, wenn sie beim Fotografieren im Bild sind; Standortdaten in den Bildmetadaten | B1, B2, B3, B6 |
| Prüfprotokolle als PDF | Name der prüfenden Person, Befähigungsangaben, Unterschriftsblock | B1, B4 |
| Qualifikationsnachweise als Scan | Name, Urkundennummer, Aussteller | B1, B3, B4 |
| Handbücher, Schaltpläne, Betriebsanweisungen | in der Regel kein Personenbezug; ausgehängte Betriebsanweisungen tragen den freigebenden Namen | B1 |
| Belege zu Zeitbuchungen | Name, ggf. Stundensatz | B1, B3 |
EXIF-Entfernung. Vorgesehen ist, die Metadaten von Bildern beim Hochladen serverseitig zu entfernen. GPS-Koordinaten in Werksfotos sind zugleich ein Datenschutz- und ein Betriebsgeheimnisproblem. ○ geplant, Stand 07.08.2026: in der Anwendung 1.1 werden Bilder über die Canvas-Schnittstelle des Browsers verkleinert; dabei gehen Metadaten technisch bedingt verloren. Eine gezielte, geprüfte EXIF-Entfernung als Sicherheitsmaßnahme existiert nicht.
4.6 Protokoll- und Systemdaten
| Datenart | Felder | Aufbewahrung |
|---|---|---|
Ereignisprotokoll audit_event | Zeitstempel, handelnde Person (Kennung, UPN, Anzeigename als Schnappschuss), Entität, Aktion, geändertes Feld mit altem und neuem Wert, Quelle (Web, Teams, QR-Portal, API, Offline-Abgleich, System, Support), Korrelationskennung, ip_hash | 10 Jahre; ip_hash 7 Tage |
| Anmeldeprotokoll | Anmeldezeitpunkt, Kennung, Quelle | Teil des Ereignisprotokolls |
| Benachrichtigungsprotokoll | Empfänger, Kanal, Status, Fehlergrund, Zustellversuche | 12 Monate |
| Anwendungsprotokolle und Fehlermeldungen | technische Kennungen, keine Fachdaten im Klartext | 31 Tage |
| Synchronisationsprotokoll | Gerätekennung, Idempotenzschlüssel, Zeitstempel, Ergebnis je Vorgang | 90 Tage |
Fehlerprotokolle enthalten keine Fachdaten, sondern ausschließlich Kennungen. Ein Stapelverfolgungsprotokoll mit Klartextinhalten aus einem Prüfprotokoll wäre bereits eine Verarbeitung außerhalb des Zwecks.
4.7 Vertrags- und Abrechnungsdaten: keine Auftragsverarbeitung
Daten zur Vertragsabwicklung zwischen vdw und dem Kunden (Firmierung, Anschrift, USt-ID, Ansprechpartner, Rechnungs- und Zahlungsdaten, SEPA-Mandat) verarbeitet vdw als eigener Verantwortlicher nach Art. 6 Abs. 1 lit. b und lit. c DSGVO. Sie sind nicht Gegenstand dieses Auftragsverarbeitungsvertrags, sondern des Verzeichnisses nach Art. 30 Abs. 1 DSGVO (Dokument 14). Die Trennung ist bewusst und wichtig: der Zahlungsdienstleister Mollie ist damit kein Unterauftragsverarbeiter dieses Vertrags.
5. Ort der Verarbeitung
5.1 Zielzustand nach Fertigstellung des Serverbetriebs
Für Datenbank, Anmeldung und Schnittstelle ist die Entscheidung getroffen und der Vertrag geschlossen; die übrigen Zeilen beschreiben den Zielzustand und werden erst mit dem Abschluss der jeweiligen Verträge verbindlich. Bis dahin ist keine der dort genannten Angaben eine Zusicherung. Maßgeblich ist Anlage 3, in der derzeit ein Unterauftragsverarbeiter geführt wird: die Supabase Pte. Ltd., Verarbeitungsort Frankfurt am Main, beauftragt am 15.08.2026.
| Verarbeitung | Ort im Zielzustand | Anbieter | Stand |
|---|---|---|---|
| Datenbank, Anmeldung und Schnittstelle der Kundenkonten | Frankfurt am Main, Region eu-central-1 | Supabase Pte. Ltd. (Anlage 3 Abschnitt 1) | beauftragt am 15.08.2026, in Betrieb |
| Auslieferung der Programmdateien der Anwendung | Deutschland | IONOS-Webspace unter app.instandio.de; dort werden keine Kundendaten gespeichert oder verarbeitet | in Betrieb, keine Auftragsverarbeitung |
| Objektspeicher für Dokumente und Fotos, Anwendungsprotokolle | Deutschland | offen, Entscheidung nicht getroffen (Anlage 3, Aufgabe A1) | nicht beauftragt; ein Objektspeicher besteht nicht |
| Datensicherung | dieselbe Region, getrennter Speicherbereich | offen, Sicherungskonzept nicht abgestimmt (Anlage 3, Aufgabe A1) | nicht beauftragt |
| E-Mail-Versand | EU | Versand aus dem Microsoft-365-Postfach kontakt@instandio.de der vdw GmbH über die Serverfunktionen auth-mail und formular-mail; ein gesonderter Versanddienstleister ist nicht ausgewählt (Anlage 3, Aufgabe A4) | in Betrieb seit dem 21.08.2026. Ob daraus eine Aufnahme in Anlage 3 folgt, ist fachkundig zu klären |
| Virenscan hochgeladener Dateien | EU | offen, Auswahl nicht getroffen (Anlage 3, Aufgabe A5) | nicht beauftragt |
| Fehlermeldungen und Betriebsüberwachung | EU | offen, Auswahl nicht getroffen (Anlage 3, Aufgabe A6) | nicht beauftragt |
Vorgabe für jede dieser Entscheidungen: keine Verarbeitung außerhalb der EU beziehungsweise des EWR. Eine Drittlandübermittlung ist nicht vorgesehen; siehe § 3 Absatz 5 und § 8 Absatz 8 des Vertrags. Vor Vertragsschluss mit einem Kunden sind die Zeilen dieser Tabelle mit dem tatsächlich beauftragten Anbieter, dessen vollständiger Firmierung und dem vertraglich zugesicherten Verarbeitungsort zu füllen; ohne diese Angaben ist die Anforderung des Art. 28 Abs. 3 lit. a DSGVO an die Bestimmung des Verarbeitungsorts nicht erfüllt.
5.2 Tatsächlicher Stand am 30.08.2026: ehrliche Angabe
Die Angaben zu den Verarbeitungsorten beruhen auf der Erhebung vom 23.08.2026. Am 30.08.2026 ist allein die Angabe zur Nutzung ohne Konto fortgeschrieben worden; die übrigen Angaben sind seither nicht erneut erhoben worden.
| Umgebung | Ort | Bewertung |
|---|---|---|
| Produktivbetrieb | Frankfurt am Main, Region eu-central-1, betrieben durch die Supabase Pte. Ltd. | Besteht seit dem 15.08.2026. Sobald ein Kunde ein Konto anlegt, werden seine Daten dort verarbeitet; vdw ist insoweit Auftragsverarbeiterin nach Art. 28 DSGVO. Seit dem 30.08.2026 ist die Anwendung nur nach Anmeldung nutzbar. Ein Betrieb der Anwendung ohne Konto findet nicht mehr statt; die frühere Angabe, bei einer Nutzung ohne Konto verarbeite vdw keine Daten, trifft für die Anwendung deshalb nicht mehr zu. Ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code am Objektetikett: Anzeige des Objekts und Abgabe einer Meldung (Vorgang V8, Abschnitt 4.4); der Melder legt dafür kein Konto an. Ein Portaldienst besteht bisher nicht (Anlage 2 Nr. 1.3.8, Stand ○ geplant). Die Programmdateien der Anwendung werden getrennt davon über den IONOS-Webspace ausgeliefert, ohne dass dort Kundendaten anfallen. Die Freischaltung eines Kundenmandanten setzt zusätzlich die gegengezeichnete Bestätigung nach § 6 Absatz 6 des Vertrags voraus; sie ist bisher nicht erteilt |
| Entwicklung, Test und Abnahme (geplant) | Hostinger-Bestandsserver (SSH-Kennung hostinger-vdw), Ubuntu 24.04 LTS, PostgreSQL 16 | Rechenzentrumsstandort innerhalb der EU (festgelegt am 23.08.2026). Auf derselben Maschine läuft ein fremdes Produktivsystem der vdw GmbH (KDP-Factory-Pipeline). Für Kundendaten ist dieser Server nicht geeignet und darf sie nicht enthalten |
6. Löschfristen je Datenart
Die Fristen sind je Mandant konfigurierbar; die Tabelle nennt die fachlich begründete Voreinstellung. Der Kunde entscheidet als Verantwortlicher über die für ihn geltenden Fristen. Einzelheiten zu Auslöser, Zuständigkeit und technischer Umsetzung stehen im Löschkonzept (Dokument 15).
| Nr. | Datenart | Voreinstellung | Löschauslöser | Begründung |
|---|---|---|---|---|
| L1 | Prüfungen, Prüfprotokolle, Mängel, Maßnahmen | 10 Jahre nach Abschluss, mindestens bis zur Aussonderung des Objekts zuzüglich 3 Jahre | Ablauf der Frist nach Abschluss beziehungsweise Aussonderung | Nachweisführung gegenüber Berufsgenossenschaft und Behörde, Verjährungsfristen |
| L2 | Aufträge, Zeitbuchungen, Materialverbrauch | 10 Jahre | Ablauf der Frist nach Abschluss | handels- und steuerrechtlich relevant, weil kostenwirksam |
| L3 | Qualifikationsnachweise (Daten und Scans) | bis Austritt zuzüglich 3 Jahre | Eintrag des Austrittsdatums beim Mitarbeiter | Nachweis der Befähigung für den Zeitraum der Tätigkeit |
| L4 | Nachweisdokumente und Scans | wie der zugehörige Nachweis | Löschung des Bezugsdatensatzes | Gleichlauf mit dem Hauptdatensatz |
| L5 | Schadens- und Störungsmeldungen mit Melderbezug | 3 Jahre | Ablauf der Frist ab Meldung | Unfallnachbereitung |
| L6 | ip_hash, Portalsitzungen, Nutzeragentklasse | 7 Tage | täglicher Lauf | reine Missbrauchsabwehr |
| L7 | Ereignisprotokoll audit_event | 10 Jahre | Ablauf der Frist ab Ereigniszeitpunkt | Nachweiskette |
| L8 | Nutzerkonten | Deaktivierung bei Austritt, Löschung nach 12 Monaten; der Anzeigename bleibt als Schnappschuss in bereits erzeugten Nachweisen erhalten | Statuswechsel und Fristablauf | Nachweise müssen lesbar bleiben, das Konto muss es nicht |
| L9 | Mitarbeiterstamm ohne Nachweisbezug | mit dem letzten Bezugsdatensatz | Löschung aller Bezüge | Datensparsamkeit |
| L10 | Anwendungsprotokolle, Fehlermeldungen | 31 Tage | automatische Rotation | Störungsanalyse |
| L11 | Benachrichtigungsprotokoll | 12 Monate | Fristablauf | Nachweis der Zustellung von Fristenalarmen über einen vollständigen Jahreszyklus der Prüffristen |
| L12 | Synchronisationsprotokoll | 90 Tage | Fristablauf | Konfliktanalyse bei Offline-Erfassung |
| L13 | Support-Protokolle zu vdw_support-Zugriffen | 10 Jahre, als Teil des Ereignisprotokolls | Fristablauf | Nachweis gegenüber dem Kunden |
| L14 | Gesamter Mandantenbestand nach Kündigung | 30 Tage Karenz mit Exportmöglichkeit, danach vollständige Löschung einschließlich Dokumenten, mit Löschprotokoll an den Kunden | Vertragsende | § 11 des Vertrags |
| L15 | Datensicherungen | Auslauf mit dem Sicherungsstand, spätestens 35 Tage nach der Löschung | Ablauf des Sicherungszeitraums | Wiederherstellbarkeit im Notfall |
7. Empfänger und Offenlegung
| Empfänger | Umfang | Grundlage |
|---|---|---|
| Beschäftigte des Kunden nach Rolle und Geltungsbereich | nach Rechtekatalog | Weisung des Kunden über die Rollenvergabe |
Fremdfirmen über die Anmeldeklasse fremdfirma_extern | ausschließlich eigene Aufträge und deren Objekte; keine Stammdaten, keine fremden Kosten, keine anderen Objekte | Weisung des Kunden |
Auditoren über die Rolle auditor | lesend, keine Änderung, Exporte | Weisung des Kunden |
| Öffentlichkeit über das QR-Portal | ausschließlich der auf der eingestellten Sichtbarkeitsstufe freigegebene Umfang; keine Personennamen auf der Voreinstellungsstufe | Einstellung des Kunden |
Beschäftigte der vdw GmbH mit der Rolle vdw_support | befristet, nach Freischaltung durch den Kunden, vollständig protokolliert | § 5 Absatz 5 des Vertrags |
| Unterauftragsverarbeiter | siehe Anlage 3 | § 8 des Vertrags |
Keine Übermittlung an Dritte zu deren eigenen Zwecken, keine Veräußerung, keine Werbenutzung, keine Nutzung zum Training von Modellen künstlicher Intelligenz.
8. Ansprechpartner und Weisungsberechtigte
8.1 Beim Kunden (Verantwortlicher)
Vom Kunden auszufüllen. Die Angaben sind Voraussetzung für die Meldung nach § 10 des Vertrags und für die Entgegennahme von Weisungen; ohne sie kann der Vertrag nicht durchgeführt werden. Der Kunde hält die Angaben aktuell und teilt Änderungen unverzüglich mit.
| Funktion | Name | Telefon | |
|---|---|---|---|
| Weisungsberechtigt | |||
| Weisungsberechtigt (Vertretung) | |||
| Datenschutzbeauftragter, sofern bestellt | |||
| Empfänger von Meldungen nach § 10 des Vertrags | |||
| Mandantenadministrator in der Anwendung |
8.2 Bei der vdw GmbH (Auftragsverarbeiter)
| Funktion | Name | Kontakt |
|---|---|---|
| Weisungsempfang, Datenschutzfragen | Olaf von Deines, Geschäftsführer | 02723/719334 · datenschutz@v-d-w.de |
| Vertretung | Dorian Wolf, Geschäftsführer | 02723/719334 · info@v-d-w.de |
| Datenschutzbeauftragter | nicht bestellt. Eine Bestellpflicht besteht nach § 38 Abs. 1 Satz 1 BDSG bei rund fünf Beschäftigten nicht; siehe § 12 des Vertrags | entfällt |
| Meldung von Sicherheitsvorfällen | siehe Dokument 16, Eskalationskette | entfällt |
Aufgabe vor dem ersten Vertragsschluss: Das Postfach
datenschutz@v-d-w.deist einzurichten und einer der beiden Geschäftsführer als Empfänger zu hinterlegen. Bis dahin giltinfo@v-d-w.de. Eine im Vertrag genannte, aber nicht erreichbare Adresse ist ein Mangel der Weisungskette.
Änderungsverzeichnis
| Version | Datum | Änderung | Bearbeiter |
|---|---|---|---|
| 1.2 | 30.08.2026 | Abschnitt 5.2 auf die Anmeldepflicht ab dem 30.08.2026 umgestellt; die Angabe, bei einer Nutzung ohne Konto verarbeite vdw keine Daten, ist für die Anwendung entfallen. Abschnitt 4.4 hält fest, dass das Objektportal hinter dem QR-Code der einzige vorgesehene Zugang ohne Konto bleibt. Neuer interner Abschnitt „Offene Punkte zur Nutzung ohne Konto“ | vdw GmbH |
| 1.1 | 23.08.2026 | Abschnitt 5.1 und 5.2 auf den tatsächlichen Verarbeitungsort fortgeschrieben: Produktivbetrieb besteht seit dem 15.08.2026 in Frankfurt am Main; Zeile für Datenbank, Anmeldung und Schnittstelle als beauftragt ausgewiesen; Auslieferung der Programmdateien und E-Mail-Versand mit ihrem Ist-Stand aufgenommen | vdw GmbH |
| 1.1 | 15.08.2026 | Serverbetrieb aufgenommen: Supabase Pte. Ltd. als Unterauftragsverarbeiter in Anlage 3, Drittlandbezug ausgewiesen, Vorbemerkung auf den tatsächlichen Stand umgestellt | vdw GmbH |
| 1.0-Entwurf | 07.08.2026 | Ersterstellung | vdw GmbH |
Änderungsprotokoll
| Datum | Geänderte Abschnitte | Behobener Befund |
|---|---|---|
| 07.08.2026 | Abschnitt 1 und 2: Leitentscheidung der Geschäftsführung aufgenommen: Prüffristen der Software sind Vorschläge ohne Rechtsverbindlichkeit, die Festlegung obliegt dem Kunden als Betreiber; Zweckbeschreibung von „Erfüllung“ auf „Unterstützung bei der Erfüllung“ der Betreiberpflichten umgestellt | Leitentscheidung Geschäftsführung |
| 07.08.2026 | Abschnitt 1, V12: Begriff „revisionssicher“ aus der Beschreibung des Ereignisprotokolls entfernt | Anlage 2 Abschnitt 2.2 (Grenze des Ereignisprotokolls) |
| 07.08.2026 | Abschnitt 4.1: § 26 Abs. 1 BDSG als Rechtsgrundlage gestrichen, Begründung ergänzt | B-11 |
| 07.08.2026 | Abschnitt 4.3, 4.4, 4.5: Aussagen zur Abschaltung personenbezogener Auswertungen, zur Abschottung des QR-Portals und zur EXIF-Entfernung vom Präsens auf den tatsächlichen Umsetzungsstand umgestellt | B-01, B-02 |
| 07.08.2026 | Abschnitt 4.6 und 6: offene Fristen L11 und L12 entschieden (12 Monate, 90 Tage); keine Platzhalter mehr in den Löschfristen | Auflage zu Dokument 11 (Ampeltabelle) |
| 07.08.2026 | Abschnitt 5.1: Anbieterspalte auf „offen, nicht beauftragt“ umgestellt; kein Anbietername mehr als Zielzustand ausgewiesen; Pflicht zur Füllung vor Vertragsschluss benannt | B-06 |
| 07.08.2026 | Abschnitt 8.1: Kundenangaben von Platzhaltern auf Ausfüllfelder umgestellt; 8.2: Datenschutzbeauftragter und Kontaktadresse festgelegt, Einrichtung des Postfachs als Aufgabe benannt | Auflage: Dokument ohne Kundendaten vollständig |
| 23.08.2026 | Abschnitt 5.2, Zeile „Produktivbetrieb“: Angabe „existiert nicht … vdw verarbeitet derzeit keine Kundendaten“ berichtigt. Der Produktivbetrieb besteht seit dem 15.08.2026 bei der Supabase Pte. Ltd. in Frankfurt am Main; die Nutzung ohne Konto bleibt rein örtlich, und die Freischaltung eines Kundenmandanten nach § 6 Absatz 6 des Vertrags ist nicht erteilt. (Die Angabe zur Nutzung ohne Konto gibt den Stand vom 23.08.2026 wieder. Seit dem 30.08.2026 ist die Anwendung nur nach Anmeldung nutzbar; maßgeblich ist der Eintrag vom 30.08.2026.) Abschnitt 5.1: Zeile für Anwendung und Datenbank aufgelöst in eine beauftragte Zeile (Datenbank, Anmeldung und Schnittstelle, Supabase Pte. Ltd.) und offene Zeilen für Objektspeicher, Anwendungsprotokolle und Datensicherung; Auslieferung der Programmdateien über den IONOS-Webspace als eigene Zeile ohne Kundendaten aufgenommen; Zeile „E-Mail-Versand“ auf den Ist-Stand gebracht (Versand aus dem eigenen Microsoft-365-Postfach seit dem 21.08.2026, kein gesonderter Versanddienstleister, Aufnahme in Anlage 3 fachkundig zu klären). Belege: Erhebung gegen die laufende Instanz und die Serverfunktionen am 23.08.2026, siehe Anlage 2 Ziffer 0.1 | Erhebung vom 23.08.2026, Anlage 2 Ziffer 0.2.1 |
| 23.08.2026 | Abschnitt 5.1: Angabe „kein Unterauftragsverarbeiter“ auf den tatsächlichen Stand berichtigt (Supabase Pte. Ltd., beauftragt am 15.08.2026); Abschnitt 5.2: Erhebungsstand auf den 23.08.2026 fortgeschrieben und der Rechenzentrumsstandort des Bestandsservers als innerhalb der EU festgelegt, der Ausschlussgrund des fremden Produktivsystems bleibt unverändert; Kopfzeile fortgeschrieben; Gedankenstriche aufgelöst und Anführungszeichen vereinheitlicht | Entscheidung der Geschäftsführung vom 23.08.2026, Widerspruch zu Anlage 3, Redaktion |
| 30.08.2026 | Abschnitt 5.2, Zeile „Produktivbetrieb“: die Angabe, wer Instandio ohne Konto nutze, arbeite ausschließlich im lokalen Speicher seines Endgeräts und bei ihm verarbeite vdw keine Daten, ist gestrichen und durch den Stand seit dem 30.08.2026 ersetzt: Die Anwendung ist nur nach Anmeldung nutzbar. Überschrift des Abschnitts 5.2 fortgeschrieben und die Reichweite der Erhebung vom 23.08.2026 davor gesetzt. Abschnitt 4.4: das Objektportal hinter dem QR-Code ausdrücklich als einziger vorgesehener Zugang ohne Konto bezeichnet. Neuer interner Abschnitt „Offene Punkte zur Nutzung ohne Konto“ mit den Fragen O1 bis O3. Der Eintrag vom 23.08.2026 bleibt als Beleg des damaligen Standes unverändert stehen; seine Angabe, die Nutzung ohne Konto bleibe rein örtlich, ist seit dem 30.08.2026 überholt | Entscheidung der Geschäftsführung vom 30.08.2026: Die Anwendung ist nur nach Anmeldung nutzbar |
Anlage 2: Technische und organisatorische Maßnahmen
nach Artikel 32 DSGVO · Produkt: Instandio · Auftragsverarbeiter: vdw GmbH
Fassung: 1.2 · Stand 30.08.2026 · Anlage zum Auftragsverarbeitungsvertrag
0. Wie diese Anlage zu lesen ist: der wichtigste Abschnitt
Diese Anlage beschreibt zwei Dinge gleichzeitig: die geplanten Maßnahmen und ihren tatsächlichen Umsetzungsstand. Beides wird bewusst nicht vermischt, weil ein Auftragsverarbeitungsvertrag, der nicht vorhandene Maßnahmen zusichert, eine falsche Zusicherung gegenüber dem Kunden ist.
0.1 Ausgangslage am 23.08.2026, fortgeschrieben am 30.08.2026
Instandio ist in der Fassung 1.1 als installierbare Webanwendung gebaut (React, TypeScript, 1247 Tests in 22 Dateien, am 23.08.2026 vollständig durchgelaufen). Seit dem 15.08.2026 kommt ein Serverbetrieb hinzu. Der Stand am 23.08.2026:
- Ein Serverbetrieb besteht. Datenbank, Anmeldung und Schnittstelle laufen bei der Supabase Pte. Ltd. (Postgres 17.6.1, Region
eu-central-1, Frankfurt am Main). Sie ist seit dem 15.08.2026 als Unterauftragsverarbeiterin beauftragt, siehe Anlage 3 Abschnitt 1. Damit ist die vdw GmbH Auftragsverarbeiterin nach Art. 28 DSGVO. - Eine Mandantentrennung besteht. Jede Zeile mit Mandantenbezug trägt ihren Betrieb, und auf allen 13 Tabellen der laufenden Instanz ist die zeilenbasierte Zugriffskontrolle (Row Level Security) eingeschaltet. Sie ist noch nicht zusätzlich erzwungen (
FORCE); siehe Nr. 1.4.2. - Eine Anmeldung besteht: E-Mail und Kennwort über den Anmeldedienst des Unterauftragsverarbeiters, mit vorausgesetzter Bestätigung der E-Mail-Adresse. Sie ist nicht die in Nr. 1.2.1 beschriebene Anmeldung über das Identitätsverzeichnis des Kunden. Die Personenauswahl in der Kopfleiste besteht daneben fort; sie steuert weiterhin nur, was die Oberfläche anbietet, und schützt nichts.
- Vier Rollen je Betrieb (
inhaber,verwalter,mitarbeiter,leser) werden in der Datenbank geprüft, nicht nur in der Oberfläche. - Verschlüsselung im Transport ist geprüft (TLS 1.3, ältere Fassungen abgewiesen). Nicht vorhanden sind weiterhin: eine geprüfte Verschlüsselung im Ruhezustand, eine Datensicherung durch vdw mit erprobter Wiederherstellung, ein anfügendes Ereignisprotokoll auf dem Server, ein Objektspeicher für Dokumente, das QR-Portal und eine Betriebsüberwachung.
- Seit dem 30.08.2026 ist die Anwendung nur nach Anmeldung nutzbar. Ein Betrieb der Anwendung allein im lokalen Speicher (
localStorage) des Endgeräts findet damit nicht mehr statt; die frühere Angabe, bei einer Nutzung ohne Konto verlasse kein Datum das Gerät und vdw verarbeite keine Daten, trifft für die Anwendung nicht mehr zu. Ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code am Objektetikett: Anzeige des Objekts und Abgabe einer Meldung. Ein Portaldienst besteht auf der laufenden Instanz nicht; die dafür vorgesehenen Maßnahmen tragen den Stand○ geplant(Nr. 1.3.8, 1.5.3, 2.1.6).
Daraus folgt: Ein Teil der Maßnahmen dieser Anlage trägt jetzt den Stand ✔ umgesetzt oder ◑ teilweise; die Mehrheit trägt weiterhin ○ geplant. Die Zählung steht in Ziffer 0.3. Das ist keine Nachlässigkeit der Dokumentation, sondern der ehrliche Befund. Die übrigen Maßnahmen entstehen mit dem weiteren Ausbau des Serverbetriebs (Fundament F1 der Roadmap).
0.2 Kennzeichnung
| Zeichen | Bedeutung |
|---|---|
✔ umgesetzt | Die Maßnahme ist gebaut, in Betrieb und überprüft. Nur solche Maßnahmen sind Gegenstand einer Zusicherung |
◑ teilweise | Die Maßnahme besteht in Teilen; der fehlende Teil ist benannt |
○ geplant | Die Maßnahme ist konzipiert, aber nicht vorhanden. Sie ist keine Zusicherung |
| kritisch | Maßnahme, die nach § 6 Absatz 5 des Vertrags vor Aufnahme des Produktivbetriebs den Stand ✔ tragen muss |
Alle Angaben beziehen sich auf den Stand 23.08.2026; allein die Angabe zur Anmeldepflicht in Ziffer 0.1 ist am 30.08.2026 fortgeschrieben worden. Vor jeder Übergabe an einen Kunden ist der Stand neu zu erheben und das Datum in der Kopfzeile fortzuschreiben.
0.2.1 Diese Anlage ist der Prüfmaßstab für alle übrigen Dokumente
Keine Aussage in einem anderen Dokument darf eine technische Maßnahme im Präsens behaupten, die hier nicht den Stand ✔ umgesetzt trägt. Das gilt für den Vertragstext selbst, für Anlage 1, für die Datenschutzhinweise zur Anwendung (Dokument 22), für die Leistungsbeschreibung, für Angebote und für die Webseite. Betroffen sind insbesondere die Dokumente, die der Kunde in eigenem Namen weitergibt. Er haftet dann für eine Aussage, deren Quelle wir sind.
Die Prüfung ist mechanisch: Aussage suchen, zugehörige Nummer in dieser Anlage nachschlagen, Stand vergleichen. Sie ist vor jeder Übergabe an einen Kunden zu wiederholen. Umgekehrt gilt: Sobald eine Maßnahme hier auf ✔ wechselt, sind die abhängigen Textstellen auf die technische Formulierung zurückzustellen. Sonst verschenkt man eine erarbeitete Zusage.
Die Freizeichnung in § 6 Absatz 2 des Vertrags wirkt nur für die Maßnahmen dieser Anlage und nur im Verhältnis zum Kunden. Sie erfasst weder Zusagen im Vertragstext außerhalb dieser Anlage noch Angaben in Dokument 22 gegenüber Beschäftigten des Kunden, und sie entlastet gegenüber der Aufsichtsbehörde nicht, weil Art. 32 DSGVO die vdw GmbH unmittelbar kraft Gesetzes trifft.
0.3 Zusammenfassung des Stands
Ausgezählt am 23.08.2026 über alle nummerierten Maßnahmen der Abschnitte 1 bis 4. Die Zählung der Fassung vom 07.08.2026 war unvollständig; sie erfasste nicht jede Zeile.
| Bereich | ✔ | ◑ | ○ | Maßnahmen |
|---|---|---|---|---|
| 1. Vertraulichkeit | 5 | 15 | 29 | 49 |
| 2. Integrität | 3 | 9 | 13 | 25 |
| 3. Verfügbarkeit und Belastbarkeit | 1 | 1 | 11 | 13 |
| 4. Verfahren zur Überprüfung | 2 | 8 | 13 | 23 |
| Summe | 11 | 33 | 66 | 110 |
Nur die 11 Maßnahmen mit dem Stand ✔ sind Gegenstand einer Zusicherung. Als kritisch gekennzeichnet sind 35 Maßnahmen. Davon tragen 3 den Stand ✔ (Nr. 1.4.3, 1.4.6, 3.6), 8 den Stand ◑ (Nr. 1.3.2, 1.4.1, 1.4.2, 1.4.4, 1.4.11, 2.1.1, 2.2.7, 4.2.1) und 24 den Stand ○. Die Voraussetzung des § 6 Absatz 5 des Vertrags ist damit nicht erfüllt: Ein Produktivbetrieb für einen Kunden darf nach dieser Vorschrift nicht aufgenommen werden.
1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)
1.1 Zutrittskontrolle: kein unbefugter Zutritt zu Datenverarbeitungsanlagen
| Nr. | Maßnahme | Stand |
|---|---|---|
| 1.1.1 | Die Verarbeitung findet ausschließlich in Rechenzentren des Hostinganbieters statt. Der physische Zutrittsschutz obliegt dem Unterauftragsverarbeiter und ist über dessen Zertifizierung nachzuweisen (siehe Anlage 3) | ○ geplant kritisch: der Anbieter der Datenbank steht seit dem 15.08.2026 fest (Anlage 3 Abschnitt 1). Ein Zertifizierungsnachweis liegt der vdw GmbH nicht vor; der Zutrittsschutz ist von vdw nicht überprüft |
| 1.1.2 | vdw selbst betreibt keine eigenen Server mit Kundendaten in eigenen Räumen | ✔ umgesetzt |
| 1.1.3 | Geschäftsräume der vdw GmbH, Fichtenstr. 49, Lennestadt: abschließbar, Schlüsselverwaltung mit dokumentierter Ausgabe, Besucher nur in Begleitung | ◑ teilweise: Räume abschließbar; ein dokumentiertes Schlüsselverzeichnis und eine Besucherregelung liegen nicht vor |
| 1.1.4 | Arbeitsplatzrechner mit Kundendatenzugriff werden bei Verlassen des Arbeitsplatzes gesperrt (automatische Bildschirmsperre nach höchstens 10 Minuten) | ○ geplant: als Richtlinie festzulegen und technisch zu erzwingen |
| 1.1.5 | Mobile Arbeit: Zugriff auf Verwaltungsoberflächen ausschließlich über verschlüsselte Verbindung und mit Zwei-Faktor-Authentisierung; keine lokale Ablage von Kundendaten auf Endgeräten | ○ geplant |
1.2 Zugangskontrolle: kein unbefugter Zugang zu Systemen
| Nr. | Maßnahme | Stand |
|---|---|---|
| 1.2.1 | Anmeldung über Microsoft Entra ID (Single Sign-on) für Beschäftigte des Kunden; die Authentisierung erfolgt im Identitätsverzeichnis des Kunden, vdw speichert keine Kennwörter dieser Nutzer | ○ geplant kritisch: eine Anmeldung besteht seit dem 15.08.2026, aber nicht über Entra ID. Sie läuft mit E-Mail und Kennwort über den Anmeldedienst des Unterauftragsverarbeiters, mit vorausgesetzter Bestätigung der E-Mail-Adresse (server/migrationen/0004_bestellung_einloesen.sql Zeile 101). Die Kennwörter dieser Nutzer liegen damit als Streuwert beim Unterauftragsverarbeiter, nicht im Identitätsverzeichnis des Kunden. Die Aussage „vdw speichert keine Kennwörter dieser Nutzer“ ist für den heutigen Anmeldeweg keine Zusicherung |
| 1.2.2 | Eigene Anmeldung für Fremdfirmen (fremdfirma_extern) mit Kennwortrichtlinie, Speicherung ausschließlich als Argon2-Hash, Sperre nach mehrfacher Fehleingabe | ○ geplant kritisch |
| 1.2.3 | Werks-PIN je Standort für die QR-Portalstufe 2, gespeichert als Argon2-Hash, rotierbar, Sperre nach 10 Fehlversuchen je IP-Adresse | ○ geplant |
| 1.2.4 | Drei getrennte Tokenklassen (Nutzertoken, Portaltoken, Dienstetoken) mit jeweils eigenem Geltungsbereich; ein Portaltoken erreicht keine Route außerhalb seines Objekts und seiner Sichtbarkeitsstufe | ○ geplant kritisch |
| 1.2.5 | QR-Portaltoken: 128 Bit Zufall, base62-kodiert, nicht aus Inventarnummer oder Kennung ableitbar, je Objekt und mandantenweit widerrufbar und rotierbar | ◑ teilweise: das Etikettenverfahren ist in der Anwendung gebaut, ein Portaldienst mit Tokenprüfung existiert nicht |
| 1.2.6 | Zwei-Faktor-Authentisierung für alle administrativen Zugänge von vdw (Hostingkonsole, Datenbank, Geheimnisspeicher, Quellcodeverwaltung) | ○ geplant kritisch |
| 1.2.7 | Keine Zugangsdaten im Quellcode, in Dokumentation oder in Umgebungsvariablen der Verwaltungsoberfläche. Geheimnisse ausschließlich im Geheimnisspeicher, Zugriff über verwaltete Identität ohne hinterlegtes Kennwort | ◑ teilweise: die Regel gilt im Arbeitsbereich der vdw GmbH und wird eingehalten. Die Zugangsdaten der laufenden Instanz stehen in einer nicht versionierten .env; der im Browser ausgelieferte Schlüssel ist bewusst kein Geheimnis, weil die Trennung ausschließlich der Zeilenschutz der Datenbank leistet (server/README.md Zeilen 26 bis 29). Die Geheimnisse der Serverfunktionen liegen im Geheimnisspeicher des Unterauftragsverarbeiters. Ein eigener Geheimnisspeicher mit verwalteter Identität und ein festgelegter Rotationsturnus bestehen nicht |
| 1.2.8 | Schlüsselrotation für Dienstetoken und Zahlungsschlüssel nach festem Turnus | ○ geplant |
| 1.2.9 | Sperrung von Konten bei Austritt beziehungsweise Ende der Berechtigung; automatische Deaktivierung nach Inaktivität | ◑ teilweise: die Zugehörigkeit zu einem Betrieb lässt sich jederzeit lösen (mitglied_entfernen, server/migrationen/0003_konto_und_abgleich.sql Zeilen 171 bis 195); die Berechtigung dazu ist serverseitig geprüft und der letzte Inhaber ist geschützt. Das Nutzerkonto selbst bleibt dabei bestehen, und eine automatische Deaktivierung nach Inaktivität besteht nicht |
| 1.2.10 | Kein Zahlungsdienst-Schlüssel im Browser. Der Schlüssel des Zahlungsdienstleisters bleibt ausschließlich serverseitig | ✔ umgesetzt: die Zahlungsanbindung läuft seit dem 16.08.2026 ausschließlich über Serverfunktionen (server/funktionen/bestellung-bezahlen/index.ts). Die Schlüssel werden dort über pflichtwert() aus der Serverumgebung gelesen; in instandio/src, in webseite/src und in den ausgelieferten Programmdateien kommt kein Schlüssel des Zahlungsdienstleisters vor (geprüft am 23.08.2026) |
| 1.2.11 | Kurze Gültigkeit des Einmalkennworts aus Bestätigungs-, Einladungs- und Kennwortmails: höchstens eine Stunde | ○ geplant: derzeit nicht eingehalten. Der Sicherheitsprüfer des Anbieters meldet am 23.08.2026 den Befund auth_otp_long_expiry (Stufe WARN): die eingestellte Gültigkeit liegt über einer Stunde, empfohlen ist darunter. Der Wert ist in den Anmeldeeinstellungen zu senken |
| 1.2.12 | Abgleich gewählter Kennwörter gegen bekannt gewordene Passwortlisten bei Registrierung und Kennwortwechsel | ○ geplant: abgeschaltet. Der Sicherheitsprüfer des Anbieters meldet am 23.08.2026 den Befund auth_leaked_password_protection (Stufe WARN). Der Abgleich ist einzuschalten; bis dahin ist er keine Zusicherung, siehe Abschnitt 5 |
1.3 Zugriffskontrolle: Berechtigte greifen nur auf das zu, wofür sie berechtigt sind
| Nr. | Maßnahme | Stand |
|---|---|---|
| 1.3.1 | Rollen- und Rechtekonzept mit Rechten der Form <ressource>.<aktion>, Rollen als benannte Mengen von Rechten und Zuweisungen mit Geltungsbereich (Mandant, Standort, Bereich) und Gültigkeitszeitraum | ◑ teilweise: ein Rollenmodell mit Vertretungs- und Eskalationslogik ist in der Anwendung gebaut und getestet. Serverseitig sind seit dem 15.08.2026 vier Rollen je Betrieb erzwungen (inhaber, verwalter, mitarbeiter, leser; server/migrationen/0001_mandanten_grundgeruest.sql Zeilen 39 bis 40 und darf_schreiben Zeilen 103 bis 116, darf_verwalten in 0003_konto_und_abgleich.sql Zeilen 41 bis 54). Die feingliedrigen Rechte der Form <ressource>.<aktion>, der Geltungsbereich und der Gültigkeitszeitraum bestehen nur in der Anwendung und werden vom Server nicht geprüft |
| 1.3.2 | Durchsetzung in drei Schichten: die Oberfläche blendet aus (Bequemlichkeit), die Schnittstelle prüft jedes Recht und jeden Geltungsbereich hart vor jeder Änderung (Sicherheit), die Datenbank erzwingt die Trennung (letzte Verteidigungslinie) | ◑ teilweise kritisch: die erste und die dritte Schicht bestehen. Die Oberfläche blendet aus; die Datenbank erzwingt die Trennung über den Zeilenschutz und über entzogene Tabellenrechte (am 23.08.2026 gegen die laufende Instanz geprüft: authenticated hat auf betriebe, mitglieder, einladungen, abonnements und zahlungsvorgaenge nur Leserecht, auf datensaetze select, insert und update, nirgends delete). Die mittlere Schicht besteht nur für die vier Serverrollen und für die Vorgänge, die über Serverfunktionen laufen; eine Schnittstelle, die jedes Recht und jeden Geltungsbereich des Rollenmodells hart prüft, besteht nicht |
| 1.3.3 | Trennung der Personaldaten: die Rolle personalstamm hat Zugriff ausschließlich auf Mitarbeiter- und Qualifikationsdaten, nicht auf Aufträge oder Kosten; umgekehrt erhält die Instandhaltungsleitung für die Zuweisung nur die Antwort „befähigt ja/nein“, nicht den Nachweis selbst | ○ geplant |
| 1.3.4 | Nur-Lese-Rolle auditor für Berufsgenossenschaft, Fachkraft für Arbeitssicherheit und Revision: alles lesen, nichts ändern | ○ geplant |
| 1.3.5 | Fremdfirmenzugang stark eingeschränkt: ausschließlich eigene Aufträge und deren Objekte; keine Stammdaten, keine fremden Kosten, keine anderen Objekte | ○ geplant |
| 1.3.6 | Kein anlassloser vdw-Zugriff. Die Rolle vdw_support ist zeitlich befristet, muss vom Kunden freigeschaltet werden, jede Aktion wird protokolliert und dem Kunden angezeigt; kein Zugriff auf Dokumentinhalte ohne gesonderte Freigabe | ○ geplant kritisch: derzeit nicht vorhanden. Der Dienstschlüssel der laufenden Instanz (service_role) umgeht den Zeilenschutz (am 23.08.2026 geprüft: rolbypassrls ist gesetzt) und liegt bei vdw. Eine Rolle vdw_support, eine Freischaltung durch den Kunden, eine zeitliche Befristung und eine Anzeige der Zugriffe im Mandanten bestehen nicht |
| 1.3.7 | Dokumentzugriff nie über eine öffentliche Adresse. Der Abruf läuft über die Schnittstelle mit Berechtigungsprüfung und anschließender kurzlebiger Weiterleitung (5 Minuten Gültigkeit). Ein nicht erratbarer Ablagepfad ist keine Zugriffskontrolle | ○ geplant kritisch |
| 1.3.8 | Portaldienst mit minimalem Datenzugriff: eigene Datenbankrolle, eigene Sichten, lesend nur die für die jeweilige Sichtbarkeitsstufe freigegebenen Felder, schreibend nur Schadensmeldung, Störung und Dokument. Auf keiner Stufe Zugriff auf Mitarbeiter-, Qualifikations-, Zeitbuchungs-, Stundensatz- und Kostendaten | ○ geplant kritisch |
| 1.3.9 | Aggregierte Produktkennzahlen statt Inhaltszugriff. vdw erhebt Anzahl der Objekte und gebuchte Module je Mandant, niemals Inhalte | ○ geplant |
| 1.3.10 | Vergabe und Entzug von Berechtigungen nach dem Grundsatz der geringsten Rechte, dokumentiert und periodisch überprüft | ○ geplant |
| 1.3.11 | Serverfunktionen mit erweiterten Rechten (SECURITY DEFINER) sind auf das Nötige begrenzt, prüfen die Berechtigung selbst und werden regelmäßig überprüft | ◑ teilweise: zehn solcher Funktionen sind für angemeldete Nutzer über die Schnittstelle aufrufbar (bestellungen_einloesen, betrieb_anlegen, darf_schreiben, darf_verwalten, einladungen_einloesen, ist_mitglied, mitglied_einladen, mitglied_entfernen, mitglieder_ansehen, rolle_aendern); der Sicherheitsprüfer des Anbieters führt sie am 23.08.2026 als Befund authenticated_security_definer_function_executable (Stufe WARN). Das ist eine bewusste Entscheidung: Sie sind der einzige Weg, einen Betrieb anzulegen oder ein Mitglied aufzunehmen, laufen mit festem Suchpfad (set search_path = public, pg_temp), sind public und anon entzogen und prüfen die Berechtigung des Aufrufers jeweils selbst. Es fehlt eine festgelegte, wiederkehrende Überprüfung dieser Funktionen und eine Aufnahme in die Prüfstrecke |
1.4 Trennungskontrolle: getrennte Verarbeitung von Daten unterschiedlicher Zwecke und Mandanten
Dies ist die zentrale Schutzmaßnahme des Produkts. Ein Bruch der Mandantentrennung ist zugleich der schwerste denkbare Vorfall (Risiko R-2 der Architektur).
| Nr. | Maßnahme | Stand |
|---|---|---|
| 1.4.1 | Ein gemeinsames Datenbankschema mit mandant_id als Pflichtfeld in jeder Tabelle mit Mandantenbezug | ◑ teilweise kritisch: das gemeinsame Schema besteht; die Spalte heißt betrieb_id. Am 23.08.2026 gegen die laufende Instanz geprüft: auf mitglieder, datensaetze, einladungen, abonnements und zahlungsvorgaenge ist sie Pflichtfeld, auf bestellungen und bestellzahlungen ist sie nicht als Pflichtfeld angelegt, weil eine Bestellung vor dem Betrieb entsteht. Die übrigen Tabellen der Instanz haben keinen Mandantenbezug |
| 1.4.2 | Zeilenbasierte Zugriffskontrolle (Row-Level-Security) auf jeder Tabelle mit Mandantenbezug, aktiviert und erzwungen (ENABLE und FORCE). Ohne FORCE umgeht der Tabelleneigentümer die Politik stillschweigend | ◑ teilweise kritisch: am 23.08.2026 gegen die laufende Instanz geprüft: auf allen 13 Tabellen ist der Zeilenschutz eingeschaltet (ENABLE). Auf keiner ist er zusätzlich erzwungen (FORCE); der Tabelleneigentümer postgres umgeht die Politik damit weiterhin. Die Anwendung verbindet sich nicht als Eigentümer, siehe Nr. 1.4.3, weshalb der fehlende Zwang heute keine fremden Zeilen sichtbar macht. Er ist gleichwohl nachzuziehen |
| 1.4.3 | Die Anwendung verbindet sich mit einer Datenbankrolle, die weder Tabelleneigentümer noch mit dem Recht zur Umgehung der Politik ausgestattet ist; Migrationen laufen unter einer getrennten Rolle | ✔ umgesetzt kritisch: am 23.08.2026 gegen die laufende Instanz geprüft. Die Anwendung arbeitet unter der Rolle authenticated; diese ist weder Superuser noch mit rolbypassrls ausgestattet und Eigentümer keiner der 13 Tabellen. Eigentümerin aller Tabellen und Rolle der Migrationen ist postgres, eine davon getrennte Rolle |
| 1.4.4 | Der Mandantenkontext wird je Transaktion gesetzt (SET LOCAL), nicht je Sitzung. Damit fällt er am Transaktionsende automatisch zurück | ◑ teilweise kritisch: die laufende Instanz führt gar keine Sitzungsvariable für den Mandanten. Jede Zugriffsregel leitet die Zugehörigkeit je Anfrage aus dem Anmeldemerkmal ab (auth.uid() in ist_mitglied und darf_schreiben, server/migrationen/0001_mandanten_grundgeruest.sql Zeilen 89 bis 133). Ein Kontext, der über eine Anfrage hinaus stehen bleiben könnte, entsteht damit nicht. Dass die Schnittstelle des Anbieters die Anmeldedaten transaktionsgebunden setzt, ist von vdw nicht überprüft |
| 1.4.5 | Der Verbindungspooler läuft ausschließlich im Modus session oder transaction, niemals statement. Im Statement-Modus wirkt die transaktionsgebundene Kontextsetzung nicht und es werden Zeilen fremder Mandanten geliefert. Die Einstellung ist Teil der Infrastrukturdefinition, nicht der Betriebsdokumentation | ○ geplant kritisch: vdw betreibt keinen eigenen Verbindungspooler. Der Zugriff läuft über die REST-Schnittstelle des Unterauftragsverarbeiters; dessen Verbindungsverwaltung ist von vdw nicht überprüft und nicht durch eine Infrastrukturdefinition der vdw GmbH festgelegt |
| 1.4.6 | Die Anwendungsschicht filtert zusätzlich nach mandant_id. Der Datenzugriff läuft über einen Mandantenkontext, der ohne gesetzten Mandanten nicht erzeugt werden kann. Vergessen wird damit zum Übersetzungsfehler, nicht zum Datenleck | ✔ umgesetzt kritisch: der Abgleich erzeugt ohne gesetzten Betrieb keine Sitzung und läuft dann gar nicht (instandio/src/domain/abgleich.ts Zeilen 82 bis 91). Jeder Lesevorgang filtert zusätzlich nach betrieb_id (Zeile 1060), jeder Schreibvorgang setzt sie (Zeile 1760), und ein Gerät, das bereits den Bestand eines anderen Betriebs trägt, verweigert den Abgleich vollständig (Zeilen 1211 bis 1222). Durch Tests abgesichert (abgleich.test.ts: „schreibt den Betrieb und den Nutzer an jede Zeile“, „verweigert den Abgleich, wenn das Gerät den Bestand eines anderen Betriebs trägt“) |
| 1.4.7 | Jeder zusammengesetzte Datenbankindex beginnt mit mandant_id | ◑ teilweise: am 23.08.2026 gegen die laufende Instanz geprüft. Auf den Tabellen mit Mandantenbezug beginnt jeder zusammengesetzte Index mit betrieb_id (datensaetze_pkey, datensaetze_abgleich, mitglieder_pkey, einladungen_je_adresse, zahlungsvorgaenge_nach_betrieb). Eine Ausnahme: bestellzahlungen_nach_bestellung beginnt mit bestellung_id |
| 1.4.8 | Ein eigener Ablagebereich je Mandant im Objektspeicher, Pfad {mandant_id}/{jahr}/{dokument_id} | ○ geplant kritisch: die laufende Instanz führt am 23.08.2026 keinen Objektspeicher (null Ablagebereiche). Dokumente und Fotos verlassen das Endgerät nicht |
| 1.4.9 | Getrennte Umgebungen: Entwicklung, Test, Abnahme und Produktion sind technisch getrennt. Die Abnahmeumgebung erhält keine unveränderten Produktivdaten | ○ geplant kritisch: siehe Prüfpunkt in Anlage 1 Abschnitt 5.2 zur Anonymisierung |
| 1.4.10 | Kein Betrieb von Kundendaten auf Servern mit fremden Produktivsystemen. Der vorhandene Hostinger-Bestandsserver, auf dem eine eigene Buch-Automatisierung der vdw GmbH läuft, wird ausschließlich für Entwicklung und Test ohne Kundendaten verwendet | ○ geplant kritisch: als Betriebsregel festgehalten; die Einhaltung ist zu überwachen |
| 1.4.11 | Automatisch erzeugte Isolationsprüfung über alle Schnittstellenrouten: Der Test liest die Schnittstellenbeschreibung, erzeugt zu jeder Route einen Aufruf mit dem Token von Mandant B auf eine Kennung aus Mandant A und erwartet die Antwort „nicht gefunden“, nicht „kein Zugriff“, weil letztere bereits die Existenz bestätigt. Eine neue Route ohne Isolationsschutz lässt die Prüfstrecke fehlschlagen | ◑ teilweise kritisch: eine Isolationsprüfung von Hand ist am 15.08.2026 gegen die laufende Instanz durchgeführt und in server/README.md Abschnitt 5 festgehalten (fremden Bestand lesen, untergeschobene Betriebskennung, ohne Filter lesen, in fremden Betrieb schreiben, sich selbst einladen, Mitgliedschaft eintragen: jeweils null Zeilen oder HTTP 403). Eine automatisch erzeugte Prüfung über alle Routen, die als Sperre in der Prüfstrecke läuft, besteht nicht |
| 1.4.12 | Prüfskript gegen das Politikverzeichnis der Datenbank: eine neue Tabelle ohne Zugriffspolitik lässt die Prüfstrecke fehlschlagen | ○ geplant kritisch: ein solches Prüfskript besteht nicht. Der Sicherheitsprüfer des Anbieters meldet Tabellen ohne Zugriffsregel (siehe Nr. 1.4.14), ist aber keine Sperre in einer Prüfstrecke der vdw GmbH und läuft nicht bei jeder Änderung |
| 1.4.13 | Penetrationstest mit Schwerpunkt Mandantenisolation und QR-Portal vor dem zweiten Produktivmandanten | ○ geplant kritisch |
| 1.4.14 | Jede Tabelle mit eingeschaltetem Zeilenschutz trägt auch eine ausdrückliche Zugriffsregel, damit die beabsichtigte Sichtbarkeit im Politikverzeichnis ablesbar ist und nicht nur aus dem Fehlen einer Regel folgt | ◑ teilweise: am 23.08.2026 gegen die laufende Instanz geprüft. Auf allen 13 Tabellen ist der Zeilenschutz eingeschaltet; fünf tragen keine Regel (bestellzahlungen, funktionsfehler, meldebremse, pipedrive_vorgaenge, zahlung_meldungen). Sie sind dadurch für anon und authenticated vollständig gesperrt, was der Absicht entspricht: sie werden ausschließlich von Serverfunktionen mit dem Dienstschlüssel beschrieben. Der Sicherheitsprüfer des Anbieters führt sie als Befund rls_enabled_no_policy (Stufe INFO). Es fehlt eine ausdrückliche, sperrende Regel, die diese Absicht festhält |
Warum diese Zeilen so ausführlich sind: Jede einzelne dieser Regeln adressiert einen Fehler, der in Produktion erst unter Last auftritt und dann ein meldepflichtiger Datenschutzvorfall ist. Wird eine davon weggelassen, ist die Mandantentrennung nicht schwächer. Sie ist wirkungslos.
1.5 Pseudonymisierung und Datenminimierung (Art. 32 Abs. 1 lit. a DSGVO)
| Nr. | Maßnahme | Stand |
|---|---|---|
| 1.5.1 | Datensparsames Datenmodell: kein Geburtsdatum, keine Privatanschrift, keine Bankverbindung, keine Personalakte, kein Lichtbild von Beschäftigten | ✔ umgesetzt: im Datenmodell der Anwendung 1.1 und in der Zielarchitektur gleichermaßen |
| 1.5.2 | Anonyme Meldung als Regelfall im QR-Portal; Namens- und Kontaktangabe des Melders freiwillig | ◑ teilweise: das Meldeverfahren ist in der Anwendung angelegt, ein anonym erreichbarer Portaldienst existiert nicht |
| 1.5.3 | Gesalzener Hashwert statt IP-Adresse in Protokollen des Portals, Frist 7 Tage | ○ geplant |
| 1.5.4 | Pseudonymisierung statt Löschung, wo eine Aufbewahrungspflicht dem Löschanspruch entgegensteht: Ersetzung des Personenbezugs (etwa „Prüfer 4711“), Löschung der Zuordnungstabelle nach Fristablauf | ○ geplant: siehe Löschkonzept, Dokument 15 |
| 1.5.5 | Aggregierte Auswertungen als Voreinstellung; personenbezogene Auswertung als abschaltbares Merkmal, im Auslieferungszustand aus | ○ geplant |
| 1.5.6 | Technische Sperre gegen Gesundheitsdaten: Dokumentupload bei Qualifikationen der Kategorie „Eignung“ unterbunden, nur „liegt vor bis TT.MM.JJJJ“, Hinweistext im Formular | ○ geplant kritisch: derzeit nicht vorhanden. Die Anwendung 1.1 erlaubt zu jedem Zertifikat den Upload einer beliebigen Nachweisdatei ohne Kategorieprüfung |
| 1.5.7 | Trennung der Vertrags- und Zahlungsdaten (eigene Verantwortlichkeit von vdw) von den Auftragsdaten des Kunden | ◑ teilweise: Vertrags- und Zahlungsdaten liegen in eigenen Tabellen (bestellungen, bestellzahlungen, zahlungsvorgaenge, abonnements), getrennt vom Fachbestand des Kunden in datensaetze, und authenticated erreicht sie nicht schreibend. Sie liegen jedoch in derselben Datenbank und beim selben Unterauftragsverarbeiter; eine Trennung auf Instanz- oder Anbieterebene besteht nicht |
Abhängige Textstellen, am 07.08.2026 berichtigt. Dokument 22 (Datenschutzhinweise zur Anwendung) hatte in Ziffer 5.1 behauptet, der Upload sei für die Kategorie „Eignung“ technisch unterbunden. Diese Aussage ist gestrichen und durch eine ausdrückliche organisatorische Anweisung ersetzt; § 3 Absatz 3 des Vertrags stellt zusätzlich klar, dass eine technische Sperre nicht zugesichert wird. Sobald 1.5.6 den Stand
✔trägt, sind Dokument 22 Ziffern 5.1 und 10.3 sowie § 3 Absatz 3 des Vertrags zurückzustellen. Bis dahin ist jeder Kunde vor Aufnahme der Nutzung schriftlich und gegengezeichnet zu belehren.
2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)
2.1 Weitergabekontrolle: Schutz bei Übertragung und Transport
| Nr. | Maßnahme | Stand |
|---|---|---|
| 2.1.1 | Verschlüsselung im Transport: ausschließlich TLS ab Version 1.2, HSTS, moderne Verschlüsselungsverfahren; keine unverschlüsselten Zugänge | ◑ teilweise kritisch: am 23.08.2026 gegen die laufenden Adressen geprüft. Die Datenschnittstelle beantwortet Anfragen über TLS 1.3, weist TLS 1.1 ab und sendet Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. instandio.de und app.instandio.de leiten unverschlüsselte Aufrufe dauerhaft auf HTTPS um (HTTP 301), senden aber keinen HSTS-Kopf; die Zeile ist in webseite/public/.htaccess und instandio/public/.htaccess auskommentiert |
| 2.1.2 | Verschlüsselung im Ruhezustand für Datenbank, Objektspeicher und Sicherungen | ○ geplant kritisch: die Verschlüsselung der Datenträger obliegt dem Unterauftragsverarbeiter und ist von vdw nicht überprüft. Ein Objektspeicher und eine eigene Sicherung bestehen nicht |
| 2.1.3 | Strenge Inhaltssicherheitsrichtlinie ohne Freigabe eingebetteter Skripte, dazu X-Content-Type-Options, Referrer-Policy, Permissions-Policy; das Einbetten in fremde Seiten ist ausschließlich für Microsoft-Hosts zugelassen | ◑ teilweise: am 23.08.2026 gegen instandio.de und app.instandio.de geprüft. Ausgeliefert werden X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin und Permissions-Policy: geolocation=(), microphone=(), camera=(), interest-cohort=(). Eine Inhaltssicherheitsrichtlinie wird nicht ausgeliefert, weder als Kopfzeile noch im Dokument, und eine Regel für das Einbetten in fremde Seiten besteht nicht |
| 2.1.4 | Ratenbegrenzung am QR-Portal: je Token 60 Aufrufe je Stunde, je IP-Adresse 300; Meldungen je Token 5 je Stunde, je IP-Adresse 20 | ○ geplant |
| 2.1.5 | Aufzählungsschutz: ein unbekanntes Token liefert immer dieselbe neutrale Seite, nie eine Unterscheidung zwischen „nicht gefunden“ und „kein Zugriff“ | ○ geplant |
| 2.1.6 | Kein Zwischenspeicher im Portal. Der anonym erreichbare Portaldienst arbeitet ohne Dienstmitarbeiter-Skript im Browser, weil ein zwischenspeicherndes Portal auf geteilten Geräten ein Datenleckrisiko ist | ○ geplant |
| 2.1.7 | Keine Suchmaschinenindizierung des Portals (X-Robots-Tag: noindex, nofollow und robots.txt) | ○ geplant |
| 2.1.8 | E-Mail-Versand mit eigener Absenderdomäne und den Verfahren SPF, DKIM und DMARC; Zustellprotokoll je Nachricht, Wiederholung bei Fehlschlag, sichtbare Anzeige fehlgeschlagener Zustellungen | ◑ teilweise: der Versand läuft seit dem 21.08.2026 über das eigene Postfach kontakt@instandio.de im Microsoft-365-Mandanten der vdw GmbH, angesteuert durch die Serverfunktionen auth-mail und formular-mail. Am 23.08.2026 im Namensdienst geprüft: SPF ist gesetzt und schließt den Microsoft-Versandweg ein, DKIM ist über die Auswählerverweise selector1 und selector2 eingerichtet, ein DMARC-Eintrag fehlt (_dmarc.instandio.de ohne Datensatz). Ein Zustellprotokoll je Nachricht, eine Wiederholung bei Fehlschlag und eine sichtbare Anzeige fehlgeschlagener Zustellungen bestehen nicht |
| 2.1.9 | Getrennter Prozess für die PDF-Erzeugung ohne Datenbankzugriff; er erhält fertiges HTML und signierte Bildverweise | ○ geplant |
| 2.1.10 | Datenträger und Endgeräte mit Kundendatenbezug werden vor Aussonderung sicher gelöscht beziehungsweise vernichtet | ○ geplant |
2.2 Eingabekontrolle: Nachvollziehbarkeit von Eingabe, Änderung und Entfernung
| Nr. | Maßnahme | Stand |
|---|---|---|
| 2.2.1 | Ereignisprotokoll audit_event, ausschließlich anfügend: Änderungen und Löschungen sind per Trigger und Rechteentzug technisch ausgeschlossen. Festgehalten werden Zeitpunkt, handelnde Person mit Anzeigenamen als Schnappschuss, Entität, Aktion, geändertes Feld mit altem und neuem Wert, Quelle und Korrelationskennung | ○ geplant kritisch: eine Tabelle audit_event besteht auf der laufenden Instanz am 23.08.2026 nicht. Serverseitig nachvollziehbar sind allein Zeitpunkt und handelnde Person der letzten Änderung je Datensatz, siehe Nr. 2.2.2. Eine Feldhistorie mit altem und neuem Wert und ein anfügendes Protokoll bestehen nicht |
| 2.2.2 | Historisierung auf allen fachlichen Tabellen: erstellt am und von, geändert am und von, Versionszähler als optimistische Sperre | ◑ teilweise: auf datensaetze setzt der Auslöser setze_aenderungsdaten bei jedem insert und update serverseitig geaendert_am und geaendert_von (server/migrationen/0003_konto_und_abgleich.sql Zeilen 229 bis 245). Die Uhr des Endgeräts spielt dabei keine Rolle. Es fehlen: erstellt am und von, ein Versionszähler als optimistische Sperre und die Historisierung der übrigen Tabellen |
| 2.2.3 | Kein hartes Löschen im Fachbetrieb. Fachliche Datensätze werden über einen Status außer Kraft gesetzt; hartes Löschen erfolgt ausschließlich über das Löschkonzept | ◑ teilweise: auf dem Server ist hartes Löschen technisch ausgeschlossen. Am 23.08.2026 gegen die laufende Instanz geprüft: weder anon noch authenticated haben auf irgendeiner Tabelle ein delete-Recht; gelöscht wird über den Vermerk geloescht_am (server/migrationen/0001_mandanten_grundgeruest.sql Zeilen 65 bis 68 und 135). In der Anwendung 1.1 löscht das Entfernen einer Anlage die zugehörigen Prüfungen, Meldungen, Aufträge und Dokumente im lokalen Bestand weiterhin unwiderruflich mit |
| 2.2.4 | Begründungspflichten: Aufhebung einer Sperre, Ablehnung einer Meldung und Zuweisung ohne Befähigung sind ohne Begründung nicht möglich; die Begründung wird protokolliert | ✔ umgesetzt: in der Anwendung 1.1 erzwungen und durch Tests abgesichert |
| 2.2.5 | Schnappschusspflicht für Nachweise: Prüfvorschrift, Prüfpunkttext, Stundensatz und Befähigungsstand werden beim Vorgang mitgeschrieben, nicht nur verknüpft. Sonst verändert ein späteres Katalogupdate rückwirkend alte Protokolle | ◑ teilweise: für Prüferbefähigung und Stundensatz in der Anwendung angelegt; ein versioniertes Rechtskataster mit Schnappschuss existiert nicht |
| 2.2.6 | Verkettetes Ereignisprotokoll: jeder Eintrag trägt die Prüfsumme des vorherigen; eine nachträgliche Änderung, Löschung oder Einfügung macht alle folgenden Prüfsummen ungültig | ◑ teilweise: mit einer wesentlichen Einschränkung, siehe Kasten |
| 2.2.7 | Serverseitige Prüfung jeder Geschäftsregel. Eine Regel, die nur in der Oberfläche steht, existiert nicht | ◑ teilweise kritisch: die Zugriffs- und Vertragsregeln werden serverseitig geprüft: Zugehörigkeit und Rolle über den Zeilenschutz, der Schutz des letzten Inhabers und die Berechtigung zum Einladen in den Serverfunktionen (0003_konto_und_abgleich.sql), die Zahlweise über eine Prüfregel der Tabelle und die Modulkennungen über modulkennungen_pruefen() (0004_bestellung_einloesen.sql). Die fachlichen Regeln (Fristenrechnung, Mängelkette, Befähigung, Bewertungsschlüssel) laufen ausschließlich im Browser; der Server nimmt den Fachinhalt als jsonb entgegen, ohne ihn zu prüfen |
| 2.2.8 | Idempotenz beim Abgleich offline erfasster Vorgänge, damit eine wiederholte Übertragung keine Doppelbuchung erzeugt | ✔ umgesetzt: das Schreiben ist ein insert … on conflict (betrieb_id, art, id) do update auf den Primärschlüssel der Tabelle (server/migrationen/0001_mandanten_grundgeruest.sql Zeile 70, instandio/src/domain/abgleich.ts Zeilen 1026 bis 1032). Eine Vormerkung wird erst nach dem bestätigten Schreiben aus der Warteschlange genommen (Zeile 1749), und das Gerät merkt sich einen Abdruck des selbst Hochgeladenen, damit es die eigenen Zeilen beim nächsten Lauf nicht für fremde Änderungen hält (Zeilen 256 bis 266). Ein zweiter Versuch desselben Pakets ändert damit nichts. Durch Tests abgesichert (abgleich.test.ts) und am 15.08.2026 gegen die laufende Instanz geprüft (server/README.md Abschnitt 5) |
| 2.2.9 | Eingabevalidierung mit demselben Schema auf Client und Server, damit eine in der Halle erfasste Prüfung beim Abgleich nicht abgelehnt wird | ○ geplant |
| 2.2.10 | Importe: nicht zuordenbare Zeilen werden als „zu prüfen“ geführt und nie stillschweigend verworfen; ein Import mit null erkannten Zeilen gilt immer als Fehler | ✔ umgesetzt: in der Anwendung 1.1 gebaut und getestet |
Grenze des Ereignisprotokolls: ausdrücklich benannt
Das in der Anwendung 1.1 gebaute Ereignisprotokoll verkettet die Einträge über eine Prüfsumme nach dem Verfahren FNV-1a mit 32 Bit. Dieses Verfahren ist kein kryptographisches Hashverfahren. Es ist bewusst so gewählt, weil die kryptographische Schnittstelle des Browsers ausschließlich asynchron arbeitet.
Daraus folgen zwei Aussagen, die im Vertrag nicht überschritten werden dürfen:
- Das Protokoll ist nicht fälschungssicher. Wer Zugriff auf den lokalen Speicher des Geräts hat, kann die gesamte Kette neu berechnen. Zusätzlich erlaubt ein 32-Bit-Prüfwert das gezielte Erzeugen von Kollisionen mit geringem Aufwand.
- Was es leistet: versehentliche und beiläufige Änderungen sichtbar machen, der praktisch häufigste Fall.
Der Begriff „revisionssicher“ darf gegenüber Kunden für diesen Stand nicht verwendet werden. Revisionssicherheit im Sinne einer Beweiskraft gegenüber Berufsgenossenschaft oder Gericht setzt den Serverbetrieb mit getrenntem Schreibrecht, ein anfügendes Datenbankprotokoll und ein kryptographisches Verfahren voraus.
2.3 Dateiverarbeitung
| Nr. | Maßnahme | Stand |
|---|---|---|
| 2.3.1 | Typerkennung über die Dateisignatur, nicht über die Dateiendung | ○ geplant |
| 2.3.2 | Virenscan jeder hochgeladenen Datei vor der Freigabe; bis zum Ergebnis ist die Datei nicht abrufbar | ○ geplant kritisch: ein Anbieter ist nicht ausgewählt, siehe Anlage 3 |
| 2.3.3 | EXIF-Entfernung aus Bildern (Standortdaten in Werksfotos sind zugleich ein Datenschutz- und ein Betriebsgeheimnisproblem) | ○ geplant: in der Anwendung 1.1 gehen Metadaten beim Verkleinern über die Zeichenflächen-Schnittstelle des Browsers technisch bedingt verloren; das ist ein Nebeneffekt, keine geprüfte Maßnahme |
| 2.3.4 | Größen- und Mengenbegrenzung je Upload (höchstens 3 Bilder, je 5 MB, nur Bildformate im Portal) | ◑ teilweise: Größengrenzen bestehen in der Anwendung; Formatprüfung über die Signatur fehlt |
| 2.3.5 | Prüfsumme (SHA-256) je abgelegter Datei zur Erkennung nachträglicher Veränderung | ○ geplant |
3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b und c DSGVO)
| Nr. | Maßnahme | Stand |
|---|---|---|
| 3.1 | Punktgenaue Wiederherstellung der Datenbank über 35 Tage | ○ geplant kritisch |
| 3.2 | Wöchentlicher Vollauszug in einen getrennten Speicherbereich, nicht im selben Abonnement wie das Produktivsystem | ○ geplant kritisch |
| 3.3 | Wöchentliche, automatisierte Wiederherstellungsprobe in der Abnahmeumgebung. Eine ungeprüfte Sicherung ist keine Sicherung. Die Probe gehört in die Auslieferungsstrecke, nicht in eine Betriebsanweisung, die niemand liest | ○ geplant kritisch |
| 3.4 | Versionierung und vorläufiges Löschen im Objektspeicher; Nachweisdokumente zusätzlich georedundant | ○ geplant |
| 3.5 | Zonenredundante Hochverfügbarkeit der Datenbank | ○ geplant |
| 3.6 | Getrennter Betrieb von Anwendung und Datenbank, damit ein Ausfall nicht beides gleichzeitig mitnimmt | ✔ umgesetzt kritisch: die Anwendung wird als statische Programmdateien über den Webspace unter app.instandio.de ausgeliefert (instandio/skripte/deploy.mjs), die Datenbank läuft bei der Supabase Pte. Ltd. in Frankfurt am Main. Zwei getrennte Anbieter, zwei getrennte Ausfälle. Am 23.08.2026 sind beide Adressen einzeln abgefragt worden |
| 3.7 | Betriebsüberwachung: Anwendungsprotokolle, Fehlermeldungen mit Aufrufkette, Erreichbarkeitsprüfung von außen, Statusseite für Kunden | ○ geplant: die laufende Instanz führt eine Tabelle funktionsfehler, in der Fehler der Serverfunktionen festgehalten werden. Eine Auswertung, eine Benachrichtigung, Anwendungsprotokolle mit Aufrufkette, eine Erreichbarkeitsprüfung von außen und eine Statusseite bestehen nicht; niemand wird von einem Eintrag in Kenntnis gesetzt |
| 3.8 | Fachliche Wächter: sie sind wichtiger als die technischen, weil der gefährlichste Fehler eines Fristenüberwachungssystems der stille ist: ein nicht versandter Fristenalarm sieht aus wie „keine Frist fällig“. Überwacht werden: der nächtliche Fristenlauf ist durchgelaufen und hat n Benachrichtigungen erzeugt; keine Benachrichtigung steht länger als eine Stunde auf „fehlgeschlagen“; kein Mandant ohne Sicherung in den letzten 24 Stunden; Objektzählerabgleich ohne Abweichung | ○ geplant kritisch |
| 3.9 | Kein stiller Fehlschlag. Eine nicht zugestellte Benachrichtigung wird im Produkt sichtbar gemacht, nicht nur protokolliert | ○ geplant |
| 3.10 | Rücknahme von Auslieferungen: Anwendungsstände sind jederzeit umschaltbar; Datenbankänderungen erfolgen ausschließlich erweiternd, Entfernungen frühestens im übernächsten Stand | ○ geplant |
| 3.11 | Belastungstest mit dem Zehnfachen des Pilotbestands vor der Mandantenfähigkeit | ○ geplant |
| 3.12 | Offline-Betrieb mit Ausgangswarteschlange auf dem Endgerät, sichtbarer Zähler, Warnung ab 24 Stunden ohne Übertragung, Export der offenen Vorgänge als Datei | ◑ teilweise: die Anwendung ist als installierbare Webanwendung gebaut, und seit dem 15.08.2026 besteht eine Ausgangswarteschlange mit Serverabgleich (instandio/src/domain/abgleich.ts): Vormerkungen überdauern das Schließen der Anwendung, der Abgleich läuft bei Rückkehr der Verbindung, beim Sichtbarwerden des Fensters und im Takt, und die Zahl der offenen Änderungen ist in der Oberfläche sichtbar (abgleichstand(), Zeilen 1862 bis 1885). Es fehlen: eine Warnung ab 24 Stunden ohne Übertragung und der Export der offenen Vorgänge als Datei |
| 3.13 | Keine Verfügbarkeitszusage in Prozent, solange nicht mindestens sechs Monate gemessen wurde; stattdessen zugesagte Reaktionszeiten im Support | ○ geplant: bewusste Entscheidung, in der Leistungsbeschreibung zu verankern |
Der wichtigste Satz dieses Abschnitts: Bei einem Nachweissystem ist ein verlorenes Prüfprotokoll ein rechtlich verlorener Nachweis, und der Kunde hat keine zweite Quelle, weil er die Ordner gerade abgeschafft hat. Die Verfügbarkeitsmaßnahmen sind hier keine Nebensache.
4. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art. 32 Abs. 1 lit. d DSGVO)
4.1 Datenschutzmanagement
| Nr. | Maßnahme | Stand |
|---|---|---|
| 4.1.1 | Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 Abs. 1 und Abs. 2 DSGVO, getrennt geführt | ◑ teilweise: als Entwurf erstellt (Dokument 14), nicht förmlich in Kraft gesetzt |
| 4.1.2 | Löschkonzept mit Fristen, Auslöser, Zuständigkeit und technischer Umsetzung | ◑ teilweise: als Entwurf erstellt (Dokument 15), technisch nicht umgesetzt |
| 4.1.3 | Meldeprozess für Datenschutzvorfälle mit Eskalationskette, Zeitvorgaben und Erfassungsformular | ◑ teilweise: als Entwurf erstellt (Dokument 16), nicht erprobt |
| 4.1.4 | Verpflichtung auf Vertraulichkeit aller Beschäftigten, dokumentiert | ○ geplant kritisch |
| 4.1.5 | Jährliche Datenschutzschulung mit Teilnahmenachweis | ○ geplant |
| 4.1.6 | Datenschutzbeauftragter | ○ geplant: nicht bestellt. Eine Pflicht nach § 38 Abs. 1 Satz 1 BDSG besteht bei rund fünf Beschäftigten nicht. Eine freiwillige Bestellung ist zum Serverbetrieb vorgesehen; sie kann zur Pflicht werden, sobald Art.-9-Daten regelmäßig verarbeitet werden (siehe 1.5.6) oder eine Datenschutz-Folgenabschätzung zu bejahen ist. Siehe § 12 des Vertrags |
| 4.1.7 | Jährliche Überprüfung dieser Anlage auf Aktualität und Angemessenheit sowie anlassbezogen bei wesentlichen Änderungen | ○ geplant |
4.2 Auftragskontrolle: Steuerung der Unterauftragsverarbeiter
| Nr. | Maßnahme | Stand |
|---|---|---|
| 4.2.1 | Auftragsverarbeitungsverträge mit allen eigenen Dienstleistern, die Kundendaten verarbeiten | ◑ teilweise kritisch: für den einzigen beauftragten Dienstleister, die Supabase Pte. Ltd., gilt seit dem 15.08.2026 ein Auftragsverarbeitungsvertrag (Anlage 3 Abschnitt 1). Er wird nicht gesondert unterzeichnet, sondern gilt mit der Annahme der Nutzungsbedingungen; maßgeblich ist der Tag der Projektanlage. Die Bewertung des Drittlandbezugs steht aus (Anlage 3 Prüfpunkte 0.2 bis 0.4). Für die noch nicht vergebenen Leistungen (Objektspeicher, Datensicherung, Virenscan, Betriebsüberwachung) besteht kein Vertrag, weil kein Dienstleister beauftragt ist |
| 4.2.2 | Eignungsprüfung vor der Beauftragung und danach jährlich, dokumentiert | ○ geplant: für die Beauftragung der Supabase Pte. Ltd. am 15.08.2026 liegt keine dokumentierte Eignungsprüfung vor. Sie ist nachzuholen und in recht/nachweise/ abzulegen; ein jährlicher Turnus ist festzulegen |
| 4.2.3 | Liste der Unterauftragsverarbeiter im Produkt einsehbar, Änderungen werden mit 30 Tagen Vorlauf angekündigt | ○ geplant |
| 4.2.4 | Prüfung der Drittlandthematik vor jeder Beauftragung | ◑ teilweise: für die Supabase Pte. Ltd. ist der Drittlandbezug in Anlage 3 Prüfpunkt 0 ausgewiesen (Sitz in Singapur, kein Angemessenheitsbeschluss, Absicherung über die im Auftragsverarbeitungsverzeichnis des Anbieters einbezogenen Standardvertragsklauseln), samt Herkunft und Abrufdatum der Angaben. Die Prüfung ist jedoch nach der Beauftragung erfolgt, und die fachkundige Bewertung (Anlage 3 Prüfpunkte 0.2 bis 0.4, darunter die Frage einer Übermittlungsfolgenabschätzung) steht aus |
4.3 Sichere Entwicklung und Prüfstrecke
| Nr. | Maßnahme | Stand |
|---|---|---|
| 4.3.1 | Automatisierte Testsuite mit Einheits-, Integrations-, Vertrags-, Oberflächen-, Last- und Sicherheitstests | ◑ teilweise: 1247 Tests in 22 Dateien, am 23.08.2026 vollständig durchgelaufen. Sie decken die Fachlogik der Anwendung 1.1 ab (Fristenrechnung, Mängelkette, Befähigung, Protokollkette, Import, Kennzahlen, Gefahrstoffe, Abrechnung) und seit dem 15.08.2026 auch die Kontoschicht und den Abgleich gegen einen nachgebildeten Server (konto.test.ts mit 71, abgleich.test.ts mit 49 Tests). Es fehlen weiterhin Integrations-, Vertrags-, Oberflächen-, Last- und Sicherheitstests gegen die laufende Instanz; kein Test spricht mit der echten Datenbank |
| 4.3.2 | Sicherheits- und Isolationssuite als Sperre in der Prüfstrecke | ○ geplant kritisch |
| 4.3.3 | Abhängigkeitsprüfung in der Prüfstrecke mit Blockade bei kritischen Befunden | ○ geplant |
| 4.3.4 | Trennung von Bauen und Freigeben: Freigabe in die Produktion nur mit ausdrücklicher manueller Zustimmung | ◑ teilweise: die Auslieferung erfolgt ausschließlich von Hand und nur mit dem ausdrücklichen Schalter --ueberschreiben; ohne ihn zeigt das Skript lediglich, was übertragen würde (instandio/skripte/deploy.mjs, webseite/skripte/deploy.mjs). Eine Prüfstrecke, die baut, prüft und die Freigabe als eigenen Schritt davon trennt, besteht nicht; es gibt keine Sperre, die eine Auslieferung mit fehlgeschlagenen Tests verhindert |
| 4.3.5 | Funktionale Verifikation vor der Freigabe: was ein Mensch anklickt, scannt oder ausdruckt, gilt erst nach Prüfung des tatsächlichen Endzustands als fertig | ✔ umgesetzt: als verbindliche Arbeitsregel im Projekt etabliert und angewandt |
| 4.3.6 | Quellcodeverwaltung außerhalb von Synchronisationsordnern, Sicherung ausschließlich im entfernten Verzeichnis, Prüfung nach jedem Übertragen | ✔ umgesetzt: als Arbeitsregel etabliert; für Instandio ist das Repository noch anzulegen |
| 4.3.7 | Eigene Freigabestrecke für das Rechtskataster mit fachlicher Freigabe im Vier-Augen-Prinzip, weil ein Katasterstand kein Programmstand ist und Fristen bei allen Kunden gleichzeitig ändert | ○ geplant |
| 4.3.8 | Der Stand des Servers ist vollständig aus dem Verzeichnis im Quellcode wiederherstellbar, damit ein Verlust der Instanz kein Verlust des Aufbaus ist und jede Änderung nachvollziehbar bleibt | ◑ teilweise: die Migrationen 0001 bis 0004 decken betriebe, mitglieder, datensaetze, einladungen und bestellungen samt Zeilenschutz, Rechten und Serverfunktionen ab. Am 23.08.2026 gegen die laufende Instanz geprüft: sie führt 13 Tabellen, für acht davon (abonnements, bestellzahlungen, funktionsfehler, kontaktanfragen, meldebremse, pipedrive_vorgaenge, zahlung_meldungen, zahlungsvorgaenge) liegt keine Migration vor. Von den acht aktiven Serverfunktionen liegt nur bestellung-bezahlen als Quelldatei im Verzeichnis. Der Stand ist damit nicht vollständig wiederherstellbar; server/README.md Abschnitt 3 behauptet das Gegenteil und ist nachzuziehen |
4.4 Vorfallbehandlung
| Nr. | Maßnahme | Stand |
|---|---|---|
| 4.4.1 | Meldung an den Kunden unverzüglich nach Bekanntwerden, in der Regel binnen 24 Stunden, an Wochenenden und gesetzlichen Feiertagen binnen 48 Stunden (§ 10 Absatz 1 des Vertrags) | ○ geplant: Prozess entworfen, siehe Dokument 16; eine Rufbereitschaft besteht nicht |
| 4.4.2 | Dokumentation aller Vorfälle einschließlich Bewertung und Abhilfemaßnahmen | ○ geplant |
| 4.4.3 | Jährliche Übung des Meldeprozesses anhand eines fiktiven Falls | ○ geplant |
| 4.4.4 | Ein Bruch der Mandantentrennung gilt stets als meldepflichtiger Vorfall | ○ geplant: als Regel festgelegt |
5. Was diese Anlage bewusst nicht zusichert
Damit kein Missverständnis entsteht, hier ausdrücklich benannt:
| Nicht zugesichert | Grund |
|---|---|
| Eine Zertifizierung nach ISO/IEC 27001, TISAX, BSI C5 oder einer vergleichbaren Norm bei der vdw GmbH | Es besteht keine und ist derzeit keine geplant. Zertifizierungen der Unterauftragsverarbeiter bleiben davon unberührt |
| Ein bestandener Penetrationstest | Noch nicht durchgeführt |
| Eine Verfügbarkeit in Prozent | Bewusst nicht zugesagt, solange nicht mindestens sechs Monate gemessen wurde |
| Revisionssicherheit im Sinne einer Beweiskraft gegenüber Gericht oder Behörde | Siehe Kasten in Abschnitt 2.2 |
| Ein bestellter Datenschutzbeauftragter | Noch nicht entschieden |
| Verschlüsselung der Fachdaten auf Feldebene | Nicht vorgesehen; geschützt wird über Transport-, Ruhezustands- und Zugriffsverschlüsselung |
| Ein Rechenzentrumsstandort in Deutschland für Entwicklungs- und Testumgebungen | Der Standort des vorhandenen Bestandsservers liegt innerhalb der EU; eine Festlegung auf Deutschland wird für Entwicklungs- und Testumgebungen nicht zugesichert, siehe Anlage 3 |
| Ein Abgleich gewählter Kennwörter gegen bekannt gewordene Passwortlisten | Im Anmeldedienst abgeschaltet, siehe Nr. 1.2.12 |
| Eine Gültigkeit des per E-Mail versandten Einmalkennworts von höchstens einer Stunde | Die eingestellte Gültigkeit liegt darüber, siehe Nr. 1.2.11 |
| Ein anfügendes Ereignisprotokoll auf dem Server | Eine Tabelle audit_event besteht auf der laufenden Instanz nicht, siehe Nr. 2.2.1. Das Protokoll der Anwendung ist kein Ersatz, siehe den Kasten in Abschnitt 2.2 |
| Eine vollständige Wiederherstellbarkeit des Serverstands aus dem Quellcodeverzeichnis | Ein Teil der Tabellen und Serverfunktionen der laufenden Instanz liegt dort nicht vor, siehe Nr. 4.3.8 |
Änderungsverzeichnis
| Version | Datum | Änderung | Bearbeiter |
|---|---|---|---|
| 1.2 | 30.08.2026 | Ziffer 0.1: Angabe zur Nutzung ohne Konto auf die Anmeldepflicht ab dem 30.08.2026 umgestellt; das Objektportal hinter dem QR-Code bleibt der einzige vorgesehene Zugang ohne Konto, ein Portaldienst besteht nicht. Ziffer 0.2 um die Reichweite dieser Fortschreibung ergänzt. Kein Umsetzungsstand einer Maßnahme geändert | vdw GmbH |
| 1.1 | 23.08.2026 | Umsetzungsstand vollständig gegen die laufende Instanz neu erhoben. Höhergestuft auf ✔: Nr. 1.2.10, 1.4.3, 1.4.6, 2.2.8, 3.6. Höhergestuft auf ◑: Nr. 1.2.9, 1.3.2, 1.4.1, 1.4.2, 1.4.4, 1.4.7, 1.4.11, 1.5.7, 2.1.1, 2.1.3, 2.1.8, 2.2.2, 2.2.7, 4.2.1, 4.2.4, 4.3.4. Neu aufgenommen: Nr. 1.2.11, 1.2.12, 1.3.11, 1.4.14, 4.3.8. Ziffer 0.1 und 0.3 fortgeschrieben, Abschnitt 5 um vier Nichtzusicherungen ergänzt | vdw GmbH |
| 1.1 | 15.08.2026 | Serverbetrieb aufgenommen: Supabase Pte. Ltd. als Unterauftragsverarbeiter in Anlage 3, Drittlandbezug ausgewiesen, Vorbemerkung auf den tatsächlichen Stand umgestellt | vdw GmbH |
| 1.0-Entwurf | 07.08.2026 | Ersterstellung mit vollständiger Kennzeichnung des Umsetzungsstands | vdw GmbH |
Änderungsprotokoll
| Datum | Geänderte Abschnitte | Behobener Befund |
|---|---|---|
| 07.08.2026 | Neuer Abschnitt 0.2.1: diese Anlage ausdrücklich als Prüfmaßstab für alle übrigen Dokumente festgelegt; Reichweite und Grenzen der Freizeichnung in § 6 Absatz 2 des Vertrags benannt | B-01, B-02, B-03 |
| 07.08.2026 | Prüfpunkt zu Nr. 1.5.6: abhängige Textstellen benannt und der Stand ihrer Berichtigung in Dokument 22 und § 3 Absatz 3 des Vertrags festgehalten | B-01, B-05 |
| 07.08.2026 | Nr. 4.1.6: Platzhalter durch die Feststellung ersetzt, dass kein Datenschutzbeauftragter bestellt und keine Bestellpflicht gegeben ist, mit den Bedingungen, unter denen sie entstehen kann | Auflage: keine Platzhalter in Vertragsanlagen |
| 07.08.2026 | Nr. 4.4.1: Meldefrist an die neue Fassung des § 10 Absatz 1 des Vertrags angeglichen (Regelfrist 24 Stunden, 48 Stunden an Wochenenden und Feiertagen) | B-07 |
| 23.08.2026 | Ziffer 0.1 auf den Serverbetrieb fortgeschrieben (Datenbank, Anmeldung und Rollen bei der Supabase Pte. Ltd. seit dem 15.08.2026, Frankfurt am Main); jede Maßnahme der Abschnitte 1 bis 4 gegen die laufende Instanz, die Migrationen in server/migrationen/, die Serverfunktionen in server/funktionen/ und die Fachschicht in instandio/src/domain/ geprüft. Belege: Abfrage des Politik-, Rechte- und Rollenverzeichnisses der Datenbank am 23.08.2026, Sicherheitsprüfer des Anbieters, Abfrage der ausgelieferten Kopfzeilen von instandio.de und app.instandio.de, Namensdienstabfrage zu SPF, DKIM und DMARC, vollständiger Testlauf mit 1247 Tests. Fünf Maßnahmen auf ✔, sechzehn auf ◑ gestuft; fünf Maßnahmen neu aufgenommen (Nr. 1.2.11, 1.2.12, 1.3.11, 1.4.14, 4.3.8), darunter die vier offenen Befunde des Sicherheitsprüfers. Testzahl in Nr. 4.3.1 von 637 auf 1247 berichtigt. Zählung in Ziffer 0.3 maschinell neu ausgezählt | Erhebung vom 23.08.2026 |
| 23.08.2026 | Abschnitt 0.2: Erhebungsstand auf den 23.08.2026 fortgeschrieben; Abschnitt 5: Angabe zum Standort des Bestandsservers von „ungeprüft“ auf „innerhalb der EU“ umgestellt, die Nichtzusicherung eines Standorts in Deutschland bleibt bestehen; Kopfzeile fortgeschrieben; Gedankenstriche aufgelöst und Anführungszeichen vereinheitlicht | Entscheidung der Geschäftsführung vom 23.08.2026, Redaktion |
| 30.08.2026 | Ziffer 0.1, letzter Aufzählungspunkt: die Angabe, wer Instandio ohne Konto nutze, arbeite ausschließlich im lokalen Speicher (localStorage) seines Endgeräts, die Daten verließen das Gerät nicht und vdw verarbeite keine Daten für ihn, ist gestrichen und durch den Stand seit dem 30.08.2026 ersetzt: Die Anwendung ist nur nach Anmeldung nutzbar; ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code, für das kein Portaldienst besteht (Nr. 1.3.8, 1.5.3, 2.1.6 unverändert ○ geplant). Überschrift der Ziffer 0.1 und Reichweite der Angabe in Ziffer 0.2 entsprechend fortgeschrieben. Kein Umsetzungsstand einer Maßnahme geändert | Entscheidung der Geschäftsführung vom 30.08.2026: Die Anwendung ist nur nach Anmeldung nutzbar |
Anlage 3: Unterauftragsverarbeiter
nach Artikel 28 Absatz 2 und 4 DSGVO · Produkt: Instandio · Auftragsverarbeiter: vdw GmbH
Fassung: 1.2 · Stand 30.08.2026 · Anlage zum Auftragsverarbeitungsvertrag
0. Der Stand in einem Satz
Seit dem 15.08.2026 betreibt vdw einen Server, und die Supabase Pte. Ltd. ist als Unterauftragsverarbeiter beauftragt. Seit dem 30.08.2026 ist die Anwendung nur nach Anmeldung nutzbar; eine Nutzung der Anwendung ohne Konto, die davon nicht berührt wäre, gibt es nicht mehr. Ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code am Objektetikett: Anzeige des Objekts und Abgabe einer Meldung; ein Portaldienst besteht bisher nicht. Sobald ein Kunde ein Konto anlegt, werden seine Daten auf einem Server in Frankfurt am Main verarbeitet, den die Supabase Pte. Ltd. betreibt.
Zu klären, bevor der erste Kunde ein Konto anlegt:
| Nr. | Frage | Wer |
|---|---|---|
| entfällt | ||
| 0.2 | Genügen die einbezogenen Standardvertragsklauseln, oder ist zusätzlich eine Übermittlungsfolgenabschätzung (TIA) nach Art. 46 DSGVO zu erstellen? | Fachkundige Prüfung |
| 0.3 | Reicht die im Anbieterkonto gewählte Region eu-central-1 vertraglich aus, oder ist der Verarbeitungsort gesondert zu vereinbaren? | Olaf mit fachkundiger Prüfung |
| 0.4 | Ist ein Anbieter mit Sitz in der EU vorzuziehen, um den Drittlandbezug ganz zu vermeiden? | Geschäftsführung |
Diese Anlage ist als Vertragsbestandteil vollständig und darf einem Kunden vorgelegt werden. Die Punkte 0.2 bis 0.4 betreffen nicht die Vollständigkeit der Liste in Abschnitt 1, sondern die Bewertung des Drittlandbezugs; sie sind fachkundig zu klären, bevor mit dem Verarbeiten von Echtdaten begonnen wird.
Aufbau dieser Anlage. Abschnitt 1 ist der Vertragsbestandteil: die Liste der beauftragten Unterauftragsverarbeiter. Sie führt seit dem 15.08.2026 die Supabase Pte. Ltd. und ist in diesem Zustand vollständig und richtig. Ein Kunde kann sie so erhalten. Abschnitt 1a hält den internen Auswahlstand fest; er ist ausdrücklich kein Vertragsbestandteil und begründet keine Genehmigung. Diese Trennung ist notwendig, weil eine Liste mit Anbieternamen sonst den Eindruck erweckt, es bestünden bereits Beauftragungen.
Alle Anschriften und Registerangaben in den Abschnitten 1a, 2, 3 und 4 sind Arbeitsstand und nicht verifiziert. Vor der Aufnahme eines Anbieters in Abschnitt 1 sind Firmierung, Anschrift und Registerangaben anhand des Impressums und des Auftragsverarbeitungsvertrags des Anbieters zu prüfen.
1. Beauftragte Unterauftragsverarbeiter: dies ist der Vertragsbestandteil
Diese Liste ist die abschließende Aufstellung nach § 8 Absatz 1 des Vertrags.
| Nr. | Name und Anschrift | Leistung | Ort der Verarbeitung | Drittlandbezug | AV-Vertrag geschlossen am |
|---|---|---|---|---|---|
| 1 | Supabase Pte. Ltd., 65 Chulia Street #38-02/03, OCBC Centre, Singapore 049513 | Betrieb der Datenbank, der Anmeldung und der Schnittstelle, über die Instandio die Daten der Kundenkonten speichert und abgleicht | Frankfurt am Main, Region eu-central-1 | Ja: Sitz des Anbieters in Singapur, kein Angemessenheitsbeschluss; abgesichert über die im Auftragsverarbeitungsverzeichnis des Anbieters einbezogenen Standardvertragsklauseln | 15.08.2026 |
Herkunft der Angaben. Firmierung und Anschrift stammen aus dem Auftragsverarbeitungsverzeichnis des Anbieters, abgerufen am 15.08.2026 unter https://supabase.com/legal/dpa. Der Verarbeitungsort eu-central-1 (Frankfurt am Main) ist am 15.08.2026 im Anbieterkonto bestätigt worden.
Zum Datum des Vertragsschlusses. Das Auftragsverarbeitungsverzeichnis des Anbieters wird nicht gesondert unterzeichnet, sondern gilt mit der Annahme der Nutzungsbedingungen („This DPA is effective as of the Effective Date of the Agreement“; „acceptance of the Agreement shall have the same effect as signing the SCCs“). Maßgeblich ist deshalb der Tag, an dem das für Instandio genutzte Projekt angelegt wurde: der 15.08.2026.
Was das bedeutet: vdw zieht für den Betrieb der Kundenkonten einen weiteren Auftragsverarbeiter heran. Seit dem 30.08.2026 ist die Anwendung nur nach Anmeldung nutzbar; die frühere Ausnahme für Kunden, die Instandio ohne Konto nutzen, besteht nicht mehr. Ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code am Objektetikett; wird dort eine Meldung abgegeben, gelangt sie in den Bestand des Kunden auf demselben Server (Anlage 1, Vorgang V8, und dortiger offener Punkt O1). Eine Hinzuziehung ist erst nach dem Verfahren des § 8 Absätze 3 bis 5 des Vertrags zulässig: Abschluss eines Vertrags nach Art. 28 Abs. 4 DSGVO, dokumentierte Eignungsprüfung, Ankündigung an den Kunden 30 Tage vor Wirksamwerden, Widerspruchsrecht des Kunden. Jede Aufnahme in diese Tabelle ist in Abschnitt 6 zu protokollieren.
Diese Anlage ist als Vertragsbestandteil vollständig und darf einem Kunden vorgelegt werden. Die Prüfpunkte 0.2 bis 0.4 betreffen nicht die Vollständigkeit dieser Liste, sondern die Bewertung des Drittlandbezugs; sie sind fachkundig zu klären, bevor mit dem Verarbeiten von Echtdaten begonnen wird.
1a. Auswahlstand: kein Vertragsbestandteil, keine Beauftragung
Die folgende Aufstellung dokumentiert den internen Arbeitsstand der Anbieterauswahl. Keiner dieser Anbieter ist beauftragt; mit keinem besteht ein Auftragsverarbeitungsvertrag. Die Aufstellung begründet keine Genehmigung nach § 8 Absatz 1 des Vertrags und ist einem Kunden nicht als Liste der Unterauftragsverarbeiter vorzulegen.
| Nr. | Zu vergebende Leistung | Arbeitsstand der Auswahl (Anschriften nicht verifiziert) | Offene Prüfung |
|---|---|---|---|
| A | Betrieb der Anwendung, Datenbank, Objektspeicher für Dokumente und Fotos, Datensicherung, Anwendungsprotokolle | Hostingentscheidung nicht getroffen. In der Betrachtung: Microsoft Azure (Region Deutschland) sowie die Rückfallebenen aus Abschnitt 3 | Für Microsoft-Dienste ist die Reichweite der EU-Datengrenze und ein möglicher Zugriff aus Drittstaaten (Support, Telemetrie) anhand der Produkt- und Datenschutzbestimmungen zu prüfen |
| B | Versand von Fristenvorwarnungen, Eskalationen, Maßnahmen- und Auftragsbenachrichtigungen (E-Mail-Adresse, Anzeigename, Inhalt der Benachrichtigung) | kein Anbieter ausgewählt. In der Betrachtung: Brevo (Sendinblue SAS), Sitz Frankreich | Rechenzentrumsregion schriftlich bestätigen lassen |
| C | Prüfung hochgeladener Dateien auf Schadsoftware vor der Freigabe | kein Anbieter ausgewählt | EU-Verarbeitung sicherstellen oder Lösung ohne Drittanbieter prüfen |
| D | Erfassung von Fehlermeldungen mit Aufrufkette (technische Kennungen, Nutzer- und Mandantenkennung; keine Fachdaten) | kein Anbieter ausgewählt. In der Betrachtung: Sentry, Anbieter mit Sitz in den USA, bei Wahl der EU-Region | Bei einem US-Anbieter sind Standardvertragsklauseln nach Art. 46 Abs. 2 lit. c DSGVO nebst Übermittlungs-Folgenabschätzung erforderlich, sofern ein Zugriff aus den USA nicht ausgeschlossen ist. Alternative ohne Drittlandbezug vorrangig prüfen |
| E | Erkennung automatisierter Zugriffe am öffentlich erreichbaren QR-Portal, erst bei Auffälligkeit ausgelöst (übermittelt würde mindestens die IP-Adresse des Melders) | nicht entschieden. Die Architektur nennt beispielhaft Cloudflare Turnstile, Anbieter mit Sitz in den USA | Ein US-Anbieter im anonymen Meldeweg steht in Spannung zum Vertriebsargument „deutsches Hosting“. Vorrangig eine Lösung ohne Drittanbieter prüfen (eigene Ratenbegrenzung und Auffälligkeitserkennung) |
2. Der Bestandsserver: offener Prüfpunkt
| Merkmal | Angabe |
|---|---|
| Anbieter | Hostinger International Ltd., 61 Lordou Vironos Street, 6023 Larnaca, Zypern (nicht verifiziert) |
| Tarif | KVM 4: 4 vCPU (AMD EPYC 9354P), 15 GiB Arbeitsspeicher, 193 GB Plattenplatz |
| System | Ubuntu 24.04.4 LTS, PostgreSQL 16, Redis, Postfix, Node, Python 3 |
| Vorgesehene Verwendung | ausschließlich Entwicklungs- und Abnahmeumgebung während der Bauzeit |
| Grenzkosten für Instandio | 0,00 €: der Server läuft ohnehin für ein anderes Vorhaben der vdw GmbH |
2.1 Warum dieser Server für Kundendaten nicht in Frage kommt
| Grund | Warum das trägt |
|---|---|
| Kein Vertrag nach Art. 28 DSGVO mit dem Betreiber | Ein solcher Vertrag ist zu schließen, bevor personenbezogene Echtdaten auf diesem Server verarbeitet werden. Der Rechenzentrumsstandort ist dagegen kein Ausschlussgrund: Der Server steht in Frankfurt am Main (bestätigt am 07.08.2026), die Verarbeitung findet damit innerhalb der EU statt, ein Drittlandtransfer liegt nicht vor |
| Gemeinsame Nutzung mit einem fremden Produktivsystem | Auf der Maschine läuft eine eigene Buch-Automatisierung der vdw GmbH (KDP-Factory-Pipeline). Kundendaten aus Instandio neben einem sachfremden Produktivsystem sind in einem Vertrag nach Art. 28 DSGVO schwer zu vertreten und gegenüber einer prüfenden Kunden-IT nicht zu erklären |
| Anwendung und Datenbank auf einer Maschine, ohne Ausfallübernahme | Ein Ausfall nimmt beides gleichzeitig mit. Bei einem Nachweissystem, dessen Fristenlauf nachts durchlaufen muss, ist das keine tragfähige Grundlage |
| Keine punktgenaue Wiederherstellung | Anlage 2 Nr. 3.1 fordert 35 Tage. Hostinger sichert per Momentaufnahme, nicht fortlaufend. Eine Protokollarchivierung müsste selbst gebaut und wöchentlich erprobt werden |
2.2 Regelung
vdw verarbeitet auf diesem Server keine personenbezogenen Kundendaten. Wird die Abnahmeumgebung mit einem Auszug aus Produktivdaten befüllt, ist dieser Server entweder durch einen ausschließlich für Instandio betriebenen Server zu ersetzen oder als Unterauftragsverarbeiter in Abschnitt 1 aufzunehmen, einschließlich Auftragsverarbeitungsvertrag, verifiziertem Standort und Ankündigung an die Kunden.
3. Alternative Hostinganbieter: geprüft, nicht beauftragt
Die folgenden Anbieter wurden in GO-LIVE-UND-BETRIEB.md §2.1 und §2.1.1 geprüft. Sie sind keine Unterauftragsverarbeiter, solange sie nicht beauftragt sind. Die Aufstellung dient der Nachvollziehbarkeit der Hostingentscheidung.
| Anbieter (Anschriften nicht verifiziert) | Sitz | Bewertung aus dem Konzept |
|---|---|---|
| Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen | Deutschland | Datenschutzrechtlich mindestens gleichwertig zu Azure, aber erklärungsbedürftiger gegenüber einer M365-nahen Kunden-IT. Preisvorteil seit der Erhöhung zum 15.06.2026 kleiner als angenommen |
| netcup GmbH, Daimlerstraße 25, 76185 Karlsruhe | Deutschland | Günstigste Variante mit selbst betriebener Datenbank. Der Preisvorteil wird durch den eigenen Betriebsaufwand (Patches, Ausfallübernahme, Wiederherstellungsproben) rechnerisch aufgezehrt |
| IONOS SE, Elgendorfer Str. 57, 56410 Montabaur | Deutschland | Zugleich Registrar der Instandio-Domänen. In keiner geprüften Variante die günstigere Wahl; Managed PostgreSQL liegt über dem Dreifachen des Azure-Preises. Die Domainregistrierung bindet die Hostingentscheidung nicht |
| Contabo GmbH | Deutschland | Billigster Preis, schlechteste Wahl: 24 Monate Vertragsbindung und kein tragfähiges Leistungsversprechen. Für ein Nachweissystem mit Berufsgenossenschafts-Relevanz nicht vertretbar |
4. Dienste, die keine Unterauftragsverarbeiter dieses Vertrags sind
Diese Abgrenzung ist wichtig, weil sie erklärt, warum bekannte Namen in Abschnitt 1 fehlen.
| Dienst | Warum keine Unterauftragsverarbeitung |
|---|---|
| Microsoft Entra ID und Microsoft Teams im Tenant des Kunden | Der Kunde betreibt seinen eigenen Microsoft-365-Tenant in eigener Verantwortung. Die Anmeldung findet im Verzeichnis des Kunden statt; vdw ist an dieser Verarbeitung nicht als Auftragsverarbeiter beteiligt und speichert keine Kennwörter |
| Quellcodeverwaltung und Prüfstrecke (GitHub) | Enthält Programmcode und Testdaten, keine Kundendaten. Wird die Abnahmeumgebung mit personenbezogenen Daten befüllt, ändert sich diese Bewertung, siehe Abschnitt 2.2 |
| Zertifikatsausstellung (Let’s Encrypt) | Ausstellung von Transportverschlüsselungszertifikaten für Domänennamen; keine Verarbeitung personenbezogener Daten des Kunden |
| Domainregistrierung (IONOS) | Verwaltung der Domänen instandio.de, .com, .store, .global der vdw GmbH; keine Kundendaten |
| Telekommunikation, Post, Reinigung, Hardwarewartung ohne Datenzugriff | Nebenleistungen nach § 8 Absatz 2 des Vertrags |
5. Aufgaben vor dem ersten Produktivkunden
| Nr. | Aufgabe | Zuständig | Status |
|---|---|---|---|
| A1 | Hostingentscheidung treffen und in Anlage 1 sowie in dieser Anlage festschreiben | Olaf von Deines | offen |
| A2 | Auftragsverarbeitungsvertrag mit dem Hostinganbieter schließen, Standardvertragsklauseln und Unterauftragsverarbeiterliste des Anbieters prüfen | vdw | offen |
| A3 | Auftragsverarbeitungsvertrag mit dem Betreiber des Hostinger-Bestandsservers schließen oder den Server aus dem Verarbeitungspfad nehmen; der Rechenzentrumsstandort ist geklärt und liegt innerhalb der EU | vdw | offen, wichtigster Punkt |
| A4 | E-Mail-Versanddienst auswählen, Auftragsverarbeitungsvertrag schließen, Rechenzentrumsregion schriftlich bestätigen lassen | vdw | offen |
| A5 | Virenscan-Anbieter auswählen und Auftragsverarbeitungsvertrag schließen; alternativ eine Lösung ohne Drittanbieter prüfen | vdw | offen |
| A6 | Fehlerüberwachung entscheiden: EU-Anbieter oder Standardvertragsklauseln mit Übermittlungs-Folgenabschätzung | vdw | offen |
| A7 | Bot-Schutz entscheiden: eigene Lösung oder Drittanbieter mit Drittlandprüfung | vdw | offen |
| A8 | Liste im Produkt einsehbar machen und das Ankündigungsverfahren nach § 8 Absatz 4 des Vertrags einrichten | vdw | offen |
| A9 | Jährliche Eignungsprüfung aller Unterauftragsverarbeiter als wiederkehrenden Termin anlegen | vdw | offen |
| A10 | Zertifizierungsnachweise (ISO/IEC 27001, BSI C5) der Anbieter einholen und ablegen. Sie sind der Nachweis nach § 9 Absatz 2 lit. d des Vertrags | vdw | offen |
6. Änderungshistorie der Unterauftragsverarbeiter
Diese Tabelle wird bei jeder Änderung fortgeschrieben. Sie ist zugleich der Nachweis der Ankündigung nach § 8 Absatz 4 des Vertrags.
| Datum | Änderung | Betroffener Unterauftragsverarbeiter | Ankündigung an Kunden am | Widersprüche |
|---|---|---|---|---|
| 07.08.2026 | Ersterstellung der Anlage; kein Unterauftragsverarbeiter beauftragt | keine | entfällt | keine |
| 15.08.2026 | Supabase Pte. Ltd. als Unterauftragsverarbeiter beauftragt und in Abschnitt 1 aufgenommen: Betrieb der Datenbank, der Anmeldung und der Schnittstelle; Verarbeitungsort Frankfurt am Main, Region eu-central-1; Drittlandbezug über den Sitz des Anbieters in Singapur, abgesichert über die einbezogenen Standardvertragsklauseln | Supabase Pte. Ltd. | entfällt, kein Kunde unter Vertrag | keine |
| 23.08.2026 | Berichtigung der Anlage: Beauftragung vom 15.08.2026 in dieser Tabelle nachgetragen; Aussagen zur Auslieferbarkeit und zur leeren Liste an Abschnitt 1 angeglichen; Rechenzentrumsstandort des Bestandsservers als innerhalb der EU festgelegt; Aufgabe A3 auf den fehlenden Auftragsverarbeitungsvertrag umgestellt | Supabase Pte. Ltd. | entfällt, kein Kunde unter Vertrag | keine |
Änderungsverzeichnis
| Version | Datum | Änderung | Bearbeiter |
|---|---|---|---|
| 1.2 | 30.08.2026 | Abschnitt 0 und Abschnitt 1: Angaben zur Nutzung ohne Konto auf die Anmeldepflicht ab dem 30.08.2026 umgestellt. Die Liste der beauftragten Unterauftragsverarbeiter in Abschnitt 1 ist unverändert | vdw GmbH |
| 1.1 | 15.08.2026 | Serverbetrieb aufgenommen: Supabase Pte. Ltd. als Unterauftragsverarbeiter in Anlage 3, Drittlandbezug ausgewiesen, Vorbemerkung auf den tatsächlichen Stand umgestellt | vdw GmbH |
| 1.0-Entwurf | 07.08.2026 | Ersterstellung | vdw GmbH |
Änderungsprotokoll
| Datum | Geänderte Abschnitte | Behobener Befund |
|---|---|---|
| 07.08.2026 | Abschnitt 0, Aufbau der Anlage erläutert: Abschnitt 1 als Vertragsbestandteil, Abschnitt 1a als interner Auswahlstand; Hinweis ergänzt, dass die leere Liste vollständig und einem Kunden vorlegbar ist | B-06 |
| 07.08.2026 | Abschnitt 1: aus der Liste „vorgesehener“ Unterauftragsverarbeiter eine leere Liste beauftragter Unterauftragsverarbeiter gemacht; die frühere Aufstellung U1 bis U5 erweckte den Eindruck bestehender Beauftragungen | B-06 |
| 07.08.2026 | Neuer Abschnitt 1a: Anbieterkandidaten als Auswahlstand ohne Vertragswirkung geführt, Anbieternamen aus der Vertragsanlage herausgelöst, offene Prüfungen je Leistung benannt | B-06 |
| 23.08.2026 | Abschnitt 0: Aussage zur Auslieferbarkeit an Abschnitt 1 angeglichen und der Hinweis auf die leere Liste berichtigt; Abschnitt 2.1: Ausschlussgründe geordnet, der Standort ist keiner; Abschnitt 5: Aufgabe A3 auf den fehlenden Auftragsverarbeitungsvertrag umgestellt; Abschnitt 6: Beauftragung vom 15.08.2026 nachgetragen; Kopfzeile fortgeschrieben; Gedankenstriche aufgelöst und Anführungszeichen vereinheitlicht | Widerspruch innerhalb der Anlage, Entscheidung der Geschäftsführung vom 23.08.2026 |
| 30.08.2026 | Abschnitt 0, „Der Stand in einem Satz“, und Abschnitt 1, „Was das bedeutet“: die Angaben, wer Instandio ohne Konto nutze, sei nicht berührt und dessen Daten lägen weiterhin ausschließlich im Browser beziehungsweise verließen das Gerät nicht, sind gestrichen und durch den Stand seit dem 30.08.2026 ersetzt: Die Anwendung ist nur nach Anmeldung nutzbar; ohne Konto vorgesehen bleibt allein das Objektportal hinter dem QR-Code. Eine dort abgegebene Meldung gelangt in den Bestand des Kunden auf demselben Server; ihre Einordnung ist als offener Punkt O1 in Anlage 1 vermerkt. Die Liste der beauftragten Unterauftragsverarbeiter in Abschnitt 1 und die Änderungshistorie in Abschnitt 6 sind unverändert, weil kein Unterauftragsverarbeiter hinzugekommen oder weggefallen ist | Entscheidung der Geschäftsführung vom 30.08.2026: Die Anwendung ist nur nach Anmeldung nutzbar |