SOC-Ausschreibungen: 7 Fragen, die Auftraggeber vorab klären sollten

Immer mehr öffentliche Auftraggeber und private Unternehmen schreiben ein Security Operations Center aus, und fast alle Anbieter beantworten die zentralen Anforderungen mit denselben Zusagen. Dieser Beitrag zeigt auf Basis von Erfahrungswerten aus zahlreichen SOC-, MDR- und SzA-Beschaffungen anhand sieben beispielhafter technischer Fragen, was vor der Veröffentlichung der Vergabeunterlagen geklärt sein sollte, damit vergleichbare Angebote entstehen statt nur vergleichbar klingender.

Cybervorfälle sind laut dem aktuellen Allianz Risk Barometer zum fünften Mal in Folge das größte Geschäftsrisiko weltweit, auch in Deutschland stehen sie auf Platz eins (s. Allianz Commercial: Allianz Risk Barometer 2026). Der Digitalverband Bitkom beziffert den Schaden durch Datendiebstahl, Spionage und Sabotage für die deutsche Wirtschaft auf zuletzt rund 289 Milliarden Euro pro Jahr, 87 Prozent der Unternehmen waren binnen zwölf Monaten betroffen (Bitkom e. V.: Wirtschaftsschutz 2025, Lagebild der deutschen Wirtschaft), und und das BSI sieht die Lage der IT-Sicherheit in Deutschland weiterhin „auf angespanntem Niveau“ (BSI: Die Lage der IT-Sicherheit in Deutschland 2025).

Der Gesetzgeber reagiert darauf auf breiter Front: mit dem NIS-2-Umsetzungsgesetz, das seit Dezember 2025 in Kraft ist (BSI: Pressemitteilung „Cybersicherheitsrecht: NIS-2-Umsetzungsgesetz ab morgen in Kraft“ (05.12.2025)), der Pflicht zum Einsatz von Systemen zur Angriffserkennung (SzA) für Betreiber kritischer Anlagen nach § 31 Absatz 2 BSIG, die alle drei Jahre nachzuweisen ist (§ 39 Absatz 1 BSIG; vormals § 8a Absatz 1a und Absatz 3 BSIG a. F. – BSI: Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung sowie FAQ zu § 8a Absatz 1a BSIG), dem Cyber Resilience Act für Produkte mit digitalen Elementen, dessen Meldepflichten für aktiv ausgenutzte Schwachstellen ab dem 11. September 2026 greifen, und DORA, das im Finanzsektor seit Januar 2025 anzuwenden ist. Parallel haben die Cyber-Versicherer ihre Anforderungen deutlich angehoben, nachdem die Branche Anfang der 2020er-Jahre in die Verlustzone geraten war: 2021 lag die Schaden-Kosten-Quote bei fast 124 Prozent (GDV: „Cyberversicherer machen erstmals Verluste, Markt legt weiter zu“ (Medieninformation zum Geschäftsjahr 2021)), Schäden und Kosten zusammen überstiegen die Beitragseinnahmen also deutlich. Inzwischen hat sich die Quote erholt, 2023 lag die Quote bei rund 97 Prozent, die Anforderungen an Erkennung und Reaktion sind geblieben. Wer heute eine Police abschließen will, muss meist Erkennungs- und Reaktionsfähigkeiten nachweisen, und je größer der Umsatz, desto restriktiver die Anforderungen. Die Versicherungspolice allein ist keine Antwort auf einen Angriff mehr. Entsprechend schreiben immer mehr (öffentliche) Auftraggeber ein Security Operations Center (SOC) aus: Eine Auswertung des Vergabe-Archivs zeigt allein oberhalb der EU-Schwellenwerte rund 450 deutsche Bekanntmachungen mit ausdrücklichem Bezug zu Security Operations Center, Angriffserkennung oder Managed Detection and Response seit 2021, die jährliche Zahl hat sich bis 2025 verachtfacht. Dieser Beitrag stützt sich auf Erfahrungswerte aus zahlreichen SOC-, MDR- und SzA-Beschaffungen für private Unternehmen und öffentliche Auftraggeber. So unterschiedlich diese Ausprägungen sind, eines haben alle gemeinsam: das kontinuierliche Monitoring des größten Einfallstors, nämlich der einzelnen Endpunkte (Laptop, Tower-PC und weitere). Das wiederkehrende Muster in diesen Beschaffungen: Alle Anbieter sagen zu denselben Anforderungen Ja, liefern aber sehr Unterschiedliches. Hinzu kommt, dass Anbieter zu Beginn oft sehr zurückhaltend mit belastbaren Informationen sind. Erst ein echter Wettbewerb führt dazu, dass Details wie Anzahl und Personenzertifizierungen der Analysten oder Anzahl und Namen von Referenzkunden offengelegt werden. Selbst dann lohnt das Nachfassen: Benannte Referenzkunden erweisen sich beim tatsächlichen Kontaktieren gelegentlich als Altkunden, die den Service längst nicht mehr beziehen. Die folgenden sieben Fragen sind erfahrungsgemäß ein wichtiger Hebel, viele weitere ließen sich ergänzen. Wer sie vorab klärt, erhält vergleichbare Angebote statt nur vergleichbar klingender.

