Was ein Dienstleister für die Sicherheit seiner Kunden schuldet:
sieben Pflichten und die Fakten, die ihre Erfüllung belegen

Warum Sicherheit zur geschuldeten Leistung gehört

Wer den Betrieb eines Systems übernimmt, übernimmt zwei Arten von Pflichten. Die Hauptpflicht ist die vereinbarte Leistung: eine Website erstellen, eine Anwendung betreiben, Inhalte pflegen. Daneben bestehen Nebenpflichten, die niemand einzeln bestellt, weil sie sich aus der Aufgabe selbst ergeben. Wer Zugang zu fremden Systemen und Daten hat, hat sie sorgfältig zu behandeln, auch wenn im Vertrag kein Wort darüber steht.

Was „Stand der Technik" konkret bedeutet

Der Stand der Technik beschreibt ein Niveau, kein bestimmtes Produkt. Gemeint sind Verfahren, die sich im laufenden Betrieb bewährt haben, am Markt erhältlich sind und deren Wirksamkeit belegt ist. Das deutsche Recht ordnet dieses Niveau zwischen zwei andere ein. Darunter liegt der breite Bestand dessen, was seit Langem üblich ist; die Rechtssprache nennt ihn die allgemein anerkannten Regeln der Technik. Ein solches Verfahren kann fachlich überholt sein und trotzdem weit verbreitet bleiben. Darüber liegt, was im Labor nachgewiesen, in der Breite aber noch nicht zu haben ist, also der Stand von Wissenschaft und Forschung.

Für die tägliche Arbeit heißt das: Ein Verfahren genügt nicht mehr, sobald es von einem verbreiteten besseren abgelöst wurde, auch wenn es technisch weiter funktioniert. Ein Verwaltungszugang, der allein mit Benutzername und Kennwort geschützt ist, entspricht dem Niveau heute nicht mehr, weil die Anmeldung mit einem zweiten Faktor überall verfügbar ist.

Wie viel dabei geschuldet ist, hängt am Risiko. Wer wenige Anfragen entgegennimmt, wird an einem geringeren Aufwand gemessen als wer laufend Bestell-, Vertrags- oder Personaldaten führt. Den Ausschlag geben zwei Größen: der Schaden, der bei einem Fehler entstehen kann, und die Zahl der Menschen, die er treffen würde.

Was Auftragsverarbeitung für das Verhältnis bedeutet

Sobald ein Dienstleister an Daten arbeitet, die sich einzelnen Menschen zuordnen lassen, arbeitet er in fremder Zuständigkeit. Wofür diese Daten erhoben wurden und was mit ihnen geschieht, entscheidet das beauftragende Unternehmen; der Dienstleister führt aus. Dieser Fall tritt häufiger ein, als er bemerkt wird: beim Betrieb einer Website mit Kontaktformular, beim Pflegen eines Kundenportals und bei jedem Wartungszugriff auf ein System, in dem Kundendaten liegen. Der Dienstleister verarbeitet die Daten niemals für den eigenen Zweck. Eine Auswertung der Kundendaten für die eigene Produktentwicklung wäre bereits ein Verstoß.

Ein Dienstleister hat folgende Punkte darzulegen:

• Welche Bestände er berührt: welche Datensammlungen seine Arbeit erreicht, für welche Aufgabe und über welchen Zeitraum
• Worauf hin er handelt: dass er ausschließlich das ausführt, was schriftlich beauftragt ist, und Bedenken anmeldet, wenn eine Anweisung rechtlich nicht trägt
• Wer die Daten zu sehen bekommt: welche seiner Mitarbeiter Zugriff haben und dass deren Schweigepflicht ihr Ausscheiden überdauert
• Womit er sie schützt: die einzeln benannten Vorkehrungen, jeweils mit Stand und Datum statt als Absichtserklärung
• Wen er hinzuzieht: jeden weiteren Anbieter, den er seinerseits einsetzt, etwa für Rechenzentrum, Mailversand oder Fehlerauswertung, mit Name, Aufgabe und Standort und mit der Zustimmung des Auftraggebers dazu
• Wie er im Anlassfall zuarbeitet: was er liefert, wenn eine betroffene Person Auskunft oder Löschung verlangt oder wenn ein Zwischenfall zu bewerten ist
• Was am Ende geschieht: in welcher Frist Daten zurückgegeben oder gelöscht werden und womit er das belegt, einschließlich der Kopien auf Testsystemen und Arbeitsplatzrechnern
• Woran sich das prüfen lässt: welche Unterlagen er dafür vorlegt und wann sein Vorgehen zuletzt überprüft wurde

