SOC-Anbieter-Auswahl: 8 Kriterien & Checkliste

SOC-Anbieter: Die wichtigsten Kriterien

SOC-Anbieter auswählen: Die wichtigsten Kriterien auf einen Blick

Bei der Auswahl eines SOC-Anbieters entscheiden acht Kriterien: SLA-Garantien, Zertifizierungen, Datenstandort, Technologie-Unabhängigkeit, Eskalationsprozesse, Referenzen, Onboarding und Reporting. Ein belastbares Angebot definiert nicht nur Leistungen, sondern auch Messpunkte, Verantwortlichkeiten, Ausschlüsse und den Umgang mit Abweichungen.

Vergleichen Sie Anbieter deshalb nicht anhand einer einzelnen Reaktionszeit oder Zertifizierung. Prüfen Sie, ob Leistung, Technologie, Datenverarbeitung und Betriebsmodell zu Ihren Risiken passen und ob der Vertrag im Ernstfall eindeutig genug ist. Kosten und das passende Betriebsmodell sollten separat bewertet werden; dieser Ratgeber konzentriert sich auf die Anbieter- und Vertragsprüfung.

Warum die Anbieterauswahl über den SOC-Erfolg entscheidet

Ein SOC-Dienstleister erhält Zugang zu sicherheitsrelevanten Daten und wird Teil kritischer Analyse-, Kommunikations- und Eskalationsprozesse. Schwache Verantwortungsabgrenzung, unklare SLAs oder fehlende Exit-Regelungen werden deshalb nicht erst bei Vertragsende sichtbar, sondern häufig im Incident. Die Auswahl sollte Fachbereich, IT, Informationssicherheit, Datenschutz, Einkauf und Recht einbeziehen.

8 Kriterien für die Auswahl

8 Kriterien für die Auswahl eines SOC-Anbieters

Reaktionszeiten und SLA-Garantien

Ein gutes SLA definiert je Prioritätsstufe, wann die Messung beginnt, welche Leistung innerhalb welcher Zeit geschuldet ist und wann eskaliert wird. Fragen Sie nicht nur nach „Reaktionszeit“, sondern nach Erstreaktion, Qualifizierung, Benachrichtigung und dem jeweiligen Messende.

Zertifizierungen und Compliance-Nachweise

Eine ISO/IEC-27001-Zertifizierung kann zeigen, dass ein Anbieter ein Informationssicherheitsmanagementsystem innerhalb eines festgelegten Scopes betreibt. Prüfen Sie daher Zertifikat, Gültigkeit, Zertifizierungsstelle und vor allem den Scope. Das Zertifikat ersetzt weder Leistungsprüfung noch technische Due Diligence.

Datenstandort, Rechtsraum und Analystenstandort

Klären Sie, wo Logdaten, Tickets, Backups und Analyseergebnisse verarbeitet und gespeichert werden, aus welchen Ländern Analysten zugreifen und welche Unterauftragnehmer beteiligt sind. Bei personenbezogenen Daten sind Rollen, Weisungen und vertragliche Regelungen zur Auftragsverarbeitung zu prüfen; Datenstandort und anwendbarer Rechtsraum sind nicht dasselbe.

Technologie-Unabhängigkeit und Vendor-Lock-in

Prüfen Sie, ob der Anbieter Ihre bestehende Plattform unterstützt, Daten in gebräuchlichen Formaten exportiert und kundenspezifische Regeln dokumentiert. Ein Lock-in entsteht auch durch proprietäre Use Cases, fehlende Exportwege, nicht übertragbare Dashboards oder unklare Eigentumsrechte an Detection Content.

Eskalationsprozesse und Erreichbarkeit

Eine Kommunikations- und Eskalationsmatrix sollte Rollen, Prioritäten, Kanäle, Vertretungen und Kontakte benennen. Prüfen Sie sichere Ausweichkanäle, falls E-Mail oder Identitätssysteme betroffen sind. „24/7 erreichbar“ ist nicht gleichbedeutend mit einer rund um die Uhr besetzten Analyse- und Response-Funktion.