Abbildung 1: Sieben Anbieter, dieselben Fragen, sehr unterschiedliche Antworten. Anonymisierte Erfahrungswerte aus SOC-, MDR- und SzA-Beschaffungen.

1. Von wo, in welchem Modell und in welcher Sprache wird das 24/7-Monitoring erbracht?

Kaum eine SOC-Beschaffung begnügt sich heute noch mit einem 8×5-Betrieb, gefordert wird fast immer 24/7. Vor der Betriebsfrage steht allerdings die Ausbaustufe und hier lohnt begriffliche Präzision: MDR (Managed Detection and Response) ist ein endpunktzentrierter Erkennungs- und Reaktionsdienst auf Basis einer EDR- oder XDR-Lösung. Ein vollwertiges SOC deckt darüber hinaus weitere Log-Quellen wie Netzwerk, Identitäten, Cloud und Applikationen ab, in der Regel über ein SIEM. Systeme zur Angriffserkennung (SzA) wiederum bezeichnen die regulatorische Mindestanforderung für KRITIS-Betreiber; sie verlangen nach der BSI-Orientierungshilfe eine kontinuierliche Protokollierung, Detektion und Reaktion auf Netz- und Systemebene und gehen damit über ein rein endpunktzentriertes MDR hinaus. Welche Kombination aus Service und Produkten gebraucht wird, bestimmt Leistung und Kosten maßgeblich. Dieser Beitrag konzentriert sich auf die externe Umsetzung, denn ein vollständiger Eigenbetrieb lässt sich in der Praxis selten kostengünstiger realisieren: Nacht- und Wochenendarbeit ist nach § 87 Absatz 1 Nummer 2 BetrVG mitbestimmungspflichtig und mit Betriebs- beziehungsweise Personalrat langwierig abzustimmen und finanziell lohnt der Eigenbetrieb sich höchstens für große Organisationen, wobei selbst dort häufig ein Hybrid-Ansatz gefahren wird. Genau deshalb ist die Frage „Bieten Sie 24/7?“ wertlos: Erfahrungsgemäß beantworten sie praktisch alle Anbieter mit Ja. Dahinter stehen jedoch völlig verschiedene Betriebsrealitäten. Ein Teil betreibt echte Schichtmodelle aus Deutschland, der Schweiz oder Nordeuropa. Andere arbeiten nach dem Follow-the-Sun-Prinzip: Nachts übernimmt ein Team auf einem anderen Kontinent, gearbeitet wird auf Englisch. Wieder andere haben zwar deutschsprachige Analysten, aber nur werktags zu Geschäftszeiten; nachts und am Wochenende bleibt nur eine Rufbereitschaft.