Fehlen diese Darlegungen, ist bereits das ein Verstoß, unabhängig davon, ob jemals etwas passiert ist. Die sieben folgenden Pflichten benennen im Einzelnen, was ein Dienstleister zu erbringen und zu belegen hat.

Zugänge und Zugangsdaten

Der Zugang ist die Stelle, an der ein System kontrolliert oder unkontrolliert betreten wird. Von der Zugangsverwaltung hängen zwei weitere Pflichten ab, und zwar aus einem jeweils konkreten Grund. Ein Protokoll kann eine Handlung nur dann einer Person zuschreiben, wenn diese Person ein eigenes Konto hat. Melden sich mehrere Personen unter demselben Konto an, verzeichnet die Aufzeichnung ausschließlich den Kontonamen; wer den Eintrag verursacht hat, lässt sich nachträglich nicht mehr feststellen. Und ob beim Ausscheiden einer Person tatsächlich alle Rechte entzogen wurden, lässt sich nur an einer vollständigen Kontenliste prüfen. Fehlt sie, kann niemand angeben, über welche Zugänge diese Person verfügte, und die Sperrung bleibt unbelegt.

Pflicht 1: Persönliche Konten statt gemeinsamer Sammelzugänge

Ein Sammelzugang ist ein Konto, das mehrere Personen gemeinsam nutzen, meist unter einem funktionsbezogenen Namen wie „admin" oder „redaktion". Er ist bequem und macht jede Nachvollziehbarkeit unmöglich. Wenn fünf Personen dasselbe Kennwort verwenden, zeigt das Protokoll fünfmal denselben Namen, und beim Ausscheiden einer dieser Personen muss das Kennwort für alle gewechselt werden, was in der Praxis unterbleibt. Geschuldet ist stattdessen ein eigenes Konto je Person, mit Rechten, die auf die tatsächliche Aufgabe zugeschnitten sind, und mit einem zweiten Faktor bei der Anmeldung für alle Zugänge mit Verwaltungsrechten. Wie schnell geteilte Kennwörter im Betrieb außer Kontrolle geraten, beschreibt der Beitrag zu geteilten Passwörtern im Betrieb.

Die Lücke: Ein einziger Verwaltungszugang, den der Dienstleister, seine Mitarbeiter und gelegentlich Dritte benutzen. Niemand weiß, wie viele Personen das Kennwort kennen. Ausgeschiedene Mitarbeiter des Dienstleisters behalten es im Kopf, und ein Wechsel findet nicht statt, weil er alle anderen aussperren würde.

Der Nachweis: eine aktuelle Liste aller Konten mit Namen, Rechten und Datum der letzten Nutzung. Sie zeigt in wenigen Minuten, ob es Sammelkonten gibt, ob Zugänge längst ausgeschiedener Personen bestehen und ob jemand Rechte hat, die seine Aufgabe nicht erfordert.

Pflicht 2: Zugangsdaten, die sich ohne Eingriff in das Programm wechseln lassen

Kennwörter, Schlüssel und Zugangsdaten für Datenbanken, Schnittstellen und Mailversand werden fachlich als Geheimnisse geführt und außerhalb des Programmcodes gehalten. Der übliche Aufbau trennt drei Ebenen. Der Code enthält nur den Namen, unter dem ein Wert erwartet wird. Die Konfiguration liefert diesen Wert je Umgebung, üblicherweise als Umgebungsvariable oder als Datei außerhalb der Versionsverwaltung. Die Werte selbst liegen in einer Ablage mit eigener Zugriffskontrolle, einem sogenannten Geheimnis-Tresor, der jeden Zugriff protokolliert.

