Eine Security-Plattform kann technisch korrekt eingerichtet und im Alltag trotzdem fragil sein. Das passiert, wenn Wissen bei wenigen Personen liegt, Routineänderungen eskalieren und niemand eindeutig für Qualität, Monitoring oder Policy-Lifecycle verantwortlich ist.
Fachkräftemangel zeigt sich deshalb nicht nur in offenen Stellen. Er zeigt sich in Wartezeiten, Ausnahmen, Nacharbeiten und einer wachsenden Abhängigkeit von Einzelpersonen.
Die folgenden sieben Warnzeichen helfen, das Betriebsmodell zu prüfen.
1. Jede Änderung landet bei derselben Person
Wenn nur eine Administratorin oder ein Administrator Regeln, Zertifikate oder Connectoren sicher beurteilen kann, besteht ein Konzentrationsrisiko. Urlaub und parallele Projekte werden sofort zum Engpass.
Die Lösung ist nicht zwingend ein größeres Team. Oft helfen dokumentierte Entscheidungskriterien, Rollen, Vier-Augen-Prinzip und standardisierte Änderungswege. Wiederkehrende Tätigkeiten werden delegierbar, während kritische Entscheidungen bei erfahrenen Personen bleiben.
2. Der Service Desk kann Fälle nur weiterleiten
Ein Ticket enthält „Zugriff geht nicht“, aber keine Angaben zu Nutzer, Gerät, Policy, Ziel, Zeitpunkt oder Fehlerbild. Der Second Level beginnt jede Diagnose von vorn.
Ein belastbares Modell definiert Mindestinformationen und erste Prüfschritte. Der Service Desk muss nicht zum Zscaler-Admin werden. Er braucht aber genug Kontext, um bekannte Ursachen zu erkennen, Daten vollständig zu erfassen und gezielt zu eskalieren.
3. Ausnahmen haben keinen Owner und kein Ablaufdatum
SSL-Inspection-Bypässe, temporäre Freigaben und Sondergruppen wachsen über Jahre. Ohne dokumentierten Grund und Wiedervorlage wird der Bestand unprüfbar.
Jede Ausnahme sollte mindestens fachlichen Owner, technischen Grund, Risikoentscheidung und Review-Datum besitzen. Ungeklärte Einträge werden nicht pauschal gelöscht, sondern priorisiert untersucht.
4. Monitoring zeigt Ereignisse, aber keine Handlungslogik
Viele Dashboards bedeuten nicht automatisch Betriebsfähigkeit. Entscheidend ist, ob aus einem Signal eine klare nächste Aktion folgt.
Für kritische Ereignisse braucht es Schwellenwert, Verantwortlichen, Erstprüfung, Eskalationsweg und Abschlusskriterium. So wird aus Telemetrie ein Prozess. Ohne diese Logik bleibt Monitoring ein weiteres System, das jemand gelegentlich öffnen muss.
5. Policy-Änderungen sind technisch, aber nicht fachlich abgenommen
Eine Regel kann syntaktisch korrekt sein und dennoch eine Geschäftsanforderung verfehlen. Wenn Anwendungsowner oder Risk Owner nicht eingebunden sind, trägt das Security-Team Entscheidungen, die es fachlich nicht allein treffen kann.
Ein gutes Change-Modell verbindet Antrag, Begründung, Testfall, Freigabe, technische Umsetzung und Nachkontrolle. Für Standardfälle gibt es Vorlagen; Sonderfälle bleiben bewusst sichtbar.
6. Updates und Zertifikate werden erst bei Störungen bemerkt
Connector-Versionen, Client-Lebenszyklen, Zertifikate und Integrationen erzeugen wiederkehrende Arbeit. Fehlt eine vorausschauende Übersicht, wird aus planbarer Wartung ein Incident.
Ein Betriebskalender mit Owner, Vorlauf und Abhängigkeiten schafft hier oft mehr Wirkung als zusätzliche Ad-hoc-Kapazität. Wichtig ist die Verbindung zu Testumgebung, Rollback und Kommunikationsweg.
7. Niemand kann sagen, ob der Betrieb besser wird
Ohne Messpunkte bleibt Optimierung subjektiv. Geeignete Kennzahlen sind nicht nur Ticketzahlen. Aussagekräftiger können sein:
- Anteil vollständig vorqualifizierter Tickets,
- Zeit bis zur richtigen Zuständigkeit,
- Alter und Anzahl ungeklärter Ausnahmen,
- Änderungsfehler und Rollbacks,
- Zertifikate oder Komponenten vor Fälligkeit,
- wiederkehrende Ursachen,
- Anteil standardisierter Betriebsabläufe.
Kennzahlen sollten Entscheidungen unterstützen, nicht Aktivität belohnen.
Vom Engpass zum Service Design
Ein Managed Service ist dann wertvoll, wenn er diese Lücken gezielt schließt. Eine pauschale Zusage „wir übernehmen den Betrieb“ reicht nicht. Benötigt werden Serviceumfang, Rollen, Übergabepunkte, Servicezeiten, Reaktionslogik, Reporting, Change-Verfahren und Exit-Regeln.
SourcingBlox beginnt deshalb mit einer Betriebsanalyse: Welche Plattformteile sind im Scope? Welche Tätigkeiten fallen tatsächlich an? Wo liegen Wissen und Zugänge? Welche Vorgänge können standardisiert werden? Welche Entscheidungen müssen beim Kunden bleiben?
Darauf folgen ein priorisierter Verbesserungsplan, Runbooks, Governance und – sofern passend – ein klar abgegrenztes Managed-Betriebsmodell. Konkrete Servicezeiten und Reaktionszeiten werden erst nach Leistungs- und Vertragsprüfung zugesagt.
Das Ziel ist nicht, interne Expertise zu ersetzen. Es ist, erfahrene Personen von wiederkehrender Koordination und Routinearbeit zu entlasten, damit sie sich auf Architektur, Risiko und schwierige Fälle konzentrieren können.
Ein 30-Tage-Check für den bestehenden Betrieb
Bevor ein neues Service-Modell entworfen wird, lohnt sich ein begrenzter Blick auf reale Arbeit. Über 30 Tage werden keine Personen bewertet, sondern Arbeitsmuster erfasst:
- Welche Ticketarten erreichen den Second Level?
- Welche Angaben fehlen regelmäßig?
- Welche Änderungen wiederholen sich?
- Welche Ausnahme benötigt die meiste Abstimmung?
- Welche Warnungen bleiben ohne Owner?
- Welche Tätigkeit hängt von genau einer Person ab?
- Welche geplante Wartung wurde zum Incident?
Bereits diese Stichprobe zeigt, ob das Hauptproblem Kapazität, fehlender Kontext, unklare Verantwortung oder unnötige Varianz ist.
Routine standardisieren, Entscheidungskompetenz erhalten
Standardisierung bedeutet nicht, jeden Fall starr zu automatisieren. Sie trennt vielmehr drei Arbeitsarten.
Erstens gibt es wiederkehrende Prüfungen mit klarer Entscheidung: Status erheben, Mindestdaten sammeln, bekannten Fehlerpfad prüfen. Diese Arbeit lässt sich durch Runbooks oder geeignete Werkzeuge beschleunigen.
Zweitens gibt es kontrollierte Standardänderungen. Sie benötigen Vorlage, Berechtigung, Protokoll und gegebenenfalls Freigabe, aber nicht jedes Mal eine neue Architekturdiskussion.
Drittens bleiben echte Risiko- und Architekturentscheidungen. Sie gehören bewusst zu erfahrenen Verantwortlichen. Wenn Routine vorher sauber abgefangen wird, steht dafür mehr Zeit zur Verfügung.
Ein sinnvolles Service-Design bleibt überprüfbar
Für jeden Servicebaustein sollten Eingang, Ergebnis und Grenze sichtbar sein. Ein Beispiel:
- Eingang: vollständig qualifiziertes Zugriffsproblem mit Nutzer-, Geräte-, Ziel- und Zeitkontext.
- Leistung: Policy-, Posture- und Pfadprüfung innerhalb des vereinbarten Scopes.
- Ergebnis: Ursache, nächste Aktion oder begründete Eskalation.
- Grenze: Anwendungscode, nicht freigegebene Drittanbieteränderung oder fehlender Zugang.
Diese Klarheit reduziert Reibung zwischen internem Team und Dienstleister. Sie verhindert zugleich, dass „Managed Service“ als unbegrenzte Zuständigkeit verstanden wird.
Welche Verbesserungen nach 90 Tagen sichtbar sein sollten
Nach einer Übergangsphase müssen Ergebnisse messbar sein. Erwartbar sind beispielsweise vollständigere Tickets, weniger ungeklärte Ausnahmen, klarere Wartungsvorläufe und ein geringerer Anteil von Fällen, die nur wegen fehlenden Kontexts eskalieren.
Bleiben diese Effekte aus, wird nicht einfach mehr Kapazität ergänzt. Scope, Runbooks, Zugänge, Telemetrie und Rollen werden erneut geprüft. Ein belastbares Betriebsmodell lernt aus tatsächlicher Arbeit.