Referenzen und Branchenerfahrung

Referenzen sind dann aussagekräftig, wenn Scope, Betriebsmodell und regulatorischer Kontext vergleichbar sind. Fragen Sie nach Erfahrungen mit ähnlichen Datenquellen, Cloud- oder OT-Umgebungen, Servicezeiten und Eskalationsmodellen. Allgemeine Logos ohne prüfbaren Kontext sind kein belastbarer Nachweis.

Onboarding-Dauer und -Prozess

Lassen Sie sich erklären, wie Scope, Logquellen, Kommunikationsmatrix, Use Cases, technische Zugänge, Tests und Service Readiness abgenommen werden. Entscheidend ist nicht eine pauschale Dauer, sondern ein realistischer Plan mit Abhängigkeiten, Mitwirkungspflichten, Abnahmekriterien und Verantwortlichen.

Transparenz bei Reporting und Kennzahlen

Reporting sollte zeigen, welche Alarme entstanden, wie sie priorisiert und bearbeitet wurden, welche Datenquellen oder Use Cases beeinträchtigt waren und welche Verbesserungen offen sind. Kennzahlen benötigen Definition, Messpunkt, Zeitraum und Kontext. Ein Durchschnitt allein kann Ausreißer verdecken.

SLA prüfen: Worauf Sie im Vertrag achten sollten

SLA-Prüfung: Worauf Sie im Vertrag achten sollten

Ein SLA ist nur vergleichbar, wenn Messbeginn, Messende, Priorität, Statistik und Verantwortungsgrenze präzise definiert sind. Besonders bei MTTR muss das „R“ ausgeschrieben werden, weil Respond, Resolve, Repair und Recover unterschiedliche Endpunkte beschreiben können.

Prüfpunkt	Frage an den Anbieter	Warnsignal
Messbeginn	Ab wann läuft die Zeit: ab Alarm im System, ab Erkennung durch Analysten oder ab Ticketeingang?	Uhr startet erst bei manueller Ticketeröffnung durch den Anbieter
Prioritätsstufen	Welche Stufen gibt es, und welche Zeiten gelten je Stufe für Erstreaktion und Eskalation?	Nur ein Wert für alle Alarme
Definition MTTR	Steht MTTR für Recover, Respond, Resolve oder Repair, und wo endet die Messung?	Begriff nicht definiert
Statistik	Mittelwert oder Perzentil? Welcher Anteil muss den Zielwert erreichen?	Nur Durchschnitt ohne Verteilung und Ausreißer
Verfügbarkeit	Welche Funktion ist tatsächlich 24/7 besetzt, inklusive Wochenenden und Feiertagen?	„24/7“ ohne Beschreibung der besetzten Leistung
Eskalationsmatrix	Wer wird wann und über welchen Kanal informiert? Gibt es Vertretungen und Ausweichkanäle?	Keine benannten Rollen, Kontakte oder Vertretungen
SLA-Verstoß	Welche Berichte, Verbesserungspläne, Service Credits oder Kündigungsrechte gelten?	Keine vertragliche Folge oder Berichtspflicht
Vergleichbarkeit	Sind Definitionen, Ausschlüsse und Messdaten klar definiert und mit anderen Angeboten vergleichbar?	Eigene Metriknamen, eigene Definitionen, selbstentwickelte Tools, intransparente KPI, ..

Was bedeutet das „R“ in MTTR?

Im Vertrag muss die Kennzahl ausgeschrieben und der Endpunkt beschrieben werden. „Respond“ kann die eingeleitete Reaktion meinen, „Resolve“ die fachliche Lösung, „Repair“ eine technische Reparatur und „Recover“ die Wiederherstellung des Betriebs. Ohne Definition sind Angebote nicht belastbar vergleichbar.