Aus dieser Trennung ergeben sich drei Eigenschaften, die den Betrieb tragen. Entwicklung, Test und Produktion verwenden getrennte Zugangsdaten, sodass ein Testsystem keinen Weg zu den Echtdaten hat. Ein Zugang lässt sich wechseln, indem der Wert in der Konfiguration ersetzt und der Dienst neu gestartet wird; eine Änderung am Code, ein neuer Bau und eine erneute Auslieferung entfallen. Und die Anwendung meldet sich mit einem eigenen Datenbankbenutzer an, dessen Rechte auf die tatsächlich benötigten Operationen beschränkt sind, statt mit einem Zugang zu arbeiten, der alles darf.

Stehen diese Angaben stattdessen im Programmcode, ändert sich die Lage in drei Punkten. Erstens wird jeder Wechsel zu einem Entwicklungsvorgang mit Änderung, Test und Auslieferung, weshalb er in der Praxis unterbleibt. Zweitens ist der Wert für jeden lesbar, der den Programmstand besitzt: für den aktuellen Dienstleister, für jeden früheren Mitarbeiter mit einer lokalen Kopie und für jeden mit Zugriff auf das Repository, also auf die Ablage des Programmstands samt seiner Änderungshistorie. Drittens bleibt ein einmal eingetragener Schlüssel in dieser Historie erhalten, auch wenn er später aus der aktuellen Fassung entfernt wird. Fachlich gilt er damit als offengelegt: Er ist zu wechseln, das Löschen aus dem aktuellen Stand genügt nicht.

Ein Rechteentzug beim Ausscheiden bleibt deshalb wirkungslos, solange die im Code hinterlegten Geheimnisse unverändert bleiben. Zum Ausscheiden einer Person mit Code-Zugriff gehört der Wechsel aller Geheimnisse, auf die sie Zugriff hatte, und nicht nur die Sperrung ihres Kontos.

Die Lücke zeigt sich an fünf Befunden, die in der Praxis gemeinsam auftreten:

• Wechsel nur per Auslieferung: Der Kennwortwechsel wird mit dem Hinweis abgelehnt, das gehe „nur mit einem Update"
• Geheimnisse in der Versionsverwaltung: Zugangsdaten stehen in eingecheckten Konfigurationsdateien, damit dauerhaft auch in der Änderungshistorie
• Keine Trennung der Umgebungen: Test- und Produktivsystem verwenden dieselben Zugangsdaten, ein Test greift damit auf Echtdaten zu
• Ein Datenbankbenutzer für alles: Die Anwendung arbeitet mit einem Zugang, der auch Struktur und Rechte ändern darf, obwohl sie nur lesen und schreiben muss
• Geheimnisse in Ausgaben: Zugangsdaten erscheinen in Protokolldateien oder in Fehlermeldungen, die im Browser sichtbar werden

Der Nachweis besteht aus einer Vorführung und vier Auskünften. Die Vorführung: Ein produktiver Zugang wird gewechselt, dokumentiert mit Zeitpunkt, betroffenem Zugang und der Bestätigung, dass dabei kein neuer Programmstand ausgeliefert wurde. Die Auskünfte betreffen den Ablageort der Geheimnisse, den Kreis der Zugriffsberechtigten darauf, das Datum des letzten Wechsels je Zugang und das Ergebnis einer Prüfung der Änderungshistorie auf enthaltene Schlüssel samt der Bestätigung, dass gefundene Schlüssel gewechselt wurden.

Aktualisierung und Sicherung

Diese beiden Pflichten sind das Tagesgeschäft des laufenden Betriebs. Sie sind unspektakulär, verursachen laufenden Aufwand und werden deshalb als Erstes stillgelegt, wenn ein Wartungsvertrag zu knapp kalkuliert ist.

Pflicht 3: Aktualisierungen mit festem Zyklus und Protokoll