Follow-the-Sun ist dabei nicht per se die falsche Antwort. Für ein global aufgestelltes Privatunternehmen mit englischsprachigem IT-Betrieb kann es genau das richtige Modell sein: Es analysiert immer ein Analyst in seiner Tagschicht, nie eine müdere Nachtschicht. Für ein Stadtwerk als KRITIS-Betreiber sieht die Rechnung anders aus. Wenn nachts um drei ein Vorfall eskaliert, spricht der Analyst auf einem anderen Kontinent Englisch, während Krisenstab, Werkleitung und die Meldewege an das BSI auf Deutsch funktionieren sollten. Dazu kommt die Datensouveränität: Bei global verteilten Betriebsmodellen werden Analyse- und Servicedaten außerhalb der EU verarbeitet und selbst ein Anbieter mit „deutschem SOC-Standort“ kann seine Rechenzentren sonst wo  betreiben oder seine Software von außereuropäischen Herstellern beziehen; gerade der Endpoint-Security-Markt wird von großen US-Anbietern dominiert. Diese Abwägung gehört vor die Ausschreibung, nicht in die Angebotswertung: Zunächst ist zu klären, welcher Ansatz beschafft werden soll, anschließend ist in den Vergabeunterlagen zu konkretisieren, wie das 24/7-Monitoring umzusetzen ist. Vorab festzulegen und zu fordern sind konkret: alle Standorte der Leistungserbringung, das Betriebsmodell nachts und am Wochenende, die Sprache über den gesamten 24/7-Zyklus und der Ort der Datenverarbeitung.

2. Wie viele Kunden betreibt der Anbieter mit einem vergleichbaren Setup?

Referenzlisten und Gesamtkundenzahlen beeindrucken, sagen aber wenig. Die entscheidende Frage lautet: Für wie viele Kunden erbringt der Anbieter den Service mit einem vergleichbaren Setup? Konkret etwa: Wie viele Kunden überwacht er mit genau der Endpoint-Security-Lösung, die im eigenen Haus im Einsatz ist, oder mit demselben SIEM? In der Beschaffungspraxis reicht die Spannweite der Antworten auf diese Frage von 0 über 2 bis zu mehreren hundert. Der lehrreichste Fall: Ein Anbieter mit über 400 Kunden insgesamt betrieb die konkret angefragte Architektur-Kombination bei genau zwei bis drei Kunden. Aufschlussreich ist daneben der Umsatzanteil: Ein Anbieter mit 80 Millionen Euro Jahresumsatz, davon 34 Millionen aus SOC-Services, ist auf das Thema fokussiert und spezialisiert. 5 Millionen Euro SOC-Umsatz bei 14 Milliarden Gesamtumsatz sind dagegen ein Nebengeschäft.

Der Hintergrund ist ein Strukturmerkmal des Marktes: Die meisten Anbieter sind auf einen einzigen Stack fokussiert oder zwei bis drei Technologie-Stacks standardisiert, häufig die großer Plattformhersteller. Der Markt kennt dagegen, wie ein Blick in Testverfahren und Marktübersichten wie die MITRE ATT&CK Evaluations, Gartner oder Forrester zeigt, eine Vielzahl von Endpoint-Security- und SIEM-Lösungen. Die Wahrscheinlichkeit, dass die eigene Bestandslösung nicht zum Standard des Wunschanbieters gehört, ist also hoch. Auf seinen Standard-Stacks ist der Anbieter eingespielt und leistungsfähig, teilweise mit mehreren hundert identisch aufgesetzten Kunden. Wer als Auftraggeber mit einer abweichenden Bestandslösung kommt, wird zum Exoten oder muss migrieren. Der Grund ist schlicht Skalierung: Anbieter wollen standardisieren und setzen selten für einen einzelnen Kunden eine Sonderlocke um. In der Praxis geht das selten gut aus: Die Erkennungsregeln, Playbooks und Automatisierungen des Anbieters sind für seine Standard-Stacks gebaut, und, am wichtigsten, seine Analysten kennen „ihre“ Lösungen und tragen darin meist die typischen Herstellerzertifizierungen der jeweiligen Endpoint- bzw. SIEM-Lösung. Der Sonderfall läuft mit angezogener Handbremse. Deshalb gehören in die Ausschreibung zwei Nachweise: die Zahl der Kunden mit vergleichbarer Servicearchitektur und Referenzen vergleichbarer Größe mit eben diesem Setup.

