Ein wirksames SOC erkennt relevante Vorfälle, bearbeitet sie nachvollziehbar und verbessert den Schutz nach dem Fall. Prüfen Sie dafür Datenabdeckung, Fallqualität, Bearbeitungs- und Wartezeiten sowie offene Folgearbeiten. Weniger Alarme oder schneller geschlossene Tickets sind nur ein Fortschritt, wenn wichtige Fälle weiterhin erkannt und angemessen bearbeitet werden.
Kurzfassung für Geschäftsführung und IT-Leitung
Ein guter Sicherheitsbetrieb kann zeigen:
- welche geschäftskritischen Systeme tatsächlich überwacht werden;
- warum ausgewählte Vorfälle so eingestuft und geschlossen wurden;
- wie lange Bewertung, Freigabe und wirksame Maßnahme jeweils gedauert haben;
- welche technischen oder organisatorischen Verbesserungen aus Vorfällen entstanden sind;
- ob frühere Verbesserungen umgesetzt und getestet wurden.
Beantwortet der Monatsbericht diese Fragen nicht, brauchen Sie für das Review zusätzliche Fall- und Umsetzungsnachweise.
Beginnen Sie mit einem belegten Engpass im Ablauf, bevor Sie weitere Regeln oder Werkzeuge einführen.
Fünf Warnsignale für Verbesserungsbedarf
Achten Sie auf wiederkehrende Zusatzarbeit, unklare Wartezeiten und offene Maßnahmen. Selbst ein SOC mit vielen bearbeiteten Meldungen kann Ihre IT unnötig belasten. Die folgenden Beobachtungen eignen sich als Einstieg ins Review.
| Beobachtung | Die Frage für das nächste Gespräch |
|---|---|
| Ihre IT erklärt wiederholt dieselbe erlaubte Aktivität. | Warum ist dieser Kontext noch nicht im Bearbeitungsablauf berücksichtigt? |
| Tickets werden schnell geschlossen, die Begründung bleibt unklar. | Welche Hinweise wurden geprüft und warum war keine weitere Maßnahme erforderlich? |
| Ein kritischer Vorfall wartet auf Rückmeldung. | Fehlen Ansprechpartner, Befugnisse oder technische Zugriffe? |
| Der Bericht zeigt keine Vorfälle aus einem wichtigen Standort. | Ist dort nichts aufgefallen oder fehlen Daten beziehungsweise Erkennungsregeln? |
| Dieselbe Ursache taucht erneut auf. | Welche Änderung wurde nach dem letzten Fall vereinbart und wurde ihre Wirkung geprüft? |
Wählen Sie für das Review auch einen offenen, einen automatisch geschlossenen und einen folgenreichen Fall. So sehen Sie, ob Rückstände, falsche Einstufungen oder interne Freigaben im Bericht erkennbar sind.
Prüfen Sie bei Kennzahlen, was gezählt wird. Defender XDR kann mehrere Alarme zu einem Vorfall zusammenführen. Alarmzahlen, Vorfallzahlen und geschlossene Tickets sind daher nicht direkt vergleichbar. Jeder Bericht braucht eine klare Zählweise und einen Zeitraum. Microsoft Learn, Alarme untersuchen, abgerufen am 21.09.2026.
Sind Ihre kritischen Systeme wirklich abgedeckt?
Vergleichen Sie den vereinbarten Schutzumfang mit einem vollständigen Bestand Ihrer kritischen Systeme. Das Defender- oder Sentinel-Portal zeigt nur die dort bekannten Geräte und Datenquellen. Prüfen Sie deshalb je System, welche Signale erwartet werden, wann zuletzt Daten eingingen und wer auf eine Lücke reagiert.
Microsoft stellt für Defender for Endpoint Berichte zur Sensorintegrität bereit, die unter anderem aktive und inaktive Sensoren sowie beeinträchtigte Kommunikation oder fehlende Sensordaten unterscheiden. Microsoft Learn, Geräte- und Sensorintegrität, abgerufen am 21.09.2026. Für unterstützte Sentinel-Ressourcen lässt sich ebenfalls eine Zustandsüberwachung einrichten, einschließlich Datenkonnektoren, Erkennungsregeln und Automatisierungen. Microsoft Learn, Systemzustandsüberwachung für Sentinel, abgerufen am 21.09.2026.
Die entscheidende Frage für die Geschäftsführung lautet: Welche kritischen Systeme sind derzeit nicht wie vereinbart abgedeckt, und wer schließt die Lücke bis wann?
| System oder Systemgruppe | Erwarteter Schutzumfang | Aktueller Nachweis |
|---|---|---|
| Geschäftskritische Server | Vereinbarte Erkennung und Reaktion | Abgleich Bestand, Sensorzustand, letzter Funktionstest |
| Benutzer mit weitreichenden Rechten | Vereinbarte Identitätsüberwachung | Angebundene Signale und getesteter Anwendungsfall |
| E-Mail und Zusammenarbeit | Vereinbarte Schutz- und Untersuchungsfunktionen | Lizenz, Richtlinienumfang und Testnachweis |
| Weitere angebundene Systeme | Beispielsweise vereinbarte Firewall-Ereignisse | Datenfluss, Datenqualität und verwendete Regel |
Auch ein grüner Datenfluss beweist keine wirksame Erkennung. Testen Sie für kritische Bereiche einen vereinbarten Fall von der Erkennung über die Eskalation bis zur Reaktion. Microsoft Learn, SOC-Anwendungsfälle entwickeln und testen, abgerufen am 21.09.2026.
Fehlalarme reduzieren, ohne blinde Flecken zu erzeugen
Wiederkehrende Fehlalarme kosten Zeit. Blenden Sie sie nicht pauschal aus. Klären Sie, warum die Aktivität zulässig ist und wodurch sie sich von einem Angriff unterscheiden lässt. Passen Sie erst danach Regeln, Ausnahmen oder den Bearbeitungsablauf an und testen Sie die Erkennung erneut.
Microsoft beschreibt für Sentinel unter anderem normale Aktivitäten von Dienstidentitäten und beabsichtigte Sicherheitsscans als Ursachen wiederkehrender unkritischer Meldungen und nennt zeitlich begrenzte Ausnahmen sowie gezielte Regelanpassungen als Weg. Microsoft Learn, Umgang mit Fehlalarmen in Sentinel, abgerufen am 21.09.2026.
So muss eine vertretbare Ausnahme dokumentiert sein
Fiktives Beispiel
Ein genehmigter Wartungsvorgang erzeugt regelmäßig Meldungen. Als Lösung wird vorgeschlagen, das verwendete Administrationskonto dauerhaft auszunehmen.
Grenzen Sie die erlaubte Aktivität möglichst genau ein: nach Vorgang, System, Zeitraum und weiteren bekannten Merkmalen. Ist das technisch nicht möglich, bewerten Sie ausdrücklich, welche Sicht verloren geht. Dokumentieren Sie zu jeder Ausnahme:
- warum die Aktivität als zulässig eingeordnet wurde;
- welche Bedingungen und Systeme die Ausnahme erfasst;
- welcher sicherheitsrelevante Testfall weiterhin erkannt werden muss;
- wer die Änderung verantwortet und wann sie erneut geprüft wird;
- wie die vorherige Regel bei Problemen wiederhergestellt werden kann.
Defender XDR ermöglicht benutzerdefinierte Erkennungen auf Basis von Abfragen. Sie können Meldungen und Reaktionen auslösen. Fügen Sie solche Regeln für konkrete Sicherheitsfälle hinzu, nicht zur Erhöhung der Regelzahl. Microsoft Learn, benutzerdefinierte Erkennungen, abgerufen am 21.09.2026.
Prüfen Sie nach jeder Anpassung den Datenfluss und einen vereinbarten Testfall. Sinkende Alarmzahlen allein sagen nichts über die Schutzwirkung aus: Auch ein ausgefallener Sensor meldet weniger.
Wie lange dauert es bis zur wirksamen Maßnahme?
Erfassen Sie vier Zeitpunkte: Wann war die Meldung verfügbar, wann wurde sie bewertet, wann lag die Freigabe vor und wann wirkte die Maßnahme? So erkennen Sie, ob das SOC, ein interner Freigabeweg oder die Technik bremst. Das Action Center zeigt ausstehende und abgeschlossene Aktionen; bei einer Geräteisolation beeinflusst auch die Erreichbarkeit des Geräts den Ablauf. Microsoft Learn, Action Center und Microsoft Learn, Reaktionsaktionen auf einem Gerät, abgerufen am 21.09.2026.
Was kann hinter einer guten Reaktionszeit stecken?
Das folgende Beispiel ist vollständig fiktiv. Es zeigt einen Ablauf während der vereinbarten Servicezeit und ist weder eine SLA-Empfehlung noch ein Kundenfall.
| Zeitpunkt | Ereignis |
|---|---|
| 09:00 Uhr | Die Meldung steht dem zuständigen Team zur Verfügung. |
| 09:08 Uhr | Ein Analyst hat den Fall bewertet und Handlungsbedarf festgestellt. |
| 09:10 Uhr | Eine wegen der Betriebswirkung erforderliche Freigabe wird angefordert. |
| 09:46 Uhr | Die Freigabe trifft ein. |
| 09:50 Uhr | Die vereinbarte Maßnahme ist ausgeführt und ihre Wirkung bestätigt. |
Die Erstbewertung dauert im Beispiel 8 Minuten, die Freigabe dagegen 36 Minuten. Erst nach insgesamt 50 Minuten ist die Wirkung bestätigt. Der wichtigste Ansatzpunkt ist hier der Freigabeweg, nicht die Ticketannahme.
Wie werden Zeiten vergleichbar?
Definieren Sie für jeden Zeitwert Start, Ende und Fallgruppe. Weisen Sie Wartezeiten auf Freigaben, externe Stellen und Technik getrennt aus. Sie bleiben für das Geschäftsrisiko relevant, auch wenn sie nicht vollständig in die vertragliche Reaktionszeit einfließen. Nennen Sie keine genaue „Erkennungszeit“, wenn der Angriffsbeginn unbekannt ist. Trennen Sie außerdem Eindämmung, Ursachenbehebung und Wiederherstellung.
Sechs Messgrößen für Ihr SOC-Review
Wenige gut erklärte Messgrößen helfen mehr als ein Dashboard voller Zahlen. Für ein gemeinsames Review von IT und Geschäftsführung empfehlen wir: Abdeckung kritischer Systeme, Fallqualität, Zeit bis zur Bewertung, Zeit bis zur bestätigten Maßnahme, überfällige Aufgaben und abgeschlossene Verbesserungen.
| Kennzahl | Wie sie nachvollziehbar wird | Welche Entscheidung sie unterstützt |
|---|---|---|
| Abdeckung kritischer Systeme | Sollbestand, tatsächlich verfügbare Daten, Ausnahmen und letzte Tests getrennt ausweisen. | Wo muss die Beobachtung zuerst vervollständigt werden? |
| Qualität der Fallbearbeitung | Dokumentierte Stichprobe mit geprüften Hinweisen, nachvollziehbarer Einstufung und begründetem Abschluss. | Wo fehlen Kontext, Fachwissen oder einheitliche Abläufe? |
| Zeit bis zur qualifizierten Bewertung | Vereinbarter Startzeitpunkt bis zur dokumentierten fachlichen Einordnung, getrennt nach Schweregrad. | Reicht die Besetzung für die benötigte Bearbeitung? |
| Zeit bis zur bestätigten Maßnahme | Fälle mit erforderlicher Maßnahme, deren tatsächlicher Status und Wartezeiten. | Fehlen Rechte, Freigaben, Erreichbarkeit oder technische Voraussetzungen? |
| Überfällige offene Aufgaben | Bestand und Alter offener Fälle, Genehmigungen und Verbesserungen zum Stichtag. | Welche Blockaden muss die Leitung lösen? |
| Nachweislich abgeschlossene Verbesserungen | Umgesetzte Änderung mit vereinbartem Funktionstest, Verantwortlichem und Ergebnis. | Wofür wurde das Verbesserungsbudget eingesetzt? |
Alarmzahlen, geschlossene Tickets und Durchschnittszeiten brauchen Kontext. Zeigen Sie Fallzahl, Zeitraum, Schutzumfang und offene Fälle daneben. Gab es keine kritischen Fälle, wurde auch keine Reaktionszeit von null gemessen. Offene Fälle gehören in den Bericht, obwohl ihre Abschlussdauer noch nicht feststeht.
Bei vielen Fällen zeigen Median und ein hoher Perzentilwert lange Bearbeitungen besser als ein Durchschnitt allein. Bei wenigen Fällen sind einzelne Zeitverläufe aussagekräftiger. Leiten Sie Zielwerte aus Ihren Geschäftsanforderungen und dem vereinbarten Service ab.
Was sagt der Secure Score über Ihr SOC aus?
Der Microsoft Secure Score hilft, Schutzmaßnahmen zu priorisieren. Er zeigt jedoch nicht, ob Ihr Team Alarme zuverlässig bewertet, rechtzeitig eskaliert und Verbesserungen umsetzt. Nutzen Sie ihn als Hinweis auf technische Schutzmaßnahmen, nicht als alleinigen Nachweis für den SOC-Betrieb. Microsoft Learn, Microsoft Secure Score, abgerufen am 21.09.2026.
So wird aus einem Vorfall eine überprüfbare Verbesserung
Nach der Eindämmung bleiben oft Aufgaben offen. Halten Sie für jede relevante Verbesserung eine verantwortliche Person, einen Termin und ein prüfbares Ergebnis fest. Das kann eine technische Änderung, ein kürzerer Freigabeweg, eine zusätzliche Datenquelle oder eine klare Zuständigkeit sein. Fragen Sie nach einem relevanten Fall:
- Was ist durch die verfügbaren Hinweise belegt und was bleibt eine Vermutung?
- Welche Maßnahme hat die akute Situation begrenzt?
- Welche technische oder organisatorische Änderung soll eine Wiederholung erschweren?
- Wer setzt sie um und wer prüft das Ergebnis?
Nicht jede Ursache lässt sich abschließend rekonstruieren. Fehlen Daten, sollte das offen dokumentiert werden. Daraus kann selbst eine Verbesserung entstehen, etwa die künftig benötigten Ereignisse verfügbar zu machen.
Wie formulieren Sie eine überprüfbare Aufgabe?
Beschreiben Sie die Änderung mit Zielsystem, Verantwortlichem und Test. „Defender optimieren“ allein ist nicht prüfbar.
| Unzureichend bestimmt | Besser überprüfbar formuliert |
|---|---|
| „Defender optimieren“ | Die vereinbarte Datenquelle wieder anbinden und den Datenfluss sowie den zugehörigen Testfall prüfen. |
| „Fehlalarme reduzieren“ | Die belegte Wartungsaktivität enger abgrenzen und nachweisen, dass der vereinbarte unzulässige Testfall weiter erkannt wird. |
| „Eskalation verbessern“ | Vertretung für den benannten Freigabeweg festlegen und deren Erreichbarkeit im vereinbarten Verfahren testen. |
| „Richtlinie härten“ | Die freigegebene Änderung auf die festgelegte Zielgruppe anwenden, Ausnahmen dokumentieren und technische sowie betriebliche Wirkung prüfen. |
Felder einer Verbesserungsaufgabe
Auslöser: Welcher Vorfall oder Befund führte zur Aufgabe?
Änderung: Was wird konkret angepasst?
Verantwortlich: Wer setzt die Änderung um?
Termin: Bis wann?
Abnahmetest: Woran erkennen wir, dass die gewünschte Wirkung erreicht wurde?
Rest-Risiko: Welche Einschränkung bleibt bestehen?
Planen Sie Zeit für die Umsetzung ein. Wenn der Vertrag nur Untersuchungen und Empfehlungen umfasst, braucht es dafür eine zuständige Person. Bei einem festen Optimierungskontingent priorisieren Sie die Aufgaben und regeln zusätzlichen Aufwand.
Sentinel-Kosten optimieren, ohne benötigte Sichtbarkeit zu verlieren
Prüfen Sie vor einer Kostensenkung, wofür jede teure Datenquelle gebraucht wird: für welche Erkennung, Untersuchung oder Nachweispflicht? Erst dann lassen sich Datenmenge, Aufbewahrung und doppelte Verarbeitung sinnvoll anpassen. Microsoft Learn, Sentinel-Kosten und Abrechnung, abgerufen am 21.09.2026.
Fragen Sie bei jeder Quelle nach den unterstützten Regeln, dem Untersuchungsbedarf und der nötigen Aufbewahrungszeit. Auch Daten, die derzeit keine Regel nutzt, können für spätere Untersuchungen wichtig sein.
Wann zusätzliche Automatisierung oder KI wirklich hilft
Prüfen Sie zuerst die vorhandene Automatisierung in Defender. Je nach Konfiguration kann sie Untersuchungen und bestimmte Maßnahmen ausführen oder zur Freigabe vorlegen. Microsoft Learn, automatisierte Untersuchung und Reaktion, abgerufen am 21.09.2026.
Testen Sie neue Automatisierung oder KI an einem wiederkehrenden Arbeitsschritt. Legen Sie fest, welches Ergebnis korrekt ist, wie Sie Fehler erkennen und wann ein Mensch eingreift. Messen Sie Zeitgewinn, Ergebnisqualität und Nacharbeit. Bei eingreifenden Aktionen brauchen Sie geregelte Rechte, Ausnahmen und einen Weg zur Rücknahme. Eine KI-Zusammenfassung sollte auf prüfbare Hinweise verweisen.
So wird aus dem SOC-Bericht eine Entscheidung
Bereiten Sie ausgewählte Fälle und technische Befunde vor. Im Review besprechen Geschäftsführung, IT und Dienstleister die Punkte, die eine Entscheidung brauchen: Datenlücken, Wartezeiten, offene Aufgaben, Kostenänderungen und frühere Beschlüsse.
| Gegenstand | Ergebnis, das im Termin vorliegen sollte | Beschluss |
|---|---|---|
| Vereinbarter Umfang und Datenlücken | Bekannte Einschränkungen einschließlich kritischer Systeme und ihrer Auswirkungen. | Wer beseitigt welche Lücke bis wann? |
| Ausgewählte Vorfälle | Nachvollziehbare Einstufung, Zeitverlauf, Maßnahmen und offene Fragen. | Welcher Engpass wird zuerst bearbeitet? |
| Änderungen an Erkennungen | Begründung, erwartete Wirkung, Test und verbleibende Einschränkung. | Freigeben, nachbessern oder zurücknehmen? |
| Offene Folgearbeiten | Verantwortliche, Fristen, Blockaden und benötigte Kapazität. | Welche Entscheidung oder Ressource fehlt? |
| Betriebskosten | Kostenänderungen mit fachlicher Begründung. | Beibehalten, untersuchen oder gezielt anpassen? |
| Abschluss vorheriger Beschlüsse | Dokumentierte Umsetzung und Prüfung der vereinbarten Wirkung. | Erledigt oder mit begründetem nächsten Schritt weiterführen? |
Halten Sie zu jedem Beschluss fest, wer bis wann handelt und welcher Nachweis die Umsetzung zeigt.
Nutzen Sie dafür vorhandene Tickets, Zeitstempel und Aufgabenlisten. Ein zusätzliches Berichtssystem ist nicht nötig, wenn sich daraus Entscheidungen nachvollziehbar treffen lassen. Fragen zur Auswahl eines Dienstes behandelt unser Artikel Microsoft-SOC für kleine IT-Teams.
Begründet ein Dienstleister Entscheidungen wiederholt nicht oder erbringt vereinbarte Leistungen nicht, dokumentieren Sie die Fälle und vereinbaren Sie Korrekturen mit Termin. Prüfen Sie dabei auch, ob interne Freigaben, Zugriffe oder Zuständigkeiten fehlen. Für die wirtschaftliche Bewertung eines Wechsels hilft die Aufstellung im Artikel Eigenbetrieb oder MDR.
Wie hochzwei den SOC-Betrieb verbessert
Bei MDR von hochzwei gehören neben der Bearbeitung vereinbarter Sicherheitsfälle in beiden Stufen zwei Stunden Optimierung pro Monat zum Leistungsmodell. Wir priorisieren die Arbeiten mit Ihrer IT und halten Befugnisse und Freigabewege im Service-Handbuch fest. Zusätzliche Arbeiten werden gesondert vereinbart.
Bringen Sie zum Erstgespräch einen Monatsbericht und einen Fall mit, dessen Bearbeitung Sie verbessern möchten. Daran können wir Datenabdeckung, Wartezeiten und nächste Schritte konkret besprechen.
Häufige Fragen
Woran erkennen wir, ob unser MDR-Dienst gute Arbeit leistet?
Prüfen Sie konkrete Fälle und den vereinbarten Umfang. Wichtige Punkte sind verfügbare Daten, nachvollziehbare Einstufungen, die tatsächliche Bearbeitung, bestätigte Maßnahmen und offene Folgeaufgaben. Eine große Zahl geschlossener Tickets allein belegt die Qualität nicht.
Sind weniger Alarme immer ein gutes Zeichen?
Nein. Die Zahl kann durch gezielte Verbesserungen sinken, aber auch durch fehlende Daten oder zu breite Ausnahmen. Prüfen Sie bei Änderungen, ob die benötigten Daten weiter ankommen und vereinbarte sicherheitsrelevante Testfälle weiterhin erkannt werden.
Welche Reaktionszeit sollten wir messen?
Unterscheiden Sie die Zeit bis zur qualifizierten Bewertung von der Zeit bis zu einer bestätigten Maßnahme. Definieren Sie jeweils Start, Ende und Fallgruppe. Zeigen Sie Wartezeiten und offene Fälle separat sowie Kalenderzeit und Zeit innerhalb des Servicefensters getrennt.
Beweist ein hoher Secure Score, dass unser SOC funktioniert?
Nein. Secure Score unterstützt die Bewertung und Umsetzung empfohlener Schutzmaßnahmen. Er belegt nicht, dass Alarme zuverlässig bearbeitet werden, und ist keine Garantie gegen Sicherheitsvorfälle. Dafür müssen Sie die tatsächlichen Abläufe prüfen.
Können wir Sentinel-Kosten durch weniger gespeicherte Daten senken?
Das kann möglich sein, muss aber gegen die benötigten Erkennungen, Untersuchungen und Aufbewahrungsanforderungen geprüft werden. Lassen Sie den Zweck einer Datenquelle klären, bevor Sie Erfassung oder Aufbewahrung reduzieren. Eine kurzfristige Kostensenkung kann sonst benötigte Informationen entfernen.
Müssen wir für die Optimierung den SOC-Anbieter wechseln?
Nicht automatisch. Prüfen Sie zunächst, ob die Probleme aus Datenlücken, internen Freigaben, unklarem Leistungsumfang oder der tatsächlichen Bearbeitung entstehen. Vereinbaren Sie konkrete Korrekturen und überprüfen Sie deren Umsetzung. Ein Wechsel kommt infrage, wenn erforderliche Leistungen weiterhin nicht verlässlich erbracht werden.
Was sollte ein guter monatlicher SOC-Bericht mindestens zeigen?
Er sollte nicht nur Fallzahlen enthalten, sondern den vereinbarten Schutzumfang, relevante Datenlücken, ausgewählte Vorfälle mit nachvollziehbarer Einstufung, wichtige Reaktions- und Wartezeiten, offene Folgearbeiten sowie den Status früher beschlossener Verbesserungen. Der Bericht sollte so aufgebaut sein, dass IT-Leitung und Geschäftsführung daraus konkrete Entscheidungen ableiten können.
Über den Autor
Manuel Fetscher ist Geschäftsführer der hochzwei tech GmbH und beschäftigt sich mit Microsoft Defender, Microsoft 365 Security und dem operativen Betrieb von Sicherheitsumgebungen für Unternehmen.
Die technischen Aussagen stützen sich auf die verlinkte Microsoft-Dokumentation, abgerufen am 21.09.2026. Kennzahlenauswahl, Prüffragen und Review-Vorlagen sind redaktionelle Vorschläge von hochzwei. Der Zeitverlauf ist ein frei gewähltes Rechenbeispiel und keine zugesagte Reaktionszeit, kein Durchschnitt und kein Kundenfall. Es werden keine Leistungsbenchmarks und keine Einsparquoten behauptet. Die Angabe zum Optimierungskontingent gibt den Stand unserer Leistungsbeschreibung wieder, maßgeblich ist der konkrete Auftrag.