Rote Flaggen bei Angeboten erkennen

Rote Flaggen: Woran Sie problematische Angebote erkennen

„24/7“ wird beworben, aber nicht nach Monitoring, Analyse, Eskalation, Response und Servicemanagement aufgeschlüsselt.

Zertifizierungen werden genannt, der relevante Service oder Standort liegt aber außerhalb des Scopes.

Reaktionszeiten haben keinen eindeutigen Start-, End- oder Prioritätspunkt.

Datenstandort, Unterauftragnehmer oder Remote-Zugriffe bleiben unklar.

Incident Response wird versprochen, ist im Vertrag jedoch ausgeschlossen oder nur gegen separate Beauftragung verfügbar.

Reporting enthält Mengen, aber keine Aussage zu Datenqualität, Coverage, SLA-Erfüllung oder Verbesserungen.

Es fehlen Export-, Lösch-, Exit-, Onboarding- und Transition-Regelungen.

Referenzen bleiben ohne vergleichbaren Scope oder dürfen nicht verifiziert werden.

Checkliste für den Anbietervergleich

Checkliste: SOC-Anbieter im Vergleich bewerten

Prüffeld	Erfüllt, wenn ...	Bewertung
Leistungsumfang	Monitoring, Triage, Analyse, Eskalation und Response klar getrennt beschrieben	☐ Ja ☐ Teilweise ☐ Nein
SLA	Prioritäten, Messpunkte, Statistik, Ausschlüsse und Folgen definiert	☐ Ja ☐ Teilweise ☐ Nein
Betriebszeit	Besetzte Funktionen für Werktage, Nacht, Wochenende und Feiertage dokumentiert	☐ Ja ☐ Teilweise ☐ Nein
Zertifizierung	ISO/IEC-27001-Zertifikat, Gültigkeit und Scope geprüft	☐ Ja ☐ Teilweise ☐ Nein
Datenverarbeitung	Standorte, Rechtsräume, Unterauftragnehmer und Remote-Zugriffe geklärt	☐ Ja ☐ Teilweise ☐ Nein
Datenschutz	Rollen, Auftragsverarbeitung, Löschung und Weisungen geprüft	☐ Ja ☐ Teilweise ☐ Nein
Technologie	Plattformen, Integrationen, Exportformate und Eigentum an Regeln geklärt	☐ Ja ☐ Teilweise ☐ Nein
Eskalation	Kommunikationsmatrix, Vertretungen und Out-of-band-Kanäle vorgesehen	☐ Ja ☐ Teilweise ☐ Nein
Referenzen	Vergleichbare Kunden- oder Projektsituationen nachvollziehbar	☐ Ja ☐ Teilweise ☐ Nein
Onboarding	Plan, Mitwirkungspflichten, Tests und Abnahme definiert	☐ Ja ☐ Teilweise ☐ Nein
Reporting	Kennzahlen, Datenqualität, Coverage und Verbesserungsmaßnahmen enthalten	☐ Ja ☐ Teilweise ☐ Nein
Response	Befugnisse, Freigaben, Playbooks und ausgeschlossene Systeme definiert	☐ Ja ☐ Teilweise ☐ Nein
Exit	Datenexport, Löschung, Wissenstransfer und Migrationsunterstützung geregelt	☐ Ja ☐ Teilweise ☐ Nein
Kommerzielles Modell	Grund-, variable und Zusatzleistungen transparent abgegrenzt	☐ Ja ☐ Teilweise ☐ Nein

Die Checkliste sollte mit gewichteten Muss- und Soll-Kriterien ergänzt werden. Ein Anbieter darf nicht durch eine hohe Gesamtpunktzahl gewinnen, wenn ein zwingendes Sicherheits-, Datenschutz- oder SLA-Kriterium nicht erfüllt ist und somit ein KO-Kriterium ist. Am Ende entscheidet jedoch auch viel das Gefühl während der gemeinsamen Evaluierung, nicht nur die reine Datenlage.