3. Wie arbeiten SOC und Incident-Response-Team im Ernstfall zusammen?

Ein SOC erkennt, qualifiziert und meldet Angriffe und dämmt sie im besten Fall schnell und erfolgreich ein. Greift dieser Prozess aber nicht, etwa zu Projektbeginn mitten im Roll-out und stellt sich der Angriff als Double-Extortion-Ransomware heraus, bei der Daten verschlüsselt und zugleich zur Erpressung abgezogen werden, beginnt eine andere Disziplin: die vollumfängliche Bewältigung des Vorfalls mit forensischer Untersuchung, Wiederanlauf, Krisenmanagement, Kommunikation sowie datenschutzrechtlichen Melde- und Dokumentationspflichten. Erfahrungsgemäß inkludieren die meisten Anbieter hier nur Basisleistungen oder bieten Incident Response als separaten Retainer an, ein klassisches Upselling; häufig stehen dahinter externe Partner, und genau dort lohnt das nähere Hinschauen. Bezeichnend: In Angebotsbewertungen ist Incident Response regelmäßig die Sektion mit der größten Streuung zwischen den Anbietern.

Ein verbreiteter Irrtum kommt hinzu: Auch mit externem SOC braucht der Auftraggeber intern eine minimale Reaktionsfähigkeit mit Meldeketten bis zur Geschäftsführung beziehungsweise zum Vorstand, die qualifizierte Meldungen annimmt, bewertet und an die richtigen Stellen im Haus steuert. Bis diese Meldewege bis zum zuständigen Ansprechpartner eingespielt sind, vergehen erfahrungsgemäß mehrere Monate, und das im besten Fall. Wer das erst im Ernstfall merkt, hat ein teures SOC, dessen Nachfragen zu möglichen Angriffen ins Leere laufen, weil intern niemand erreichbar ist.

Orientierung bietet die Liste der qualifizierten APT-Response-Dienstleister des BSI. Ein Blick darauf zeigt: Viele der gelisteten Häuser sind gar keine SOC-Anbieter, sondern auf vollumfängliche Vorfallsbewältigung spezialisierte Forensik- und Beratungsunternehmen. Umgekehrt stehen nur wenige Managed-SOC-Anbieter auf der Liste. Daraus folgen zwei Modelle, die beide funktionieren können. Aus einer Hand: SOC und Incident Response beim selben Anbieter, mit kurzen Wegen und einem Vertrag; dann ist zu prüfen, wer die Forensik tatsächlich erbringt und ob dahinter Subunternehmer stehen. Oder getrennt: das SOC für Erkennung und Eindämmung, dazu ein Retainer bei einem qualifizierten APT-Response-Dienstleister für den großen Ernstfall; dann müssen Schnittstellen, Eskalationswege, Rollen und die Datenübergabe zwischen beiden vorab vertraglich geregelt sein. Welche Variante passt, hängt von Größe und Kritikalität ab. Für die Vorauswahl hat sich die BSI-Liste auch vergabepraktisch bewährt: In einem realen Teilnahmewettbewerb wurde die Listung als objektiv prüfbares Wertungskriterium bepunktet und differenzierte das Bewerberfeld deutlich. Aus der Begleitung mehrerer Bewerbungsverfahren zur Aufnahme in die BSI-Liste qualifizierter APT-Response-Dienstleister ergeben sich zudem praktische Einblicke, die zeigen, dass die Liste auch Schwächen hat: Die Aufnahme ist freiwillig, geeignete IR-Dienstleister können also fehlen und die Listung sagt nur etwas über die APT-Vorfallsbewältigung aus, nichts über Monitoring- oder SOC-Fähigkeiten. Vor allem aber ist sie eine Qualifizierung, keine Zertifizierung, also eine einmalige Prüfung der Fähigkeiten: Wer vor vier Jahren gelistet wurde, hat die damals geprüften Fähigkeiten und das damalige Personal heute womöglich nicht mehr an Bord. Nachfragen lohnen sich deshalb auch hier: nach Personenzertifizierungen etwa von GIAC, nach Erfahrungswerten in Krisen- und Datenschutzthemen, nach der Reaktion auf Data Leaks sowie nach Umsätzen und Referenzkunden.

