Wir müssen reden: über IT-Dienstleister

Das Drittparteienrisiko, das niemand bestellt hat und trotzdem geliefert wurde.

Ich habe einen IT-Dienstleister mitgegründet und über Jahre mitgeführt, im Wettbewerb mit globalen Konzernen und über mehr als hundert Projekte hinweg. Danach war und bin ich als CEO und Verwaltungsrat auf der anderen Seite des Tisches, dort, wo man die Offerte erhält, sie unterschreibt und die Verantwortung trägt. Was ich hier schreibe, schreibe ich deshalb nicht von aussen. Ich habe beide Rollen ausgefüllt und in der ersten die Fehler mitgemacht, die ich in der zweiten teilweise sogar selber ausbaden musste, und das war gut so. Mit dem Rollenwechsel haben sich nicht nur Perspektive und Verantwortung verändert. Ich sehe seither auch die Realität, in der viele Unternehmen stecken.

Es ist grundsätzlich einfach, von Verwaltungsräten Technologiekompetenz zu verlangen. Ich habe das selbst mehrfach getan und stehe dazu. Aber die Forderung ist unvollständig, solange sie nur eine Seite adressiert. Selbst ein kompetenter Verwaltungsrat entscheidet nur so gut, wie die Grundlagen sind, die er bekommt. Und diese Grundlagen liefert in vielen Unternehmen ein externer Dienstleister, der ein eigenes wirtschaftliches Interesse an der Antwort hat.

Ein Ablauf, den ich in dieser Form mehrfach gesehen habe

Ein Betrieb, gut hundert Mitarbeitende, über die Jahre gewachsene Infrastruktur. Die Person, welche die Systeme über Jahre aufgebaut und teilweise verbastelt hat, verlässt das Unternehmen. Man entscheidet sich notgedrungen für ein Outsourcing. Der Anbieter soll günstig sein und «alles» können. Man evaluiert ihn, oder man kennt jemanden, der jemanden kennt. Die Zusammenarbeit beginnt gut.

Die siebenjährige Firewall und die ebenso betagten Server werden ersetzt. Das ist überfällig, es sind Managementschulden aus der Vergangenheit. Aber welche Komponenten kommen zum Einsatz? Nicht zwingend die passenden. Es sind jene aus dem Portfolio des Anbieters. Ob die Firewall künftig von Hersteller X oder Hersteller Y stammt, hängt selten an einer technischen Anforderung. Es hängt am Partnerprogramm, an Einkaufskonditionen und daran, welche Zertifizierungen die eigenen Leute haben. Die Komponenten sind deswegen nicht schlecht. Sie sind einfach nicht das Ergebnis einer Anforderungsanalyse.

Dann wächst der Bedarf. Videoconferencing, Fileshares, Homeoffice. Verwendet werden die Plattformen, die der Anbieter kennt. Der lokale Exchange Server wird in die Cloud migriert, MS Teams geht in Betrieb, und plötzlich liegen Daten in der Cloud, lokal, in Teams und auf der NAS. Danach fällt auf, dass beispielsweise Archivfunktionen fehlen und die Mailboxen zugespammt werden. Der Anbieter hat die Antwort sofort bereit: ein vorgeschaltetes E-Mail-Gateway. Vorgeschlagen wird das Produkt, das er kennt, und nur dieses, weil er weder E-Mail- noch Archiv-, Datenschutz- oder Sicherheitsspezialist ist, und nach ein paar Kinderkrankheiten läuft es.

Zwei Jahre später wird der Hersteller des Gateways aufgekauft, Konditionen und Partnerprogramm ändern sich, und es folgt der Produktwechsel. Ersetzt wird nicht eine Architektur. Ersetzt wird ein Produkt durch ein gleichartiges. Eine Gegenüberstellung mehrerer Hersteller oder Optionen gibt es nicht, und die Offerte ist für einen Nicht-Techniker nicht lesbar: «ATP» steht beispielsweise darin. Das meint hier nicht die Association of Tennis Professionals. Gemeint ist Advanced Threat Protection. Die Geschäftsleitung sieht drei Buchstaben und eine Differenz von dreissig Franken pro Benutzer und Jahr, bei hundert Benutzern also dreitausend Franken. Sie entscheidet sich für die günstigere Variante, weil die IT-Kosten ohnehin als zu hoch gelten.

Dann kommen weiterhin Phishing-Mails durch, und auf die Frage nach dem Warum folgt der Satz, der alles über das Verhältnis aussagt: Mit dem Zusatzmodul XY inkl. ATP könnten wir solche Mails natürlich abfangen. Hätte der Kunde das nur vorher gewusst.

Die einzige Kennzahl: es läuft

