MSP Governance und Partner Management

Warum MSP Governance oft unterschätzt wird

Viele Organisationen beschließen, Teile ihres Cloud-Betriebs an einen Managed Service Provider (MSP) auszulagern. Die Entscheidung ist oft richtig — der Betrieb wird zuverlässiger, interne Teams können sich auf strategische Themen konzentrieren.

Was häufig unterschätzt wird: Die MSP-Beziehung zu steuern, ist an sich schon eine anspruchsvolle Aufgabe. Wer keinen strukturierten Steuerungsprozess aufbaut, verliert nach und nach die Kontrolle über die eigene Cloud-Umgebung — ohne es zu merken.

Was ein MSP typischerweise übernimmt

Operative Aufgaben, die MSPs häufig übernehmen:

• Monitoring und Alerting: Überwachung von Infrastruktur und Applikationen rund um die Uhr
• Incident Response: erste Reaktion und Eskalation bei Produktionsvorfällen
• Patchmanagement: OS-Updates, Security-Patches, Kubernetes-Upgrades
• Backup-Management: Backup-Verifizierung, Recovery-Tests, Retention-Management
• Compliance Reporting: Erstellung von Revisionsnachweisen für regulatorische Reviews
• Kostenoptimierung: Monitoring der Ressourcenverschwendung, Rightsizing-Empfehlungen

Was intern bleiben soll:

• Strategische Cloud-Entscheidungen (Architektur, Providerauswahl, Investitionen)
• Access Management und IAM-Konfiguration (keine Root-Delegation an MSPs)
• Datenschutz- und DSGVO-Verantwortung (Verantwortung ist nicht delegierbar)
• Budgetverantwortung und FinOps-Entscheidungen
• Krisenmanagement und Kommunikation mit Regulatoren

Die vier kritischen Governance-Elemente

1. Vertragsgestaltung und SLAs

Ein MSP-Vertrag muss mehr abdecken als Preis und Umfang. Kritische Vertragsbestandteile:

Service Level Agreement (SLA):

• Verfügbarkeits-SLA für den Managed Service (typisch: 99,5 % bis 99,9 %)
• Reaktionszeit nach Schweregrad (P1: 15 Minuten, P2: 1 Stunde, P3: 4 Stunden)
• Lösungszeitziele mit Eskalationsweg
• Häufigkeit und Format des SLA-Reportings

Penalties and Credits: Ohne wirtschaftliche Konsequenzen bei SLA-Verstößen haben SLAs wenig Lenkungseffekt. Typisch: Gutschrift von 10–30 % der monatlichen Service Fee bei nachgewiesener SLA-Unterdeckung.

Subunternehmerregelungen: Welche Aufgaben darf der MSP weiter delegieren? Jede Weiterübertragung muss transparent sein und den gleichen Datenschutz- und Sicherheitsstandards genügen — relevant für DSGVO Art. 28 Abs. 4.

Ausstiegsregelungen: Wie wird die Übergabe an einen anderen Anbieter bzw. zurück an das interne Team geregelt? Fristen, Wissenstransferpflichten, Dokumentationsübergabe, Zugangsrückgabe.

2. Zugangsmanagement

Der häufigste Governance-Fehler: Der MSP hat zu viele Rechte, zu lange.

Best Practice für MSP-Zugriffe:

• Keine permanenten Admin-Rechte — stattdessen Just-in-Time-Zugriff für Wartungsfenster
• Dedizierte MSP-Konten (keine Verwendung von Mitarbeiterkonten)
• Alle MSP-Aktivitäten im Audit-Log ersichtlich
• Monatliche Überprüfung der aktiven MSP-Berechtigungen
• Sofortige Deaktivierung zum Vertragsende

Das interne IAM-Team (oder CCoE) behält die Eigentümerrechte an allen Projekten. Der MSP agiert mit Editorrechten in definierten Scopes — nie mit Eigentümerrechten.

3. Service-Review-Rhythmus