4. Welche Use Cases und Log-Quellen soll das SOC abdecken und auf welchem Mengengerüst?

Ein SOC erkennt nur, was es sieht. Vor der Ausschreibung gehört ein Mengengerüst erstellt: Endpunkte, Server, Netzwerkkomponenten, Cloud-Dienste, erwartete Log-Volumina. Das ist auch kommerziell entscheidend, denn die Preistreiber der Anbieter sind verschieden: Manche kalkulieren nach Nutzerzahl, andere nach Endpunkten oder nach Log-Volumen pro Tag. In der Beschaffungspraxis liegen die Jahreskosten bei identischem Mengengerüst nicht selten um 75 Prozent auseinander; in einem realen Vergabeverfahren trennte die Gesamtangebotspreise für dieselbe Leistungsbeschreibung sogar mehr als Faktor zwei, während die Qualitätswertungen der Bieter eng beieinanderlagen. Teils sind zudem beizustellende Herstellerlizenzen nicht im Preis enthalten. Für die Schätzung des SIEM-Log-Volumens, das meist Preistreiber Nummer eins ist, stehen öffentlich zugängliche Rechner verschiedener Hersteller zur Verfügung, etwa der SIEM-Storage-Rechner von ManageEngine, der EPS-Kalkulator von TeskaLabs oder für cloudbasierte SIEM-Dienste der Azure-Preisrechner. Bewährt hat sich, aus mehreren dieser Rechner einen Mittelwert zu bilden und ihn als kalkulatorisches Minimum in der Ausschreibung vorzugeben: So kalkulieren alle Bieter auf derselben realistischen Basis, statt sich mit optimistischen Annahmen den Zuschlag zu sichern und später nachzufordern. Ergänzend gehört eine Klausel in den Vertrag, dass ein wachsendes Log-Volumen die Lizenzkosten höchstens linear erhöht. Die weitergehende Optimierung der Log-Kosten ist ein eigenes Thema: Viele Anbieter bieten inzwischen Data-Lake-Modelle an, in denen selten benötigte Logs deutlich günstiger vorgehalten werden. Und eine wiederkehrende Beobachtung aus Bestandsaufnahmen: Logs werden vielerorts gesammelt, aber nur anlassbezogen ausgewertet. Eine zentrale Log-Sammlung allein ist noch keine Angriffserkennung.

5. Wie werden Reaktionszeiten definiert, gemessen und berichtet?