An diesem Punkt lohnt sich die Rückfrage, was in dieser ganzen Kette eigentlich je gemessen wurde. Die Antwort ist: Funktion und Verfügbarkeit, nichts sonst. Keine Zielarchitektur, keine definierte Schutzwirkung, keine Prüfung, an welcher Stelle welches Problem überhaupt bekämpft werden soll. Und genau das ist die eigentliche Diagnose.

Denn im besagten Fall hätte das Zusatzmodul das eine benannte Problem gelöst. Nur ist die Frage nicht, ob man eine weitere Lizenz kauft. Die Frage ist, wo ein Angriffsweg technisch am wirksamsten unterbrochen wird: am Gateway, am Mailserver, an der Firewall oder am Endgerät. Das ist zunächst eine Frage des Anwendungsfalls und infolgedessen eine Frage der Architektur. Wer sie nicht stellt, kauft Module und nicht Sicherheit.

Keiner der Einzelentscheide in diesem Ablauf war für sich falsch. Und trotzdem ist das Ergebnis unbefriedigend und ein Cybersecurityrisiko, denn über das Endresultat hat niemand entschieden. Die technologische Architektur dieses Unternehmens ist als Nebenprodukt von Beschaffungsentscheiden und Bedürfnissen entstanden, verteilt über Jahre, jeder Schritt für sich plausibel begründet. Das ist das Muster, das ich über viele Unternehmen hinweg gesehen habe, und es ist gefährlicher als jeder einzelne Fehlkauf.

Warum Anbieter so handeln

Hier ist Fairness angebracht, und zwar in beide Richtungen. Dieses Verhalten ist selten Absicht, es folgt einer ökonomischen Logik.

Ein Anbieter mit zehn bis zwanzig Mitarbeitenden kann nicht in einem halben Dutzend Herstellerwelten gleichzeitig zertifiziert sein und die Produkte in allen Details kennen. Diese sind zum Teil in Funktionen auch völlig überladen und derart komplex, dass es eine Herausforderung ist, nur ein einziges Produkt richtig zu beherrschen. Partnerprogramme belohnen Konzentration auf einen Stack, nicht Vielfalt. Wiederkehrende Lizenzmargen sind planbarer Umsatz und damit das Rückgrat des Geschäftsmodells. Eine belastbare Gegenüberstellung mehrerer Produkte kostet Aufwand, den niemand bestellt und niemand bezahlt, und sie kann das eigene Portfolio schlecht aussehen lassen. Das Ergebnis ist Portfoliologik statt Anforderungslogik. Ich habe diese Anreize aus der Anbieterperspektive selber erlebt und würde niemandem persönliche Vorwürfe daraus machen.

Der wunde Punkt liegt woanders. Es gibt in diesem Ablauf keine einzige Stelle, die unabhängig urteilt. Wer die Lösung empfiehlt, verkauft sie. Wer sie verkauft, müsste im Problemfall den eigenen früheren Entscheid infrage stellen. Das ist kein Wissensproblem. Es ist ein Anreizproblem, und es löst sich nicht dadurch auf, dass alle Beteiligten gute Absichten haben.

Es löst sich auch nicht über Zertifikate. Eine ISO-27001-Zertifizierung des Anbieters bescheinigt dessen eigenes Managementsystem in einem definierten Geltungsbereich. Sie sagt nichts darüber aus, ob die Architektur, die er bei Ihnen baut, zu Ihrem Risikoprofil passt.

Wo die Governance-Theorie an ihre Grenze stösst

Am Ende dieser Kette steht der Verwaltungsrat. Die Oberaufsicht nach Art. 716a Abs. 1 Ziff. 5 OR ist unübertragbar, die Verantwortung für die Organisation ebenso. Auslagern lässt sich die Leistung, nicht aber die Verantwortung. Das habe ich an anderer Stelle ausführlich beschrieben, und daran ändert sich nichts, auch wenn ich weiss, dass man in der Praxis oft versucht ist, genau diese Verantwortung zu delegieren.

Aber die praktische Konsequenz wird zu selten ausgesprochen. Ein Gremium beaufsichtigt hier eine Umgebung, deren Aufbau es nie entschieden hat, deren Risiken ihm nie vollständig dargelegt wurden, und deren Bewertung von jener Partei stammt, die daran verdient. Wenn es knallt, wandert die heisse Kartoffel zwischen den Anbietern hin und her, und übrig bleiben Geschäftsleitung und Verwaltungsrat.

Dazu kommt eine Asymmetrie, die in der Diskussion um Drittparteienrisiken meist untergeht. Die Haftung des Anbieters ist vertraglich typischerweise begrenzt, oft unter Ausschluss von Folgeschäden. Der Betriebsunterbruch, der Datenverlust und der Reputationsschaden liegen dagegen vollständig beim Kunden. Der Anbieter trägt das Risiko seiner eigenen Empfehlung wirtschaftlich also kaum mit. Das ist der Grund, weshalb ich diese Verträge inzwischen als Führungsthema und nicht als Beschaffungsthema behandle.