Jede Software, die im Betrieb ist, bekommt im Lauf der Zeit bekannt gewordene Schwachstellen. Eine Schwachstelle ist ein Fehler, über den sich das System zu etwas bewegen lässt, das nicht vorgesehen war. Sobald sie öffentlich bekannt ist, existiert in der Regel auch eine Anleitung zu ihrer Ausnutzung, weshalb der Zeitraum zwischen Bekanntwerden und Einspielen der Korrektur das eigentliche Risiko trägt. Geschuldet ist deshalb ein vereinbarter Zyklus, eine kürzere Frist für dringende Korrekturen und ein Protokoll darüber, was wann eingespielt wurde.

Die Lücke: Aktualisiert wird, wenn ohnehin etwas geändert wird, und das System läuft in einer Version, deren Herstellerunterstützung vor Jahren endete. Auf Nachfrage heißt es, ein Wechsel sei aufwendig und bisher sei nichts passiert.

Der Nachweis: eine Liste der eingesetzten Komponenten mit ihrem aktuellen Versionsstand, dem Ende der jeweiligen Herstellerunterstützung und dem Datum der letzten Aktualisierung. Diese Liste ist auch die Grundlage jeder Entscheidung darüber, wann ein größerer Wechsel eingeplant werden muss.

Pflicht 4: Sicherungen, die nachweislich zurückspielbar sind

Eine Sicherung, die nie zurückgespielt wurde, birgt unkalkulierbare Risiken. Erst der Rückspieltest, bei dem eine Sicherung in einer getrennten Umgebung tatsächlich wiederhergestellt wird, belegt, dass die Daten vollständig und lesbar sind und dass der Vorgang in der erwarteten Zeit abläuft. Geschuldet sind daher drei Angaben: wie oft gesichert wird, wie lange die Stände aufbewahrt werden und wann zuletzt erfolgreich zurückgespielt wurde. Dazu gehört die Aufbewahrung an einem zweiten, vom laufenden System getrennten Ort, damit ein Angriff auf das System nicht zugleich die Sicherungen erfasst. Der übliche Aufbau dafür steht im Beitrag zur Datensicherung nach der 3-2-1-Regel.

Die Lücke: Es wird gesichert, aber nie geprüft. Im Ernstfall zeigt sich, dass die Sicherung seit Monaten abbricht, dass eine Datenbank fehlt oder dass der Stand sich nur mit Zugangsdaten wiederherstellen lässt, die niemand mehr kennt.

Der Nachweis: das Protokoll des letzten Rückspieltests mit Datum, wiederhergestelltem Umfang und benötigter Dauer. Die Dauer ist dabei die eigentliche Information: Sie sagt Ihnen, wie lange Ihr Betrieb im Ernstfall steht.

Verschlüsselung und Protokollierung

Die beiden folgenden Pflichten wirken erst im Ernstfall, und dann entscheiden sie über den Schaden. Verschlüsselung begrenzt, was ein Angreifer mit erbeuteten Daten anfangen kann. Protokolle bestimmen, ob sich hinterher überhaupt rekonstruieren lässt, was geschehen ist.

Pflicht 5: Transportverschlüsselung, Ablageverschlüsselung und Kennwort-Hashing

Die Transportverschlüsselung sichert Daten auf dem Weg zwischen zwei Punkten. Für den Aufruf einer Website geschieht das über TLS, das Protokoll hinter der Adresszeile mit „https". Zur Pflicht gehören dabei vier Punkte: die Weiterleitung unverschlüsselter Aufrufe auf die gesicherte Adresse, ein gesetzter HSTS-Header, mit dem der Browser künftige Aufrufe von sich aus verschlüsselt, die Beschränkung auf aktuelle Protokollversionen bei abgeschalteten veralteten Verfahren und die automatisierte Erneuerung der Zertifikate mit einer Überwachung, die vor Ablauf meldet. Die Strecke endet nicht am Webserver: Auch die Verbindungen von der Anwendung zur Datenbank, zu Schnittstellen und zum Mailversand gehören verschlüsselt, sobald sie ein Netz verlassen.

