ISO 27001 und SOC: Wo das ISMS aufhört und der Betrieb anfängt
ISO 27001 verlangt ein Managementsystem für Informationssicherheit mit dokumentierten Prozessen, Risiken und Kontrollen. Ein SOC ersetzt kein ISMS. Es ist aber die operative Grundlage, mit der die Controls A.5.24 bis A.5.30 (Incident Management, Continuity, Bereitschaft) und A.8.15 bis A.8.16 (Logging, Monitoring) tatsächlich gelebt werden. Ohne 24/7-Detection sind mehrere Annex-A-Controls formal erfüllt, aber operativ nicht wirksam.
Abgrenzung zu Nachbarthemen
Diese Seite betrachtet ISO 27001 aus der Betriebs-Perspektive: welche Controls ein SOC operativ trägt und welche Nachweise ein Auditor sehen will. Für die Schweizer Meldepflicht siehe SOC & ISG 24h-Meldepflicht. Für EU-Regulierung siehe NIS2 Schweizer Töchter und DORA-Anforderungen an das SOC. Für Datenschutz siehe revDSG und SOC.
ISMS und SOC sind nicht dasselbe
Ein ISMS nach ISO 27001 ist ein Managementsystem. Es dokumentiert Kontext, Risiken, Rollen, Prozesse und Kontrollen und weist deren Wirksamkeit nach. Ein SOC ist ein operativer Dienst: Menschen und Werkzeuge, die Alarme rund um die Uhr triagieren, eskalieren und beantworten. Das ISMS beschreibt, was passieren soll, wenn ein Vorfall eintritt. Das SOC sorgt dafür, dass der Vorfall überhaupt entdeckt wird und dass Reaktionen zeitgerecht ablaufen.
Ein ISO-27001-Zertifikat bestätigt, dass das Managementsystem den Anforderungen entspricht. Es sagt nichts darüber aus, wie schnell ein Sicherheitsvorfall entdeckt oder eingedämmt wird. Diese Wirksamkeit muss operativ geliefert und über Metriken belegt werden. Genau dort liegt die Rolle des SOC.
Annex-A-Controls, die ein SOC operativ trägt
| Control (ISO/IEC 27001:2022 Annex A) | Was der Standard verlangt | Was das SOC liefert |
|---|---|---|
| A.5.24 Incident-Management-Planung und -Vorbereitung | Dokumentierte Prozesse, Rollen, Eskalationswege. | Playbooks pro Alarmtyp, Eskalationsmatrix mit benannten Rollen, dokumentierte Übergaben. |
| A.5.25 Beurteilung und Entscheidung zu Sicherheitsereignissen | Kriterien, wann ein Ereignis ein Incident ist. | Triage-Schwellen im SIEM, dokumentierte Entscheidungslogik, Ticket-Trail mit Zeitstempeln. |
| A.5.26 Reaktion auf Sicherheitsvorfälle | Reaktion gemäss dokumentiertem Verfahren. | 24/7-Response-Team, Containment-Aktionen im EDR/Identity, dokumentierte Response-Aktionen pro Fall. |
| A.5.27 Lernen aus Sicherheitsvorfällen | Erkenntnisse fliessen in Kontrollen und Regeln. | Post-Incident-Reviews, Detection-Regeländerungen, Awareness-Themen aus realen Fällen. |
| A.5.28 Beweissicherung | Beweise nachvollziehbar sichern. | Immutable Logs im SIEM, forensische Artefakte aus dem EDR, Chain-of-Custody-Dokumentation. |
| A.5.29/A.5.30 Informationssicherheit im Business Continuity und IKT-Bereitschaft | Kontinuität und Wiederanlauf abgesichert. | Detection-Coverage für Recovery-Wege, Tabletop-Beteiligung, Abstimmung mit BCM-Playbooks. |
| A.8.15 Logging | Aktivitäten werden protokolliert und geschützt. | Zentrale Log-Ingestion mit priorisierten Quellen, Integritätsschutz, definierte Retention. |
| A.8.16 Überwachungstätigkeiten | Anomalien werden erkannt und behandelt. | Detection-Content pro Business-Kontext, 24/7-Alerting, dokumentierte False-Positive-Reduktion. |
Die Controls A.8.15 und A.8.16 sind auf dem Papier abgedeckt, aber es gibt keine 24/7-Auswertung. Ergebnis: Nichtkonformität, weil das Monitoring formal existiert, aber praktisch nicht stattfindet. Ein Managed SOC schliesst diese Lücke ohne interne Schichtplanung.
Klausel 9 und 10: Messung und Verbesserung
ISO 27001:2022 verlangt in Klausel 9 die Überwachung, Messung, Analyse und Bewertung und in Klausel 10 die kontinuierliche Verbesserung. Auditoren fragen nicht mehr nur nach Policies, sondern nach messbarer Wirksamkeit. Ein SOC liefert die dazu benötigten Kennzahlen und die Evidenz, dass daraus tatsächlich Verbesserungen entstehen.
- MTTD und MTTR, gemessen pro Alarmklasse, mit Zielkorridoren und Trendbetrachtung.
- Anzahl bestätigter Vorfälle pro Quartal, mit Kategorien und daraus abgeleiteten Regeländerungen.
- False-Positive-Rate pro Detection-Regel als Steuergrösse für die Detection-Engineering-Roadmap.
- Coverage-Karten (Assets, Log-Quellen, MITRE ATT&CK) mit dokumentierten Lücken und Schliessungsplan.
- Tabletop- und Übungsprotokolle mit gemessener Verbesserung von Rollenklarheit und Reaktionszeit.
Audit-Vorbereitung: was Auditoren konkret sehen wollen
- Statement of Applicability mit klarer Zuordnung SOC-getragener Controls zu Playbooks und Toolkette.
- Nachweis, dass Logs vollständig, integer und ausreichend lange gespeichert werden.
- Beispielhafte Ticket-Verläufe von der Detection bis zum Post-Incident-Review, inklusive Zeitstempel.
- Protokoll einer Tabletop-Übung mit Geschäftsleitung, mit dokumentierten Verbesserungen.
- Metriken-Dashboard für die letzte Managementbewertung, aus dem klar hervorgeht, was gemessen und verbessert wurde.
- Lieferantenlage: Vertrag, DPA und Auditrechte für den Managed-SOC-Provider mit klarer Rollen- und Datenzuordnung.
Zur Frage, wann ein internes SOC realistisch wird, siehe Managed SOC vs. In-house. Zur wirtschaftlichen Grössenordnung siehe SOC-Kosten Schweiz. Für den 24/7-Betrieb siehe SOC 24/7 Betrieb.
Einordnung im SOC-Betrieb
Wie der ISO-27001-taugliche SOC-Betrieb im Alltag aussieht, steht auf SOC as a Service Schweiz.
Rechtsgrundlagen und Quellen
- ISO/IEC 27001, offizielles Gremium ISO/IEC JTC 1/SC 27: committee.iso.org
Häufige Fragen
Ersetzt ein SOC ein ISMS?
Nein. Ein ISMS ist ein Managementsystem mit Politiken, Risiken und Kontrollen. Das SOC ist der operative Dienst, mit dem mehrere Annex-A-Controls tatsächlich gelebt werden. Beides ergänzt sich; keines ersetzt das andere.
Welche Annex-A-Controls betreffen das SOC am direktesten?
A.5.24 bis A.5.30 (Incident Management, Continuity, Bereitschaft, Lernen, Beweismittel) sowie A.8.15 (Logging) und A.8.16 (Monitoring). Ein SOC ohne Bezug zu diesen Controls liefert keine auditfähigen Nachweise.
Muss unser Managed-SOC-Anbieter selbst ISO-27001-zertifiziert sein?
Es ist nicht formal vorgeschrieben, aber praktisch erwartet. Ein zertifizierter Anbieter erleichtert den Nachweis zur Lieferantensteuerung (Annex A.5.19 bis A.5.23) erheblich und verkürzt die Audit-Diskussion.
Wie hängt ISO 27001 mit revDSG und ISG zusammen?
Die ISO-27001-Kontrollen liefern grosse Teile der technisch-organisatorischen Massnahmen, die revDSG (Art. 8) und ISG-nahe Anforderungen ohnehin verlangen. Meldeprozesse und Meldeschwellen sind aber zusätzlich pro Regime zu regeln, weil Empfänger und Fristen unterschiedlich sind.
Reicht Alerting-only aus für ISO-27001-Zwecke?
Nur in engen Ausnahmen. A.5.26 verlangt Reaktion gemäss Verfahren, A.5.28 verlangt Beweissicherung. Ohne Response- und Forensik-Kette ist die Wirksamkeit dieser Controls schwer zu belegen. Ein Managed SOC mit Response ist der pragmatische Weg.
Verwandte Begriffe
- ISO 27001 ISO 27001 ist die internationale Norm für Informationssicherheits-Managementsysteme. Eine Zertifizierung bestätigt, dass Risiken systematisch gesteuert werden.
- SOC 2 SOC 2 ist ein US-Prüfstandard, der die Sicherheitskontrollen von Dienstleistern anhand der Trust Services Criteria bewertet.
- SOCaaS SOC as a Service (SOCaaS) ist ein SOC, das ein externer Anbieter betreibt und als laufende Dienstleistung liefert.
- Incident Response Incident Response ist das geordnete Vorgehen, um einen Sicherheitsvorfall einzudämmen, zu bereinigen und den Betrieb wiederherzustellen.
- Vulnerability Management Vulnerability Management ist der laufende Prozess, Schwachstellen zu finden, nach Risiko zu bewerten und ihre Behebung zu prüfen.