Bei Reaktionszeiten kommt es auf den Messpunkt an: Bezieht sich „unter einer Stunde“ auf die Qualifizierung des Alarms, die Meldung an den Auftraggeber oder die Eindämmung? Ohne definierten Messpunkt ist ein SLA im Streitfall wertlos. Entscheidend ist, dass der Auftraggeber diese Definitionen in der Ausschreibung vorgibt und nicht den Bietern überlässt; sonst werden in der Angebotsauswertung Äpfel mit Birnen verglichen. Reale Leistungsbeschreibungen machen es vor: Dort wird die Reaktionszeit exakt definiert als Zeit vom Zeitstempel der Alarm-Generierung bis zur aktiven Übernahme durch einen Analysten, mit verbindlichen Werten je Alarmkategorie, beispielsweise 15 Minuten bei hoher Kritikalität. Nach demselben Muster lassen sich weitere Kennzahlen entlang der Bearbeitungskette festlegen, etwa die mittlere Erkennungszeit oder die Genauigkeit der Erstbewertung. Dazu gehört ein regelmäßiges Berichtswesen mit nachvollziehbaren Kennzahlen, etwa der Abdeckung der Erkennungsregeln gegen gängige Angriffstechniken und dem Anteil der vom SOC statt von Nutzern entdeckten Vorfälle, damit die Leistung über die Vertragslaufzeit messbar bleibt.

6. Soll der Dienstleister nur melden oder auch eingreifen?

Auch hier zeigt die Beschaffungspraxis das volle Spektrum: Ein Anbieter spricht grundsätzlich nur Handlungsempfehlungen aus, ein anderer isoliert Endpunkte ausschließlich manuell nach menschlicher Validierung, wieder andere automatisieren Gegenmaßnahmen nach einer vorab unterzeichneten Freigabe. Teils sind delegierbare Maßnahmen wie Firewall-Sperrungen kostenpflichtige Zusatzmodule. Wer darf wann was, auch nachts um drei? Das muss vor der Ausschreibung entschieden und spätestens nach Zuschlag mit dem Auftragnehmer schriftlich in Freigabeprozessen hinterlegt sein.

7. Wie sehen Onboarding und Exit aus?

Ein SOC ist am ersten Vertragstag nicht wirksam: Anbindung der Log-Quellen, Use-Case-Rollout und Einschwingphase dauern erfahrungsgemäß mehrere Monate und gehören mit Meilensteinen in die Leistungsbeschreibung. Am anderen Ende ist der Exit zu regeln, und dort vor allem die Eigentumsfrage: Bleiben die SIEM-Erkennungsregeln und Use Cases beim Anbieterwechsel geistiges Eigentum des Anbieters, oder gehören sie dem Auftraggeber? Marktüblich sind drei Jahre Laufzeit, meist mit Verlängerungsoptionen von einem plus einem weiteren Jahr, seltener auch drei plus zwei plus zwei; Ausstiegsklauseln und Offboarding-Kosten sollten explizit abgefragt werden.

Fazit

Keine dieser sieben Fragen erfordert vergaberechtliches Spezialwissen, wohl aber technische Vorarbeit vor der Ausschreibung. Entscheidend ist dabei die Zusammenarbeit und das gemeinsame Verständnis zwischen den IT- und den Vergabeexperten im eigenen Haus; teils lohnt sich ein Vermittler, der beide Sprachen spricht. Die Erfahrung aus zahlreichen SOC-Beschaffungen bringt es auf einen Satz: Alle Anbieter sagen 24/7, kaum einer meint dasselbe. Wer Betriebsmodell, Setup-Erfahrung, Response-Befugnisse und die Schnittstelle zur Incident Response vorab klärt, erhält vergleichbare Angebote, realistische Preise und einen Dienst, der im Ernstfall das leistet, was die Leistungsbeschreibung verspricht. Werden diese und weitere Fragen vor der Beschaffung beantwortet und in die Vergabeunterlagen gegossen, ist der Grundstein für eine erfolgreiche Beschaffung gelegt. Bewährt hat sich zudem ein vorgeschalteter Teilnahmewettbewerb: Erfahrungsgemäß bewerben sich dort mehr als 15 Anbieter, aus denen sich über Referenzen und objektiv prüfbare Kriterien ein starkes Bieterfeld für die Angebotsphase auswählen lässt. Wer diese Fragen dagegen offenlässt, überlässt die Antworten den Bietern und merkt es oft erst beim ersten echten Sicherheitsvorfall.