Die Ablageverschlüsselung sichert Daten im Ruhezustand. Hier ist die Unterscheidung entscheidend, welche Bedrohung sie tatsächlich abdeckt. Eine Verschlüsselung des gesamten Datenträgers schützt gegen den physischen Verlust eines Geräts; im laufenden Betrieb ist der Datenträger entschlüsselt eingebunden, und ein Angreifer mit Systemzugriff liest die Daten im Klartext. Wirksam gegen den Abfluss von Kopien sind deshalb zwei weitere Ebenen: verschlüsselte Sicherungen, deren Schlüssel getrennt von den Sicherungen verwahrt wird, und die feldweise Verschlüsselung besonders schutzbedürftiger Daten in der Datenbank. Beides steht und fällt mit der Schlüsselverwaltung, also mit der Frage, wo die Schlüssel liegen, wer sie einsehen kann, in welchem Abstand sie gewechselt werden und wie sie im Notfall verfügbar sind. Eine verschlüsselte Sicherung ohne auffindbaren Schlüssel ist im Ernstfall ein Totalverlust.

Für Kennwörter gilt ein anderes Verfahren. Verschlüsselung ist umkehrbar; wer den Schlüssel hat, erhält den Klartext zurück. Kennwörter werden deshalb gehasht: Eine Hashfunktion bildet das Kennwort auf eine Zeichenfolge fester Länge ab, aus der sich die Eingabe nicht zurückrechnen lässt. Geeignet sind Verfahren, die eigens für Kennwörter entwickelt wurden, absichtlich rechen- und speicherintensiv arbeiten und je Datensatz einen zufälligen Zusatzwert verwenden, das sogenannte Salz. Die Rechenintensität begrenzt die Zahl der Rateversuche pro Sekunde, das Salz verhindert, dass gleiche Kennwörter denselben Hash ergeben und mit vorberechneten Tabellen aufgelöst werden. Schnelle Prüfsummenverfahren, wie sie zur Integritätsprüfung von Dateien dienen, sind für diesen Zweck ungeeignet.

Die Lücke tritt in fünf Ausprägungen auf:

• Schutz endet am Webserver: Der Aufruf ist verschlüsselt, die Sicherungen liegen unverschlüsselt in einem Netzwerkordner mit weitem Zugriff
• Schlüssel neben den Daten: Der Schlüssel zur verschlüsselten Sicherung liegt im selben Verzeichnis oder im selben Sicherungssatz
• Zertifikate von Hand: Keine automatisierte Erneuerung und keine Ablaufüberwachung, die Erneuerung hängt an der Erinnerung einer Person
• Interne Strecken offen: Die Verbindung zwischen Anwendung und Datenbank läuft unverschlüsselt über ein gemeinsam genutztes Netz
• Kennwörter falsch gespeichert: Ablage im Klartext, umkehrbar verschlüsselt oder mit einem schnellen Prüfsummenverfahren ohne Salz

Der Nachweis umfasst fünf Angaben: eine Aufstellung der Datenbestände mit dem Verschlüsselungszustand im Transport und in der Ablage; den Ablageort der Schlüssel samt Kreis der Zugriffsberechtigten und Datum des letzten Wechsels; den Beleg für die automatisierte Zertifikatserneuerung einschließlich der Schwelle, ab der die Überwachung meldet; die Benennung des eingesetzten Kennwort-Hashverfahrens mit seinen Parametern; und das Protokoll einer Wiederherstellung aus einer verschlüsselten Sicherung, die mit dem hinterlegten Schlüssel tatsächlich gelungen ist.

Pflicht 6: Protokolle, die Änderungen einer Person zuordnen

Ein Protokoll ist die fortlaufende Aufzeichnung darüber, wer wann welche Änderung vorgenommen hat. Es dient zwei Zwecken: der Aufklärung nach einem Vorfall und dem Nachweis der eigenen Sorgfalt. Geschuldet sind Aufzeichnungen über Anmeldungen, insbesondere fehlgeschlagene, über Änderungen an Rechten und Konten sowie über Eingriffe in das laufende System. Sie werden so aufbewahrt, dass sie im Bedarfsfall vorliegen, und so begrenzt, dass sie nicht ihrerseits zu einem Datenbestand werden, der niemanden etwas angeht.

