Inhouse vs. Managed Services ist keine rein technische Frage: Für IT‑Leads, Compliance‑Beauftragte und Sicherheitsverantwortliche entscheidet sie maßgeblich über Personalrisiken, Verantwortungsgrenzen und Audit‑Nachweise. In dieser Entscheidung stehen operative Kontinuität, Wissenserhalt und rechtliche Nachweisführung gegen Skalierbarkeit, Kostenflexibilität und Zugriff auf externe Spezialkompetenz.
Warum Personalrisiken bei der Wahl zwischen Inhouse und Managed Services zentral sind
Personalrisiken betreffen Kompetenzverfall, Single Point of Failure (SPoF), Wissenstransfer, Fluktuation und Betriebsbereitschaft. Single Point of Failure meint eine einzelne Person oder Rolle, deren Ausfall den Betrieb erheblich gefährdet. Bei Inhouse‑Modellen verschiebt sich die Verantwortlichkeit direkt auf die internen Teams; bei Managed Services bleibt die Verantwortung zwar vertraglich oft beim Anbieter, das Unternehmen trägt aber weiterhin Reputations‑, Compliance‑ und Datenrisiko.
Entscheidend ist: Die Frage ist nicht, ob Verantwortung besteht — sondern wie sie verteilt, dokumentiert und geprüft wird. Dieser Guide strukturiert die Entscheidung entlang Governance, Betrieb, Sicherheit, Kosten und konkreter Umsetzungsschritte.
Kurzüberblick: Kernunterschiede aus Sicht von Personalrisiken
- Inhouse: Volle operative Kontrolle, Wissen bleibt intern, höhere Personalkosten und stärkere Abhängigkeit von internen Schlüsselpersonen.
- Managed Services: Zugriff auf externe Expertise, potenziell geringeres Personalbindungsrisiko, dafür vertragliche Risiken, weniger direkter Einfluss auf Auswahl, Schulung und Nachweisführung.
Governance: Verantwortlichkeiten klar definieren
Governance beschreibt Regeln, Rollen und Nachweisprozesse. In jedem Modell müssen Sie eindeutige Verantwortlichkeiten (z. B. wer incident response eskaliert, wer Change‑Freigaben erteilt) und Audit‑Nachweise festlegen. Ein gebräuchliches Werkzeug ist die RACI‑Matrix (Responsible, Accountable, Consulted, Informed). RACI ordnet Aufgaben vier Rollenklassen zu und reduziert Unklarheiten im Betrieb.
Beispiel: RACI für Incident Response
Die folgende, kopierbare RACI‑Tabelle ist ein Basisbeispiel, das Sie an Ihre Organisation anpassen sollten.
Aktivität,Incident Owner (intern),Ops Team (intern),Managed Provider,Sicherheitsverantwortlicher,Geschäftsführung
Erkennung,R,A,C,I,I
Containment,R,A,C,C,I
Root Cause Analyse,A,R,C,C,I
Kommunikation an Stakeholder,I,I,R,A,A
Lessons Learned,A,R,C,C,I
Hinweis: ‚R‘ = Responsible (durchführend), ‚A‘ = Accountable (verantwortlich für Entscheidung), ‚C‘ = Consulted (zu konsultieren), ‚I‘ = Informed (zu informieren).
Operationalisierung: Betrieb, SLAs und Schnittstellen
Ein Managed Service entbindet Sie nicht automatisch von Betriebsverantwortung. Entscheidend sind SLA‑Definitionen, Schnittstellen (APIs, Ticketsysteme, Monitoring), Rollen für Eskalation und Change‑Kontrolle. Prüfen Sie insbesondere:
- Konkrete SLA‑Metriken: Verfügbarkeit, MTTR (Mean Time To Repair), Fehlerklassen, Penalty‑Mechanik.
- Schnittstellen für Monitoring‑ und Audit‑Daten: Darf Ihr Team Logs direkt einsehen? Werden Alerts parallel an interne Tools weitergeleitet?
- Change‑Workflow: Wer autorisiert Änderungen in Produktion? Wie sind Rollbacks geregelt?
Ohne saubere Schnittstellen entstehen verdeckte Personalrisiken: internes Team muss trotz Outsourcing fachlich nachverfolgen können, sonst verliert es situatives Wissen.
SLA‑Design: Zwei konkrete Fallen
Erste Falle: SLA nur auf Verfügbarkeit. Ein Anbieter kann Verfügbarkeit liefern, aber Zeit bis zur Wiederherstellung geschäftskritischer Funktionalität bleibt unklar. Zweite Falle: Fehlende Transparenz bei Eskalationspfaden. Legen Sie eine Kontaktmatrix mit zeitgebundenen Eskalationsstufen fest.
Sicherheit und Compliance: Verantwortlichkeiten, Zugriff und Nachweisbarkeit
Sicherheitsverantwortung lässt sich vertraglich nicht vollständig auslagern. Datenschutz‑Grundverordnung (DSGVO) oder NIS2 zum Beispiel verlangen, dass Betreiber nachweisen können, wie Zugriffsrechte gehandhabt und Vorfälle gemeldet wurden. Wesentliche Prüffragen:
- Wer ist Datenverantwortlicher vs. Auftragsverarbeiter? (Die Begriffe beziehen sich auf rechtliche Rollen; der Datenverantwortliche legt Zweck und Mittel der Verarbeitung fest, der Auftragsverarbeiter handelt im Auftrag.)
- Sind Zugriffskontrollen durch Ihr Identity‑Provider zentral oder beim Managed Provider? Wie werden privilegierte Zugriffe (z. B. SSH‑Keys, Service‑Accounts) verwaltet und auditiert?
- Wie werden Security‑Incidents dokumentiert, und steht ein forensisch verwertbarer Audit‑Trail zur Verfügung?
Praktische Policy‑Vorlage: Privilegienentzug beim Offboarding
# Beispiel-Offboarding: Schritte (Checkliste für Administratoren)
# 1) Zugang sperren
usermod --expiredate 1
# 2) SSH-Keys entfernen
rm /home//.ssh/authorized_keys
# 3) API-Credentials rotieren
# (Beispiel für HashiCorp Vault, falls verwendet)
vault write auth/approle/role//secret-id -force
# 4) Passwort zurücksetzen für gemeinsame Konten (Audit-Log-Eintrag)
# 5) Revoke SSO Tokens (Identity Provider)
# Admin-Konsole: revoke-session --user
Dokumentieren Sie jeden Schritt mit Zeitpunkt und ausführender Person; das ist essenziell für Audits.
Personalmanagement: Skills, Succession Planning und Wissenserhalt
Ob Inhouse oder Managed Services: Nachfolgeplanung reduziert SPoF‑Risiken. Wichtige Maßnahmen sind Qualifikationsmatrizen, jährliche Runbooks, regelmäßige Recovery‑Übungen und Job‑Shadowing. Eine Qualifikationsmatrix zeigt, wer welche Systeme auf welcher Stufe bedienen kann — idealerweise mit einem Plan für Cross‑Training.
Succession‑Planning: Praktische Checkliste
- Identifizieren Sie kritische Rollen und dokumentieren Sie Kernaufgaben.
- Erstellen Sie mindestens zwei Personen pro kritischer Rolle (Primus und Stellvertreter).
- Führen Sie vierteljährliche Knowledge‑Transfers und halbjährliche Restore‑Übungen durch.
- Bewerten Sie regelmäßig die Lernkurve anhand konkreter Tasks (z. B. Recovery eines Service aus Backup).
Kosten und Risiko: TCO, versteckte Aufwände und FTE‑Äquivalente
Managed Services können direkte Personalkosten senken, verschieben jedoch oft Kosten in Form von Integrationsaufwand, Vertragsmanagement und Compliance‑Kontrollen. Berechnen Sie TCO nicht nur als reines monatliches Abo‑Gebühr, sondern addieren Sie:
- Interne Aufwände für Steuerung, Review und Audit (z. B. 0,2–0,5 FTE bei mittlerer Komplexität).
- Integrationsaufwand (APIs, IAM‑Brücken, Monitoring‑Feeds).
- Risikoaufschläge (z. B. Kosten durch verlängerte Wiederherstellungszeiten, wenn Eskalationen scheitern).
Eine einfache TCO‑Formel:
TCO = Anbietergebühr + Integrationskosten + Governance-Aufwand + (Restaurationskosten * Eintrittswahrscheinlichkeit)Audit‑Perspektive: Nachweise erstellen und prüfen
Für Audits benötigen Sie technische Nachweise: Zugriffsliste, Change‑Logs, SLA‑Reports, Incident‑Reports und Schulungsnachweise. Bei Managed Services sollte der Vertrag folgende Punkte regeln:
- Regelmäßiger Zugang zu Logs in maschinenlesbarem Format.
- Audit‑Rechte: Interne oder externe Prüfer müssen Zugang zu relevanten Prozessen und Nachweisen erhalten.
- Verfahren zur Behebung von Compliance‑Verstößen und Meldepflichten innerhalb definierter Fristen.
Vertragsgestaltung: Wie Verantwortlichkeiten vertraglich geregelt werden
Ein Vertrag ist mehr als SLA und Preis. Relevante Vertragsbestandteile:
- Rollen‑ und Verantwortlichkeitsmatrix (inkl. RACI‑Bezug).
- Definition der Schnittstellen: API‑Spektrum, Monitoring‑Feeds, Ticketing‑Integrationen.
- Datenzugriffs‑ und Datenschutzklauseln, inkl. Sub‑Processor‑Listen.
- Exit‑ und Transition‑Plan: Datenrückgabe, Wissenstransfer, Unterstützung beim Übergang zurück Inhouse oder zu anderem Anbieter.
Besonders wichtig ist ein Transition‑Plan mit festen Deliverables: Datendumps in standardisiertem Format, übertragene Runbooks, Schulungsslots und Shadowing‑Zeiträume.
Mindestinhalte eines Transition‑Milestone (Beispiel)
Milestone: Übergabe Produktivbetrieb
- Vollständige Datenexporte (Schema, Anwendungsdaten) in agreed format
- Zugriffsliste und Credential-Inventar übergeben
- Durchführung von 3 Knowledge-Transfer Sessions à 2 Stunden
- Dokumentierte Runbooks und Checklisten übergeben
- Support für 30 Tage nach Übergabe (Hotline + Ticketpriorität)
Entscheidungshilfe: Wann Inhouse, wann Managed Service?
Die Entscheidung hängt von fünf Faktoren: Kritikalität, Compliance‑Anforderungen, verfügbare interne Skills, Kostenrahmen und Zeitbedarf für Skalierung.
- Bevorzugen Sie Inhouse, wenn: starke regulatorische Vorgaben bestehen, Datenhoheit unerlässlich ist, oder das Geschäft Wettbewerbs‑ oder Prozessvorteile aus spezifischem Know‑how zieht.
- Bevorzugen Sie Managed Services, wenn: Sie schnell skalieren müssen, Spezialkenntnisse fehlen, oder Sie standardisierte Komponenten outsourcen können (z. B. E‑Mail‑Gateways, DDoS‑Schutz, Backup‑Storage).
Praktischer Entscheidungsbaum (Kurzfassung)
- Ist die Funktion regulatorisch kritisch? (Ja → Inhouse oder strenge Managed‑Verträge)
- Fehlen interne Skills und sind kurzfristig nicht aufbaubar? (Ja → Managed Services)
- Sind Datenhoheit oder niedrige Latenz geschäftskritisch? (Ja → Inhouse)
- Können Sie einen Transition‑Plan und Auditzugang vertraglich sicherstellen? (Nein → Kein Outsourcing)
Umsetzung: Integrations‑ und Kontrollmaßnahmen bei Outsourcing
Selbst bei Managed Services müssen Sie Kontrollstellen aufbauen:
- Monitoring‑Mirroring: Kopie wichtiger Metriken an interne Systeme.
- Regelmäßige Table‑Top‑Exercices für Incident Response mit Anbieter.
- Quarterly Business Reviews mit KPI‑Überprüfung (MTTR, Change‑Success‑Rate, Security‑Incidents).
- Technische Audits: Sandbox‑Umgebungen, Penetration‑Tests, Zugriffskontroll‑Reviews.
Beispiel: Kommandozeilen‑Checkliste für kurzfristige Validierung der Zugriffsrechte
# Überprüfung, welche Service-Accounts auf einem Linux-Host sudo-Rechte haben
getent group sudo || true
# Liste sudoers-Dateien
ls -l /etc/sudoers.d
# Prüfen, welche SSH-Keys einem Systemkonto zugeordnet sind
grep -R "authorized_keys" /home /root || true
Solche Checks sind Teil eines Audit‑Playbooks, das Sie mit dem Provider abstimmen sollten.
Inhouse vs. Managed Services: Personalrisiken konkret bewerten
Für eine fundierte Entscheidung sollten Sie Personalrisiken quantifizieren und operationalisieren. Dazu gehört die Identifikation kritischer Rollen, Bewertung altersbedingter Fluktuation, Marktverfügbarkeit von Skills und mögliche Beschaffungszeiten. Ein pragmatisches Bewertungsmodell kombiniert qualitative Faktoren mit drei Kennzahlen:
- SLE (Single Loss Expectancy): geschätzter finanzieller Schaden, falls eine Rolle ausfällt oder Wissen verloren geht.
- ARO (Annualized Rate of Occurrence): erwartete Eintrittswahrscheinlichkeit pro Jahr.
- ALE (Annualized Loss Expectancy) = SLE * ARO: erwarteter Jahresverlust durch Personalausfall.
Beispiel: Wenn der Ausfall eines Systemadministrators einen Geschäftsunterbruch von 20.000 EUR (SLE) verursacht und die Eintrittswahrscheinlichkeit 0,1 pro Jahr (ARO) beträgt, liegt die ALE bei 2.000 EUR. Nutzen Sie diese Werte, um Outsourcing‑Entscheidungen finanziell zu untermauern.
FTE‑Äquivalente und Steuerungsaufwand berechnen
Praktisch sollten Sie berechnen, wie viele interne FTE für Steuerung, Audit und Integration nötig sind. Eine grobe Orientierung:
- Low‑Touch Managed Service (standardisierte Komponente): 0,1–0,3 FTE interne Steuerung.
- Mid‑Touch (integrierte Plattform mit API/Monitoring): 0,3–0,6 FTE.
- High‑Touch (kritische, integrierte Betriebsfunktion): 0,5–1,0+ FTE inklusive Audit‑Aufwand.
Diese Schätzwerte berücksichtigen die Zeit für Reviews, Eskalationen, Audits und Knowledge‑Transfer‑Sitzungen. Legen Sie solche Schätzungen vor dem Vertragsabschluss als Budgetposten fest.
KPIs, Dashboards und Review‑Routinen für Providersteuerung
Konkrete KPIs machen Providerleistung vergleichbar und reduzieren personalabhängige Risiken durch messbare Erwartungen. Wichtige Metriken:
- MTTR nach Fehlerklasse (z. B. P1, P2, P3).
- First‑Time‑Fix‑Rate: Anteil der Incidents, die beim ersten Eingriff gelöst wurden.
- Change Success Rate: Anteil erfolgreicher Changes ohne Rollback.
- Time to Knowledge Transfer: Zeit, bis intern dokumentiertes Wissen vorhanden ist.
- Audit‑Bereitschaft: Anzahl und Vollständigkeit auditierter Logs pro Zeitraum.
Technisch empfiehlt sich ein Management‑Dashboard mit aggregierten Daten aus Ticketing, Monitoring und CI/CD. Konfigurieren Sie automatisierte Reports für Quarterly Business Reviews (QBR) und verpflichten Sie den Anbieter zu maschinenlesbaren Exporten.
Sample SLA‑Klausel (kopierbar)
SLA-Klausel: Verfügbarkeit und Eskalation
1) Serviceverfügbarkeit: 99,9% pro Kalendermonat für Funktion X
2) Reaktionszeiten:
- P1: Reaktion innerhalb 15 Minuten, Lösung oder Workaround innerhalb 4 Stunden
- P2: Reaktion innerhalb 1 Stunde, Lösung innerhalb 24 Stunden
3) Eskalationsmatrix: Stufe 1 (Support Engineer) 15 min → Stufe 2 (Team Lead) 60 min → Stufe 3 (Service Manager) 4 Std
4) Reporting: Tägliches Incident-CSV, wöchentliches KPI-Report im JSON-Format
5) Audit: Monatlicher Zugriff auf relevante Logs und vierteljährlicher PenTest-Report
Regulatorische Anforderungen und Auditbeispiele
Bei NIS2 oder branchenspezifischen Vorgaben verlangen Auditoren oft detaillierte Nachweise: wer wann auf welche Daten zugegriffen hat, welche Changes freigegeben wurden und dass Offboarding‑Prozesse wirksam sind. Prüfpunkte für Auditoren:
- Existenz und Anwendung eines privilegierten Zugriffskontrollverfahrens.
- Nachweis über regelmäßige Restore‑Tests und deren Ergebnisse.
- Belege für durchgeführte Knowledge‑Transfer‑Sitzungen im Transition‑Milestone.
- Vertragliche Audit‑Rechte und Protokoll der tatsächlichen Auditdurchführungen.
Vertragsklausel: Audit‑Rechte (Beispiel)
Audit-Klausel:
Der Auftragnehmer gewährt dem Auftraggeber oder dessen beauftragten Prüfern vierteljährlich Zugang zu relevanten Betriebs- und Sicherheitslogs, Testfällen und Dokumentationen. Prüfungen dürfen nicht mehr als zweimal jährlich unangekündigt stattfinden und müssen in einem vereinbarten Test‑Sandbox-Scope erfolgen. Ergebnisse sind innerhalb 15 Arbeitstagen zu dokumentieren und zu beheben.Onboarding, Offboarding und Trainingsplan (umsetzungsorientiert)
Ein präzises Onboarding reduziert spätere Abstimmungsaufwände. Kernbestandteile:
- Technische Integration: API‑Keys, VPN‑Verbindungen, IAM‑Brücken.
- Organisatorisches Onboarding: Verantwortlichkeiten, RACI, Kommunikationswege.
- Wissenstransfer: dokumentierte Runbooks, Hands‑on Sessions, Shadowing‑Zeiten.
Trainingsplan (90 Tage)
Tag 0-14: Systemzugänge, Architektur-Review, Zugangstests
Tag 15-45: Hands-on-Workshops (Recovery, Failover), 2x Knowledge-Transfer Sessions
Tag 46-75: Shadowing im Live-Betrieb, Teilnahme an Incidents als Beobachter
Tag 76-90: Selbstständige Ausführung von Recovery-Aufgaben, Abschluss-Review und Zertifikat
Checkliste für die Entscheidung (praxisnah)
- Kritikalitätsanalyse der zu outsourcenden Funktion
- Skills‑Gap‑Analyse und Trainingsplan
- SLA‑ und Eskalationsmatrix definiert
- RACI‑Matrix erstellt und kommuniziert
- Audit‑ und Reporting‑Zugang vertraglich gesichert
- Transition‑Plan mit Deliverables im Vertrag verankert
- Notfallplan und Wiederherstellungsübungen vereinbart
- Onboarding/Offboarding‑Prozesse technisch und organisatorisch abgesichert
Fazit: Verantwortlichkeiten bewusst verteilen und nachweisen
Die Wahl zwischen Inhouse und Managed Services ist kein Entweder‑Oder, sondern eine organisatorische Abwägung. Managed Services bieten Zugang zu Expertise und Skalierbarkeit, aber die Personalrisiken verlagern sich nicht weg — sie verändern ihre Form. Entscheidend sind klare Governance‑Regeln, überprüfbare SLAs, dokumentierte RACI‑Zuweisungen und ein Transition‑Plan, der Wissen und Audit‑Nachweise sicherstellt.
Technische Maßnahmen wie Monitoring‑Mirroring, Zugangskontrollen, regelmäßige Restore‑Übungen und ein stringentes Offboarding sind in beiden Modellen Pflicht. Treffen Sie die Entscheidung strategisch, mit einer belastbaren TCO‑Rechnung, quantifizierten Personalrisiken (SLE/ARO/ALE) und operationalisierten Steuerungs‑KPIs. Nur so lässt sich Personalrisiko messbar reduzieren — unabhängig davon, ob Services intern betrieben oder extern eingekauft werden.
Für dieses Thema sind auch Verantwortlichkeiten It und Sla Design wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.