Anbieter in Deutschland: Worauf achten?

SOC-Anbieter in Deutschland: Worauf besonders achten?

Ein deutscher Standort kann Kommunikation, Vertragsgestaltung und regulatorische Abstimmung erleichtern, ist aber allein kein Qualitätsnachweis. Prüfen Sie Datenverarbeitung, Rechtsraum, Unterauftragnehmer, Analystenzugriffe und Zertifizierungsscope konkret. Für Auftragsverarbeitung stellt die EU-Kommission Standardvertragsklauseln nach Artikel 28 Absatz 7 DSGVO bereit; ob und welche Regelung benötigt wird, muss der konkrete Verarbeitungsvorgang zeigen.

Das BSI nutzt für bestimmte Sicherheitsdienstleistungen wettbewerbsneutrale Qualifizierungsverfahren mit Selbstauskunft und fachlichem Interview. Eine solche Qualifizierung ist jedoch nicht mit einer allgemeinen Zulassung als SOC-Anbieter gleichzusetzen. Ausschreibungen sollten deshalb weiterhin den konkreten Leistungsumfang prüfen.

Häufige Fragen zur Auswahl

Häufige Fragen zur Anbieterauswahl

Wie erkenne ich einen guten SOC-Anbieter?

Ein guter Anbieter beschreibt Leistung, Verantwortlichkeiten, Datenverarbeitung und SLA-Messung transparent. Er kann den Zertifizierungsscope, das Betriebsmodell, Eskalationswege, Reporting und Exit-Regelungen nachvollziehbar erklären. Entscheidend ist die Passung zu Ihrem Risiko- und Betriebsmodell, nicht eine einzelne Produkt- oder Marketingaussage.

Was ist ein gutes SOC-SLA?

Ein gutes SLA definiert pro Prioritätsstufe Messbeginn, Zielhandlung, Messende, Statistik, Ausschlüsse und Eskalation. Es benennt, welche SOC-Funktion zu welcher Zeit verfügbar ist und welche Folgen eine Abweichung hat. Ein Minutenwert ohne diese Definitionen ist nicht belastbar.

Was unterscheidet deutsche von internationalen Anbietern?

Unterschiede können bei Vertragsrecht, Sprache, Datenstandort, Analystenstandorten, Unterauftragnehmern und Plattformarchitektur liegen. Die Nationalität des Anbieters allein beantwortet diese Fragen nicht. Prüfen Sie die konkrete Leistungskette und alle Orte, an denen Daten gespeichert oder verarbeitet werden.

Wie lange dauert die Auswahl typischerweise?

Eine allgemeingültige Dauer lässt sich nicht seriös nennen. Sie hängt von Ausschreibungsumfang, Datenschutz- und Rechtsprüfung, technischen Workshops, Referenzgesprächen und Vertragsverhandlung ab. Planen Sie Entscheidung und Onboarding getrennt und definieren Sie für beide klare Abnahmepunkte.

Muss ein SOC-Anbieter ISO 27001 zertifiziert sein?

Eine ISO/IEC-27001-Zertifizierung ist ein wichtiges Prüfkriterium, aber kein automatischer Leistungsnachweis. Prüfen Sie, ob der relevante SOC-Service, die beteiligten Standorte und Prozesse vom Zertifizierungsscope erfasst sind. Zusätzlich bleiben technische, vertragliche und operative Due Diligence erforderlich.

Weiter zur Anbieterauswahl

Nächster Schritt: SOC-Anbieter auswählen

Buyer's Guide für SOC und MDR

Worauf kommt es bei der Auswahl eines SOC- oder MDR-Anbieters an? Unser Buyers Guide hilft Ihnen, Ihre Anforderungen zu schärfen, Leistungen einzuordnen und den passenden Security-Partner auszuwählen.

< Zurück zur Übersicht