Die Lücke: Es gibt keine Protokolle, oder sie werden nach wenigen Tagen überschrieben. Nach einem Vorfall lässt sich nicht sagen, wann der Zugriff begann, welcher Zugang benutzt wurde und welche Daten betroffen sind. Genau diese Angaben verlangt die Aufsichtsbehörde im Meldeverfahren.

Der Nachweis: ein Auszug aus dem Änderungsprotokoll der letzten Wochen mit Zeitstempel und Urheber je Eintrag. Wo die Wartung über Serverzugriffe läuft, kommt der Nachweis hinzu, dass diese Zugriffe aufgezeichnet werden. Wie sich solche Aufzeichnungen im Alltag auswerten lassen, zeigt der Beitrag zu Server-Logs als Diagnosewerkzeug.

Dokumentation und Übergabefähigkeit

Pflicht 7: Eine Betriebsdokumentation, die ein fachkundiger Dritter lesen kann

Die Betriebsdokumentation ist die Beschreibung des Systems in seinem Betriebszustand. Der Maßstab für ihren Umfang ist die Übergabefähigkeit: Eine fachkundige Person, die das System nie gesehen hat, muss den Betrieb damit übernehmen können, ohne den bisherigen Dienstleister zu befragen. Daraus ergeben sich acht Bestandteile.

• Architektur und Datenflüsse: welche Komponenten zusammenwirken, also Webserver, Anwendung, Datenbank, Zwischenspeicher, Dateiablage und Warteschlangen, dazu alle externen Schnittstellen mit ihren Endpunkten und der Art der Anmeldung
• Umgebungen: Entwicklung, Abnahme und Produktion mit ihren Adressen, ihren Unterschieden und der Frage, welche Daten in welcher Umgebung liegen dürfen
• Laufzeit und Abhängigkeiten: Betriebssystem, Laufzeitversionen und die Liste der Fremdbibliotheken mit festgeschriebenen Ständen, üblicherweise in einer Sperrdatei, dazu ihre Lizenzen
• Bereitstellung und Rückabwicklung: der Weg vom freigegebenen Quellstand in die Produktion, die beteiligte Bau- und Auslieferungsstrecke, die Freigabeschritte und das Verfahren, mit dem ein fehlerhafter Stand zurückgenommen wird, samt der dafür benötigten Zeit
• Konfiguration: alle Konfigurationsschlüssel mit ihrer Bedeutung und ihrem Ablageort, ohne die Werte selbst, sowie die Angabe, welche davon je Umgebung abweichen
• Datenhaltung: Schema und der Ablauf von Schema-Änderungen, die Felder mit Personenbezug, die Aufbewahrungs- und Löschfristen
• Sicherung und Wiederanlauf: Umfang, Zeitplan, Aufbewahrung, Ablageort und Verschlüsselung der Sicherungen, dazu eine Schritt-für-Schritt-Anleitung zur Wiederherstellung mit der erwarteten Dauer und dem maximal hinnehmbaren Datenverlust
• Überwachung und Bereitschaft: welche Messwerte überwacht werden, ab welcher Schwelle ein Alarm ausgelöst wird, an wen er geht und welche Handlungsanweisung für die häufigsten Störungen hinterlegt ist

Dazu treten die kaufmännischen Angaben, die den technischen Teil erst brauchbar machen: die Konten bei Registrar, Nameserver-Betreiber, Hosting-Anbieter, Mailversand und Zertifikatsstelle mit dem jeweiligen Inhaber, ein Auszug der DNS-Einträge mit ihrer Bedeutung sowie die bekannten Besonderheiten des Systems, also Altlasten, bewusste Umgehungslösungen und die Begründung, warum sie bestehen.

Das Fehlen dieser Dokumentation richtet im laufenden Betrieb keinen Schaden an. Es wirkt in drei Situationen: am Vertragsende, bei längerer Abwesenheit der zuständigen Person und im Störfall außerhalb ihrer Erreichbarkeit. Besteht keine übergabefähige Dokumentation, ist ein Wechsel des Dienstleisters technisch blockiert, unabhängig davon, wie die Zusammenarbeit im Übrigen beurteilt wird.

