


Ein Security Operations Center (SOC) ist die zentrale Einheit für die kontinuierliche Überwachung, Erkennung und Reaktion auf Sicherheitsvorfälle. Ob als externer SOC-as-a-Service oder als internes SOC-Aufbauprojekt: die Ausschreibung erfordert ein präzises Leistungsverzeichnis mit klaren Anforderungen.
Unser Muster-LV für SOC ist unser umfangreichstes Produkt. Es deckt alle relevanten Aspekte ab: von Service-Levels über Monitoring-Umfang und Incident-Response-Prozesse bis hin zu Onboarding, Reporting und Vertragsbedingungen.
Die Beauftragung eines Security Operations Center, ob als interner Aufbau oder als Managed SOC-Service, gehört zu den komplexesten IT-Beschaffungsvorhaben im öffentlichen Sektor. Wir haben dieses Leistungsverzeichnis entwickelt, weil wir in der Praxis beobachten, dass viele Behörden die SLA-Anforderungen zu unspezifisch formulieren und damit im späteren Betrieb keine Handhabe gegenüber dem Dienstleister haben. Abschnitt A definiert daher differenzierte Betriebszeiten: 8×5 für kommunale Verwaltungen, 12×5 für Behörden mit erhöhtem Schutzbedarf und 24×7 für KRITIS-Betreiber, die eine kontinuierliche Sicherheitsüberwachung rechtlich schulden.
Reaktionszeiten nach Schweregrad sind dabei verbindlich festzulegen, nicht optional. Anbieter wie T-Systems, Telekom Security und secunet bieten im deutschen Markt BSI-zertifizierte SOC-Dienstleistungen an, während internationale Anbieter wie DXC Technology und Atos/Eviden vor allem für bundesweite und EU-weite Ausschreibungen mit komplexen Anforderungen relevant sind. Wartungsfenster und Eskalationspfade müssen vertraglich so definiert sein, dass der Auftraggeber im Ernstfall die Kontrolle behält.
Der Monitoring-Scope ist eine der häufigsten Streitursachen in SOC-Verträgen: Was genau wird überwacht, welche Assets sind eingeschlossen, und wer ist für die Nacherfassung neuer Systeme verantwortlich? Unser Leistungsverzeichnis adressiert diese Fragen durch klare Anforderungen an die Asset-Inventarisierung als Grundlage für den Monitoring-Scope. Log-Ingestion und SIEM-Anforderungen werden dabei als eigenständiger Punkt definiert, weil die Qualität der Sicherheitsüberwachung direkt von der Vollständigkeit und Aktualität der Log-Quellen abhängt.
Use Cases und Detection Rules sind der eigentliche Mehrwert eines professionellen SOC gegenüber einer reinen SIEM-Implementierung. Wir haben diesen Punkt bewusst in das Leistungsverzeichnis aufgenommen, weil Auftraggeber ein Recht darauf haben zu wissen, welche Angriffsmuster der Anbieter erkennen kann. Axians und arvato Systems etwa bieten hier umfangreiche, branchen-spezifische Use-Case-Bibliotheken für den öffentlichen Sektor.
Incident Response im Rahmen eines SOC-Vertrages ist in Deutschland noch immer ein schwach reguliertes Feld, in dem Vertragsklarheit entscheidend ist. Wir haben Abschnitt C deshalb mit präzisen Anforderungen an Incident-Klassifizierungsschemas, Eskalationsprozesse und Kommunikationspflichten ausgestattet. Die NIS2-Richtlinie hat hier klare Fristen gesetzt: Betroffene Einrichtungen müssen binnen 24 Stunden eine Frühwarnung ausgeben, binnen 72 Stunden eine Meldung erstatten und innerhalb von 30 Tagen einen Abschlussbericht vorlegen[1]. Diese dreistufige Meldepflicht haben wir als verbindliche Anforderung in Abschnitt C verankert, damit der SOC-Dienstleister die Behörde bei der Einhaltung dieser Fristen aktiv unterstützt.
Forensische Unterstützung und Root Cause Analysis sind Leistungen, die in vielen SOC-Verträgen nur pauschal erwähnt werden, ohne operative Tiefe zu definieren. Unser Muster-LV fordert hier einen verbindlichen Prozess, der vom initialen Triage über die forensische Datenerfassung bis zum Post-Incident-Report reicht. Wer reale Vergabeunterlagen zu SOC-Beschaffungen im öffentlichen Sektor einsehen möchte, findet entsprechende Referenzdokumente im Vergabe-Archiv.
Die Onboarding-Phase ist erfahrungsgemäß der kritischste Abschnitt eines SOC-Projekts: Verzögerungen beim Asset-Onboarding, unklare Verantwortlichkeiten beim Knowledge Transfer und fehlende Meilenstein-Definitionen führen dazu, dass Behörden oft Monate zahlen, bevor der operative Schutz vollständig greift. Wir haben diesen Abschnitt deshalb mit einem strukturierten Asset-Onboarding-Prozess, klaren Transition-Meilensteinen und expliziten Schulungsanforderungen ausgestattet.
Exit-Kriterien und Offboarding-Anforderungen sind ein oft vernachlässigter Vertragsbestandteil, der aber spätestens beim Providerwechsel erhebliche Bedeutung bekommt. Unser Leistungsverzeichnis verankert diese Anforderungen explizit, weil Behörden im öffentlichen Vergaberecht an Wettbewerbsregeln gebunden sind und ein funktionsfähiger Anbieterwechsel keine Ausnahme, sondern eine planbare Notwendigkeit sein muss.
Transparenz ist im SOC-Betrieb kein Nice-to-have, sondern eine Voraussetzung für wirksame Governance. Unser Leistungsverzeichnis fordert monatliche operative Berichte sowie quartalsweise Management-Reports, die beide unterschiedliche Zielgruppen ansprechen: IT-Sicherheitsverantwortliche benötigen operative Kennzahlen, während die Behördenleitung einen strategischen Überblick über die Sicherheitslage erwartet. KPIs und regelmäßige Service-Review-Meetings schaffen die Grundlage für eine kontinuierliche Qualitätssicherung im Vertragsverhältnis.
Audits und Zertifizierungsnachweise haben wir als verbindliche Anforderung aufgenommen, weil Behörden die Sicherheitsleistung ihres SOC-Dienstleisters gegenüber Aufsichtsbehörden nachweisen müssen. ISO 27001, SOC 2 Type II und BSI-Zertifizierungen nach IT-Grundschutz sind hier die relevanten Nachweise. Datenschutz und Datenhaltung im Kontext des SOC-Betriebs sind dabei eigenständige Compliance-Felder, die in unserem Leistungsverzeichnis explizit geregelt werden.
Quellen
| Format | Microsoft Excel (.xlsx) + PDF |
| Umfang | mehr als 60 Leistungspositionen |
| Sprache | Deutsch |
| Vergaberecht | GWB, VgV, UVgO konform |
| Normen | BSI, NIS2, ISO 27001, SOC 2 |
| Stand | 2026 (regelmäßige Revision) |
| Lieferung | Lieferung in 5 Werktagen |
Sie haben Fragen?