Ich halte deshalb an der Forderung nach Technologiekompetenz im Verwaltungsrat und in der Geschäftsleitung fest. Sie ist notwendig, aber nicht hinreichend. Governance kann eine Informationsasymmetrie ordnen, aufheben kann sie sie nicht.

Wo ich heute mehr differenziere

Es braucht nicht noch mehr Checklisten für diesen Fall. Es braucht drei Entscheide, die auf den Tisch der Geschäftsleitung und in die Traktandenliste des Verwaltungsrats gehören, und zwar bevor die nächste Offerte kommt.

• Das Urteil vom Verkauf trennen. Bei jedem Entscheid oberhalb einer definierten Wesentlichkeitsschwelle beurteilt jemand die Anforderung, der an der Lösung nichts verdient. Das kann ein unabhängiger Fachmann sein, ein Beirat oder ein zweiter Anbieter ohne Auftragsaussicht. Der Aufwand wirkt zunächst wie zusätzliche Kosten. Nicht gemachte Fehler sind ebenfalls eingesparte Kosten, sie stehen nur in keiner Rechnung.
• Die eigenen Schlüssel behalten. Wem gehört der Microsoft-Tenant? Wer hält die globalen Administratorkonten? Wem gehören die entwickelten Lösungen? Wo liegt die Dokumentation, und wem gehört sie? Lauten die Antworten auf den Anbieter, ist die Abhängigkeit keine Vertragsfrage mehr. Sie ist eine Tatsache. Das sind fünf Fragen, die jedes Verwaltungsratsmitglied ohne technische Vorbildung stellen kann und deren Antworten sich prüfen lassen.
• Die Architektur als Entscheid behandeln, nicht als Ergebnis. Wer weiss im Unternehmen, wo welche Daten liegen und welche Komponente welches Risiko abdeckt? Wenn diese Frage niemand beantworten kann, ist die Architektur nicht entschieden worden. Sie ist entstanden. Dasselbe gilt für die Investitionsbetrachtung: Weder die günstigste noch die teuerste Variante ist per se die richtige. Richtig ist jene, die über die Nutzungsdauer unter Einbezug von Risiken, Prozessanpassungen und Betriebskosten aufgeht. Den realen Preis bezahlt man ohnehin, nur später und selten zum Listenpreis.

Und eine Bemerkung an die Anbieterseite, ohne Häme. Die verlässlichsten Partner, mit denen ich zusammengearbeitet habe, waren nicht jene mit dem breitesten Portfolio. Es waren jene, die von sich aus sagten, wo ihre Kompetenz endet, und empfahlen, für diesen Teil jemand anderen beizuziehen, oder die zumindest zugaben, dass sie das Know-how zuerst und auf eigene Kosten aufbauen müssen. Das kostet kurzfristig Umsatz, schafft aber langfristig die Beziehung, in der ein Kunde überhaupt erst zuhört. Wer dagegen eine Infrastruktur aufbaut und danach einen zweiten Anbieter braucht, um die dabei entstandenen Lücken zu schliessen, hat ein Geschäftsmodell, aber kein nachhaltiges Mandat.

Zusammenfassung

Die Debatte über Technologiekompetenz im Verwaltungsrat führt nur eine Hälfte des Gesprächs. Die andere Hälfte lautet, dass viele Unternehmen ihre kritischste Infrastruktur auf der Empfehlung einer Partei betreiben, deren Portfolio, Marge und Zertifizierungslage die Empfehlung mitbestimmen, und die für die Folgen wirtschaftlich kaum einsteht. Das ist ein weiteres Drittparteienrisiko, das niemand bewusst eingekauft hat. Es entsteht schleichend, aus lauter einzeln vertretbaren Entscheiden.

Der Verwaltungsrat kann diese Asymmetrie nicht allein durch Fachwissen auflösen. Er kann aber entscheiden, dass zwischen Empfehlung und Entscheid eine unabhängige Beurteilung liegt, dass die Zugänge zur eigenen Umgebung im eigenen Haus bleiben und dass die Architektur ein Traktandum ist und kein Nebenprodukt. Diese drei Entscheide verlangen keine technische Ausbildung. Sie verlangen die Bereitschaft, eine Offerte so lange erklären zu lassen, bis man sie verstanden hat. Das ist nicht nur ein Recht des Gremiums. Es ist Bestandteil seiner Sorgfaltspflicht.

Governance und Praxis treffen an dieser Stelle aufeinander, und die Praxis gewinnt immer. Umso wichtiger ist, wer im Raum sitzt, wenn entschieden wird.