Die Lücke hat zwei Ausprägungen. Die erste ist die fehlende Dokumentation: Es gibt einen Ansprechpartner, der „das schon macht". Beim Wechsel stellt sich heraus, dass Domains auf den Namen des Dienstleisters registriert sind, dass niemand die Zugänge zu den Anbietern kennt und dass der Programmstand nur beim bisherigen Dienstleister vorliegt. Was zum eigenen Webauftritt gehört und worauf man beim Wechsel besteht, behandelt der Beitrag zu Zugängen, Daten und Nutzungsrechten.

Die zweite Ausprägung ist die häufigere und die schwerer zu erkennende: Eine Dokumentation existiert, hält der Prüfung aber nicht stand. Typische Befunde sind Versionsangaben, die vom tatsächlichen Stand abweichen, eine Wiederherstellungsanleitung, die nie durchlaufen wurde, fehlende Angaben zu Konfigurationsschlüsseln, die im Betrieb gesetzt sind, und ein Stand, der auf dem Tag der Übergabe stehen geblieben ist, während das System seither mehrfach geändert wurde. Eine solche Dokumentation erfüllt die Pflicht nicht, weil sie ihren Zweck verfehlt.

Der Nachweis ist deshalb zweiteilig. Erstens die Dokumentation selbst, versehen mit einem Änderungsdatum je Abschnitt, dazu die Registrierungsdaten der Domains und ein schriftlicher Vermerk, wem die Nutzungsrechte am erstellten Programmstand zustehen. Zweitens ihre Verifikation: Eine Person, die die Dokumentation nicht geschrieben hat, arbeitet die Wiederherstellungsanleitung in einer getrennten Umgebung ab und protokolliert das Ergebnis. Erst dieser Durchlauf belegt, dass die Beschreibung mit dem System übereinstimmt. Sinnvollerweise wird er in denselben Rhythmus gelegt wie der Rückspieltest aus Pflicht 4.

Wer rechtlich wofür einsteht

Die rechtliche Einordnung entscheidet darüber, was ein Auftraggeber verlangen kann. Sie beginnt mit einer Unterscheidung, die im Alltag selten getroffen wird: Ein Werkvertrag schuldet ein Ergebnis, ein Dienstvertrag schuldet sorgfältiges Tätigwerden. Wer eine Website erstellt, schuldet das fertige, funktionierende Werk. Wer den laufenden Betrieb übernimmt, schuldet die vereinbarte Tätigkeit in der gebotenen Sorgfalt.

Der Dienstleister haftet gegenüber betroffenen Personen und der Aufsichtsbehörde unmittelbar dort, wo er gegen die Pflichten verstößt, die ihm als Auftragsverarbeiter selbst auferlegt sind, oder wo er außerhalb der erteilten Weisungen handelt. Die typischen Fälle sind benennbar: ein eigenmächtig eingesetzter weiterer Dienstleister, die unautorisierte Weitergabe von Code und Daten, die Verarbeitung für eigene Zwecke, die Speicherung auf eigenen Speichermedien und unterlassene Sicherheitsmaßnahmen.

Hat der Dienstleister eine geschuldete Maßnahme nicht erbracht, trägt er den daraus entstandenen Schaden. Hat der Auftraggeber ein Bußgeld oder eine Entschädigung gezahlt, die auf einer solchen Unterlassung beruht, kann er beim Dienstleister Rückgriff nehmen.

Die Prüfliste für den Auftraggeber

Die folgenden Punkte lassen sich ohne eigenes IT-Personal abfragen.

Die häufigsten Lücken im laufenden Betrieb

Die folgenden sechs Befunde treten in dieser Kombination immer wieder auf. Sie entstehen selten aus einer einzelnen Entscheidung, sondern aus einem Betrieb, der über Jahre auf Zuruf lief und nie überprüft wurde.

Die Punkte eins bis drei erzeugen unmittelbares Risiko, die Punkte vier bis sechs kosten im Streitfall die Beweisführung und die Handlungsfähigkeit