Der vorherige Dienstleister ist gekündigt, die Agentur hat das Mandat verloren, oder ein Zukauf hat Systeme ins Haus geholt, die niemand im eigenen Team gebaut hat. Die nächste Sitzung dreht sich dann oft um das Redesign, den neuen Stack oder den Kick-off mit dem Nachfolger. Das sind die falschen ersten Themen.
Die erste Frage lautet: Können Sie am Montag eine Änderung in Produktion bringen — und den vorherigen Dienstleister gleichzeitig aussperren, ohne dass die Seite, der Shop oder die Schnittstelle stehen bleibt? Wer das nicht aus eigenen Unterlagen beantworten kann, hat keine Übergabe. Er hat ein Betriebsrisiko, das sich als Projekt tarnt.
Das Bundesamt für Sicherheit in der Informationstechnik verlangt für die Beendigung eines Outsourcing-Verhältnisses Regelungen: wie Daten und Hardware zurückkommen, und ob Zugangs- und Zugriffsrechte mit dem Vertragsende wirklich aufgehoben sind (BSI, IT-Grundschutz-Baustein OPS.2.3, Anforderung A7). Genau das wird nach einem Agenturwechsel oder einer Übernahme am häufigsten übersprungen.
Die Reihenfolge ist die eigentliche Entscheidung
Fünf Gegenstände, in dieser Reihenfolge. Nicht weil sie gleich wichtig sind, sondern weil jeder spätere Schritt den vorherigen voraussetzt. Ohne Zugänge sehen Sie den Code nicht. Ohne geklärtes Eigentum dürfen Sie ihn nicht weiterbauen. Ohne Deploy bleibt jede Korrektur Theorie. Ohne Monitoring merken Sie den Fehler nicht. Ohne die undokumentierten Integrationen erklären Sie den nächsten Ausfall falsch.
| Schritt | Gegenstand | Fertig, wenn |
|---|---|---|
| 1 | Zugänge | Der vorherige Dienstleister ist ausgeschlossen, ohne Produktionsverlust |
| 2 | Code-Eigentum | Sie können klonen, bauen und das rechtlich auch dürfen |
| 3 | Deploy | Jemand im eigenen Haus kann ausliefern und zurücknehmen |
| 4 | Monitoring | Ein Ausfall erreicht eine Person, die handeln kann — und zu Ihnen gehört |
| 5 | Integrationen | Jede ausgehende und eingehende Verbindung steht auf einer Liste |
1. Zugänge: Wer kommt noch rein
Bevor irgendetwas am System geändert wird, muss feststehen, wer heute noch hineinkommt. Nicht als Gesprächsnotiz, sondern als Liste mit Eigentümerkonto, Rolle und letzter Nutzung.
Mindestumfang, der nach einem Wechsel regelmäßig Lücken hat:
- Quellcodeverwaltung, Paketregister, CI und Secret Stores
- Cloud-Konten, Hosting, CDN, DNS und Domain-Registrar
- Shopsystem, Newsletter, Zahlungsdienst, CRM
- Monitoring, Logaggregation, Fehlertracker
- Passwortmanager und das Konto, das alle anderen Konten ausstellt
Drei Befunde kehren nach Agenturwechseln und Übernahmen regelmäßig wieder. Das Eigentümerkonto liegt auf einer privaten Adresse des Dienstleisters. Ein gemeinsames Passwort steht in einem Chatverlauf. Ein Root-Zugang existiert, den niemand im Haus je benutzt hat — und den deshalb auch niemand sperren will.
Der IT-Grundschutz verlangt, dass jede Kennung einer Person zugeordnet werden kann, dass inaktive Kennungen deaktiviert werden und dass Berechtigungen bei personellen Veränderungen entzogen werden (BSI, Baustein ORP.4, Anforderungen A1 und A2). Ein Dienstleisterwechsel ist genau so eine personelle Veränderung. Der Unterschied zu einem internen Austritt: Derjenige, der geht, hat oft noch die Schlüssel, mit denen sich die übrigen Konten zurückholen lassen.
Deshalb gilt innerhalb dieses Schritts eine harte Reihenfolge. Zuerst die Eigentümerrolle auf ein Konto der eigenen Organisation ziehen. Dann die übrigen Zugänge inventarisieren. Dann die Zugänge des vorherigen Dienstleisters entziehen — nicht vorher. Wer zuerst sperrt und danach feststellt, dass das DNS-Konto oder der Deploy-Schlüssel nur dort lag, hat den Betrieb selbst abgeschaltet.
Fertig ist dieser Schritt, wenn Sie den vorherigen Dienstleister vollständig ausschließen können und das System danach noch startet.
2. Code-Eigentum: Was Ihnen gehört
Zugang zum Repository ist nicht dasselbe wie das Recht, den Code weiterzuentwickeln. Und das Recht auf Papier ist nicht dasselbe wie die Fähigkeit, aus dem Bestand ein lauffähiges System zu erzeugen.
Tatsächlich prüfen:
- Liegt das Repository in einer Organisation, die Ihnen gehört — oder in der Organisation der Agentur?
- Existieren neben dem Anwendungscode die Build-Konfiguration, die Infrastrukturdefinition und das, was als „das Projekt“ in Designwerkzeugen, im CMS oder in einer lokalen Datenbank lebt?
- Welche Abhängigkeiten laufen über ein Lizenzkonto der Agentur — Schriften, Plugins, Theme, ein internes Paket?
- Lässt sich aus einem frischen Clone ein Build erzeugen, ohne dass jemand aus dem alten Team einen Schlüssel nachreichen muss?
Rechtlich liegt die Grenze schärfer, als viele Verträge sie zeichnen. Wird ein Computerprogramm von einem Arbeitnehmer in Wahrnehmung seiner Aufgaben geschaffen, stehen die vermögensrechtlichen Befugnisse dem Arbeitgeber zu (§ 69b UrhG). Für eine beauftragte Agentur oder einen Freiberufler gilt das nicht. Dort bleiben die Urheberrechte beim Ersteller, solange Nutzungsrechte nicht eingeräumt sind. Sind die Nutzungsarten im Vertrag nicht ausdrücklich bezeichnet, bestimmt sich der Umfang nach dem Vertragszweck (§ 31 Abs. 5 UrhG). Ein Werkvertrag, der „die Website“ schuldet, überträgt damit nicht automatisch das Recht, den Code intern umzubauen, an einen Nachfolger zu übergeben oder Teile davon in einem zweiten System wiederzuverwenden.
Diese Lücke fällt selten am Übergabetag auf. Sie fällt auf, wenn der Nachfolger den ersten größeren Eingriff plant und die vorherige Agentur widerspricht — oder nicht mehr antwortet. Ob Ihr Vertrag die nötigen Nutzungsrechte enthält, ist eine Rechtsfrage. Ob Sie den Bestand ohne die vorherige Agentur bauen können, ist eine Betriebsfrage. Beide müssen in den ersten Tagen geklärt sein.
Fertig ist dieser Schritt, wenn ein Dritter den Bestand klonen, bauen und das nach dem Vertrag auch darf — ohne Rückfrage beim Vorgänger.
3. Deploy: Wie eine Änderung in Produktion kommt
Wer den Code hat, hat noch keinen Weg in Produktion. Nach einem Wechsel liegt der Deploy oft „irgendwie bei denen“: ein Skript auf einem Laptop, ein Zugang ins Hosting-Panel, eine Pipeline, deren Schlüssel niemand dokumentiert hat.
Zu klären ist nicht das Tool. Zu klären sind vier Fragen:
- Wer darf ausliefern — namentlich, mit einem Konto der eigenen Organisation?
- Welche Schritte liegen zwischen Commit und laufendem System, und welcher davon ist nicht wiederholbar?
- Wie wird eine Auslieferung zurückgenommen, und wurde das jemals ausgeführt?
- Wo liegen die Geheimnisse — in der Pipeline, in der Umgebung, oder in einer Nachricht, die niemand mehr findet?
Die Trennung von Build, Release und Laufzeit ist dafür die brauchbare Prüfschablone: Ein Build entsteht aus einem bestimmten Commit, ein Release verbindet diesen Build mit der aktuellen Konfiguration, die Laufzeit startet genau dieses Release. Releases sind ein nur anfügbares Verzeichnis; eine Änderung erzeugt ein neues Release, sie überschreibt kein altes (The Twelve-Factor App, Faktor V). Wo diese Trennung fehlt, ist ein Rollback eine Hoffnung, kein Vorgang. Wo jemand nachts auf dem Server Dateien ändert, gibt es nichts, zu dem man zurückkehren könnte.
Nach einem Wechsel sind Produktion und Repository oft auseinandergelaufen, weil Hotfixes nie zurückgespielt wurden. Der nächste saubere Deploy überschreibt dann auch die undokumentierte Korrektur vom letzten Quartal.
Fertig ist dieser Schritt, wenn jemand im eigenen Haus eine einzeilige Änderung ausliefern und wieder zurücknehmen kann — ohne den Vorgänger und ohne den Laptop, der „das Skript“ enthält.
4. Monitoring: Was überwacht wird, und wer den Alarm bekommt
Ein System, das niemand beobachtet, fällt nicht auf, wenn es ausfällt. Es fällt auf, wenn ein Kunde anruft. Nach einem Wechsel ist das Monitoring oft entweder beim Vorgänger geblieben oder so eingerichtet, dass es nur die Startseite prüft.
Drei Fragen reichen, um den Zustand zu sehen:
- Welche Signale werden erfasst — Anfragen, Fehler, Latenz, Sättigung?
- An wen gehen die Alarme heute, und gehört diese Person noch zum Auftrag?
- Wurde eine Wiederherstellung aus dem Backup jemals ausgeführt, oder existiert nur die Sicherung?
Die SRE-Literatur von Google behandelt Überwachung als Entwurfsfrage, nicht als Zusatz: Die vier goldenen Signale — Latenz, Traffic, Fehler und Sättigung — beschreiben den Zustand eines nutzerseitigen Systems; ein Alarm, der niemanden erreicht, der handeln kann, ist keiner (Google SRE Book, Monitoring Distributed Systems). Ein Uptime-Check an eine Mailbox der alten Agentur, ein Fehlertracker auf einem privaten Konto, ein Backup, das nie zurückgespielt wurde — das sind die Stellen, an denen der nächste Vorfall unsichtbar bleibt.
Fertig ist dieser Schritt, wenn ein Ausfall um zwei Uhr nachts eine Person erreicht, die handeln kann und zu Ihrer Organisation gehört — und wenn klar ist, woran diese Person den Schaden erkennt.
5. Undokumentierte Integrationen: Was in keiner Übergabe steht
Was dokumentiert ist, ist selten das Problem. Das Problem sind die Verbindungen, die nie als System galten: ein nächtlicher CSV-Export auf einen übrig gebliebenen Server, ein Webhook ins Buchhaltungssystem, ein Pixel, das Bestellungen an ein Analysekonto der Agentur schickt, ein DNS-Eintrag auf einen Dienst, den niemand mehr bezahlt, bis er abgeschaltet wird.
Diese Integrationen fallen nicht bei der Codeübergabe auf. Sie fallen auf, wenn ein Vorgang zwischen zwei Systemen abreißt und beide Seiten den jeweils anderen für zuständig halten.
Praktisch auffindbar sind sie trotzdem:
- Ausgehende Verbindungen in der laufenden Anwendung, in Cron-Jobs und in der CI
- Eingehende Webhooks bei Zahlungsdienst, Newsletter, Shop und Formularen
- DNS- und TLS-Einträge, die auf Hostnamen außerhalb der bekannten Infrastruktur zeigen
- Rechnungen für SaaS, das niemand intern bestellt hat
- Shared Folders, FTP-Zugänge und „temporäre“ Datenbanken, die seit Jahren produktiv sind
Der Outsourcing-Baustein des BSI benennt genau dieses Risiko: Werden Teile weiter an Subdienstleister verlagert, fragmentiert sich der Prozess, und die Transparenz für den Auftraggeber schwindet (BSI, OPS.2.3). Nach einem Agenturwechsel oder einem Zukauf ist diese Kette oft länger als die Übergabeliste. Was nicht auf der Liste steht, hat trotzdem einen Fehlerfall — nur keinen Verantwortlichen.
Fertig ist dieser Schritt, wenn jede ausgehende und jede eingehende Verbindung einen Namen, eine Gegenstelle und einen bekannten Fehlerfall hat. Was fehlt, wird als fehlend notiert, nicht nachträglich schöngeschrieben.
Ein Beispiel für eine Verbindung mit Verfallsdatum: Programme, die von außen über die Exchange Web Services auf Postfächer zugreifen. Microsoft schaltet diese Schnittstelle in Exchange Online ab, wie wir in EWS-Abschaltung in Exchange Online beschreiben. Wer zusätzlich noch einen Exchange Server vor Ort betreibt, findet in Exchange Hybrid: noch nötig, modernisieren oder abschalten?, woran er hängen kann.
Eine Übergabe, die nur das dokumentiert, was ohnehin bekannt war, hat den Betrieb nicht übergeben. Sie hat ihn verborgen.
Was bewusst später kommt
Erst wenn die fünf Schritte einen belastbaren Stand haben, lohnt die Diskussion, die sonst am Anfang steht: neues Design, neues CMS, neue Agentur, „schnell etwas sichtbar machen“. Vorher ist jede Änderung an Produktion eine Änderung an einem System, das Sie nicht zurücknehmen können und dessen Nebenwirkungen Sie nicht sehen.
Dasselbe gilt für den reflexhaften kompletten Neubau. Manchmal ist er richtig. Ohne die Prüfreihenfolge ist er eine Entscheidung über einen Bestand, den niemand beschrieben hat — und genau diese Entscheidung ist später die teuerste.
Zur Übergabe gehört auch die Frage, wer künftig die Ankündigungen von Herstellern liest. Für Microsoft 365 steht das im Beitrag Microsoft 365 Message Center: Änderungen im Blick behalten.
Wann die eigene Prüfung nicht mehr reicht
Die fünf Schritte sind so geschnitten, dass ein internes Team sie selbst abarbeiten kann, sofern Lesezugriff und ein Ansprechpartner aus dem Betrieb zur Verfügung stehen. Zwei Lagen sprengen dieses Format.
Die erste: Der Bestand ist über Jahre gewachsen, niemand überblickt ihn vollständig, und die Geschäftsführung braucht einen Befund, den ein Dritter nachprüfen kann — etwa vor einer Investition oder nach einem Zukauf. Dafür ist das System-Audit das passende Werkzeug: ein abgegrenzter Prüfauftrag mit festem Preis, fester Dauer und benannten Ergebnisdokumenten. Übernahme nach Zukauf, Fusion oder Dienstleisterwechsel ist einer der Anlässe, für die es gedacht ist.
Die zweite: Nach der Übergabe hören die technischen Fragen nicht auf. Angebote des neuen Dienstleisters müssen eingeordnet, Änderungen mitgezeichnet, die Landschaft im Blick behalten werden — und im Haus gibt es niemanden, der das laufend tut. Dann löst ein einmaliger Befund das nicht. Dafür gibt es die technische Begleitung als wiederkehrendes Format. In den meisten Fällen beginnt sie mit einem Audit — sonst gehen die ersten Monate für genau das drauf, was dieser Beitrag beschreibt.
Beides ersetzt die Prüfreihenfolge nicht. Es macht aus ihr ein Dokument, mit dem sich arbeiten lässt.
Wer Dienstleistern Zugänge zu seinen Systemen gibt, sollte außerdem wissen, ob die NIS2-Regeln das eigene Unternehmen betreffen. Wie sich das in drei Schritten prüfen lässt, steht im Beitrag NIS2: Wer ist betroffen?.
Quellen
- BSI — IT-Grundschutz-Baustein OPS.2.3 „Nutzung von Outsourcing“, Edition 2023, insbesondere A7
- BSI — IT-Grundschutz-Baustein ORP.4 „Identitäts- und Berechtigungsmanagement“, Edition 2023, insbesondere A1 und A2
- § 69b UrhG — Urheber in Arbeits- und Dienstverhältnissen
- § 31 UrhG — Einräumung von Nutzungsrechten
- The Twelve-Factor App — V. Build, release, run
- Google — Site Reliability Engineering, Kapitel „Monitoring Distributed Systems“