MSP Governance braucht Struktur. Ohne eine regelmäßige Überprüfung tendiert die Beziehung in eine Richtung, die der Kunde nicht mitbekommt — bis ein Problem entsteht.

Seitlich wischen, um die ganze Tabelle zu sehen

Reviewformat	Frequenz	Teilnehmer	Agenda
Operativer Statuscall	Wöchentlich	IT-Lead + MSP Delivery	Offene Incidents, Tickets, laufende Changes
SLA-Prüfung	Monatlich	CIO + MSP-Management	SLA-Bericht, Abweichungen, Verbesserungsmaßnahmen
Strategische Prüfung	Quartalsweise	Vorstand + MSP-Führung	Roadmap, Vertragsanpassungen, Make-or-Buy
Sicherheitsaudit	Jährlich	CISO + MSP Security	Ergebnisse Penetrationstest, Zertifizierungen, Incident Report

4. Wissensmanagement und Dokumentation

MSP-Lock-in ist oft nicht vertraglich, sondern wissensbasiert: Das interne Team weiß nicht mehr, wie die eigene Infrastruktur funktioniert.

Dokumentationsanforderungen:

• Alle Architekturentscheidungen schriftlich dokumentiert, Pflege im internen Wiki
• Runbooks für alle betrieblichen Prozesse — die Verantwortung liegt intern, nicht beim MSP
• Änderungsprotokoll aller Konfigurationsänderungen, das vom MSP gepflegt wird und intern zugreifbar ist
• Vierteljährliche Wissenstransfersitzungen: MSP erklärt dem internen Team, was sich geändert hat

MSP-Auswahl — worauf es wirklich ankommt

STACKIT-Erfahrung

Hat der MSP nachweisbare Erfahrung mit STACKIT? Gibt es Referenzkunden aus ähnlichen Branchen? STACKIT-zertifizierte Partner bieten einen strukturierten Einstieg.

Compliance-Expertise

Versteht der MSP die regulatorischen Anforderungen Ihrer Branche? DSGVO, TISAX, BAIT, KRITIS — ein MSP ohne Compliance-Know-how ist für regulierte Umgebungen ungeeignet.

Transparente Prozesse

Kann der MSP seinen Incident-Response-Prozess, seine Change-Management-Verfahren und sein Sicherheitskonzept vorstellen? Anbieter, die diesen Fragen ausweichen, sind ein Risiko.

Exit-Bereitschaft

Ein seriöser MSP gestaltet die Ausstiegsklausel aktiv mit — weil er weiß, dass eine gute Beziehung die beste Kundenbindung ist. Wer Ausstiegsvorsorge blockiert, schafft Abhängigkeit.

Umsetzungsschritte

1. Umfang definieren — Was wird ausgelagert, was bleibt intern? Schriftlich, als Grundlage für die Ausschreibung.

2. Ausschreibung oder Auswahl des MSP — Mindestens drei Angebote, eine strukturierte Bewertungsmatrix, Referenzgespräche mit Bestandskunden.

3. Vertragsverhandlung — SLAs, Vertragsstrafen, Subunternehmerregelung, Austrittsklausel, DSGVO-Auftragsverarbeitungsvertrag. Eine auf Cloud-Verträge spezialisierte Rechtsberatung wird empfohlen.

4. Zugriffskonzept umsetzen — MSP-Accounts einrichten, Berechtigungsumfang definieren, Audit-Protokollierung aktivieren, Review-Prozess etablieren.

5. Review-Rhythmus festlegen — Wöchentliche, monatliche und quartalsweise Überprüfungen im Kalender verankern. Agenda-Vorlagen erstellen.

6. Dokumentationspflicht schriftlich vereinbaren — Was liefert der MSP, in welchem Format, in welchem Intervall? Als Vertragsbestandteil, keine verbale Zusicherung.

Verbindung zu anderen Kapiteln

Die SLA-Anforderungen für MSPs leiten sich aus den DR-Tier-Klassifizierungen der betroffenen Workloads ab. Der interne Servicekatalog definiert, welche Services die IT selbst erbringt und welche der MSP übernimmt.