Monitoring: Überwachung als Kontrolle für Betrieb, Sicherheit und Nachweise

Monitoring bezeichnet die systematische und fortlaufende Überwachung von IT-Komponenten, Anwendungen und Services, bei der Messwerte und Ereignisse erfasst, gegen definierte Sollwerte geprüft und Abweichungen an festgelegte Stellen gemeldet werden. Aus Governance-Sicht ist Monitoring damit eine Kontrolle: Es belegt, dass kritische Systeme wie vorgesehen funktionieren, und sorgt dafür, dass Störungen und Angriffe zeitnah erkannt werden.

In der Schweiz ist das nicht nur eine Frage guter Praxis. Die Datenschutzverordnung verlangt Massnahmen, mit denen Verletzungen der Datensicherheit rasch erkannt werden. Banken müssen nach FINMA-Rundschreiben 2023/1 die inventarisierten IKT-Bestandteile und kritischen Daten systematisch und durchgängig überwachen. Und Betreiber kritischer Infrastrukturen müssen bestimmte Cyberangriffe seit dem 1. April 2025 innert 24 Stunden dem BACS melden.

Das Wichtigste in Kürze

• Zweck: Verfügbarkeit sichern, Sicherheitsvorfälle erkennen und die Wirksamkeit des Betriebs belegen.
• Abdeckung: Massgeblich ist, ob alle kritischen Services und die IKT-Bestandteile, auf denen sie beruhen, überwacht werden. Das setzt ein aktuelles Inventar voraus.
• Nachvollziehbarkeit: Jede relevante Meldung führt zu einem dokumentierten Vorgang mit Zuständigkeit, Zeitstempeln und Entscheid, bis hin zur Frage, ob eine Meldepflicht besteht.
• Schutz: Monitoring-Systeme und Logs sind selbst schützenswert. Sie brauchen Zugriffskontrolle, definierte Aufbewahrung und eine geklärte Datenhaltung.

Stand: November 2026 · Fachlich abgeglichen mit ITIL^® 4 (PeopleCert), DSG und Datenschutzverordnung (Fedlex), FINMA-Rundschreiben 2023/1 und den Informationen des BACS (Quellen am Ende des Artikels)

Abdeckung: Monitoring vom Service her planen

Ein Monitoring, das viele Messwerte liefert, kann trotzdem Lücken haben. Entscheidend ist nicht die Zahl der Sensoren, sondern ob jeder kritische Geschäftsprozess über die Komponenten, auf denen er beruht, abgedeckt ist. Die Planung verläuft deshalb von oben nach unten:

1. Kritische Funktionen und Services bestimmen. Welche Prozesse dürfen wie lange ausfallen? Banken müssen diese Unterbrechungstoleranzen nach FINMA-RS 2023/1 ohnehin festlegen.
2. Abhängigkeiten aus dem Inventar ableiten. Anwendungen, Datenbanken, Server, Netzwerkstrecken, Cloud-Dienste und externe Dienstleister, auf denen ein Service beruht. Eine CMDB liefert diese Sicht, sofern sie gepflegt wird.
3. Messpunkte je Ebene festlegen. Verfügbarkeit und Antwortzeit aus Sicht der Nutzer (Black-Box), interne Messwerte der Komponenten (White-Box) und sicherheitsrelevante Ereignisse.
4. Sollwerte und Verantwortliche definieren. Für jeden Messpunkt: Schwellenwert, Empfänger, Reaktionsfrist und Eskalation.
5. Abdeckung regelmässig prüfen. Geht ein neues System ohne Monitoring in Betrieb, entsteht eine Lücke, die niemand bemerkt. Ein Abgleich zwischen Inventar und überwachten Komponenten macht sie sichtbar.

Welche Signale es gibt

Metriken zeigen Zustände als Zahlenreihen, etwa Auslastung oder Fehlerrate. Logs halten einzelne Ereignisse mit Zeitstempel fest, zum Beispiel Anmeldungen oder Konfigurationsänderungen. Traces verfolgen eine Anfrage über mehrere Dienste hinweg.

Für Governance-Zwecke sind Logs besonders wichtig, weil sie im Nachhinein belegen, wer wann was getan hat. Das setzt eine einheitliche Zeitbasis auf allen Systemen voraus. Ohne synchronisierte Uhren lassen sich Ereignisse aus verschiedenen Quellen nicht verlässlich zu einem Ablauf zusammensetzen.

Betriebsmonitoring und Sicherheitsmonitoring: zwei Kontrollen, ein Prozess

In vielen Organisationen gibt es zwei Arten der Überwachung mit eigenen Teams und Werkzeugen. Das Betriebsmonitoring sichert Verfügbarkeit und Leistung. Das Sicherheitsmonitoring, häufig mit einem SIEM und einem Security Operations Center (SOC), soll Angriffe erkennen. Beide brauchen eine klare Abgrenzung und eine gemeinsame Schnittstelle.

Die Trennung ist sinnvoll, die Bruchstelle dazwischen ist ein Risiko. Ein Ausfall kann die Folge eines Angriffs sein, etwa bei einem Verschlüsselungstrojaner, und eine scheinbar harmlose Auffälligkeit im Betrieb kann der erste Hinweis darauf sein. Deshalb sollten beide Seiten Vorfälle im selben Incident-Prozess erfassen, mit einem dokumentierten Übergabepunkt zwischen Betrieb und Security.

ITIL^® 4 behandelt Monitoring und Event Management als eigene Practice und stuft Events als Information, Warnung oder Ausnahme ein. Diese Einstufung lässt sich für beide Arten der Überwachung verwenden und schafft eine gemeinsame Sprache für die Übergabe.

Regulatorische Anforderungen und wie Nachweise entstehen

Welche Vorgaben gelten, hängt von Branche und Datenart ab. Für das Monitoring in der Schweiz sind vor allem drei Rechtsgrundlagen relevant:

• DSG und Datenschutzverordnung: Art. 8 DSG verlangt eine dem Risiko angemessene Datensicherheit. Art. 3 DSV nennt dazu unter anderem Massnahmen, mit denen Fehlfunktionen gemeldet und Verletzungen der Datensicherheit rasch erkannt werden. Werden besonders schützenswerte Personendaten in grossem Umfang automatisiert bearbeitet oder wird ein Profiling mit hohem Risiko durchgeführt und genügen präventive Massnahmen nicht, verlangt Art. 4 DSV eine Protokollierung. Die Protokolle sind mindestens ein Jahr getrennt vom bearbeitenden System aufzubewahren.
• FINMA-Rundschreiben 2023/1 (Banken): Im Management der Cyber-Risiken fordert die FINMA die zeitnahe Aufzeichnung und Erkennung von Cyber-Attacken auf Basis eines Prozesses zur systematischen und durchgängigen Überwachung der inventarisierten IKT-Bestandteile und der elektronischen kritischen Daten. Für meldepflichtige Cyber-Attacken nennt das Rundschreiben eine Vororientierung der FINMA innert 24 Stunden und die Meldung über die Erhebungsplattform innert 72 Stunden.
• Informationssicherheitsgesetz (ISG): Betreiber kritischer Infrastrukturen müssen Cyberangriffe seit dem 1. April 2025 innert 24 Stunden nach der Entdeckung dem BACS melden, unter anderem wenn ein Angriff die Funktionsfähigkeit der Infrastruktur gefährdet, zu einer Manipulation oder einem Abfluss von Informationen geführt hat oder mit Erpressung verbunden ist. Fehlende Angaben können innert 14 Tagen nachgereicht werden.

Wie aus einem Alarm ein Nachweis wird

Die Frist für die Meldung an das BACS beginnt mit der Entdeckung. Für Revision und Aufsicht zählt deshalb, dass sich der Weg vom ersten Event bis zum Entscheid lückenlos belegen lässt:

1. Das Event wird mit Zeitstempel und Quelle als Incident erfasst, automatisch über eine Schnittstelle oder durch das Security-Team.
2. Die Erstbeurteilung hält fest, welche Services und Daten betroffen sind und ob ein Sicherheitsbezug besteht.
3. Der Entscheid über die Meldepflicht wird mit Begründung, verantwortlicher Person und Zeitpunkt dokumentiert.
4. Massnahmen, Kommunikation und Wiederanlauf werden im selben Vorgang nachgeführt.
5. Ursachenanalyse und daraus abgeleitete Changes werden mit dem Vorfall verknüpft und bis zum Abschluss verfolgt.

ky2help^® historisiert Vorgänge automatisch, bietet ein integriertes Daten-Audit und ist auf revisionssichere Dokumentation ausgelegt. Wie Monitoring-Events per Schnittstelle zu Tickets werden, zeigt das Referenzprojekt der CCT Software Solutions GmbH: Eine REST-API fragt die Events der Monitoring-Software laufend ab und eröffnet bei erkannten Problemen automatisch den Incident-Prozess (Referenzbericht).

Lösung für Finanzinstitute

Risiken des Monitorings selbst und wirksame Kontrollen

Monitoring-Systeme haben weitreichende Leserechte, oft auf alle Server und Netzwerkgeräte, und sie speichern Daten, aus denen sich der Aufbau der Infrastruktur ablesen lässt. Damit sind sie für Angreifer ein lohnendes Ziel. Zugleich enthalten Logs Personendaten. Die folgenden Kontrollen setzen bei diesen Risiken an.

Zugriff und Integrität

Administrative Zugänge zum Monitoring gehören zu den privilegierten Konten und sind entsprechend zu schützen und regelmässig zu rezertifizieren. Änderungen an Alarmregeln und Schwellenwerten laufen als Change mit Freigabe, denn eine stillgelegte Regel ist eine stillgelegte Kontrolle. Logs werden zentral gespeichert und gegen nachträgliche Veränderung geschützt.

Datenhaltung und Aufbewahrung

Bei Monitoring- und Log-Diensten aus der Cloud ist zu klären, wo die Daten liegen und wer darauf zugreifen kann. Für Banken verlangt FINMA-RS 2023/1, erhöhte Risiken angemessen zu begrenzen und zu überwachen, wenn kritische Daten ausserhalb der Schweiz gespeichert werden oder vom Ausland aus zugänglich sind. Aufbewahrungsfristen gehören dokumentiert: lang genug für Analyse und Nachweis, kurz genug für den Grundsatz der Verhältnismässigkeit nach Art. 6 DSG.

Wirksamkeit belegen

• Abdeckungsgrad: Anteil der kritischen IKT-Bestandteile mit aktivem Monitoring, abgeglichen mit dem Inventar.
• Erkennungszeit: Zeit zwischen Beginn und Erkennung eines Vorfalls, auch Mean Time to Detect genannt.
• Alarmtests: dokumentierte Tests der Alarmkette bis zum Bereitschaftsdienst, mindestens nach jeder grösseren Änderung.
• Quote handlungsrelevanter Alarme: Ein hoher Anteil folgenloser Alarme deutet auf eine Alarmflut hin, in der echte Vorfälle untergehen können.

Wie eine Organisation ihre Informationssicherheit insgesamt steuert und belegt, beschreibt der Glossarartikel ISO 27001.

Häufige Fragen zum Monitoring

Was ist Monitoring?

Monitoring ist die systematische und fortlaufende Überwachung von IT-Komponenten, Anwendungen und Services. Messwerte und Ereignisse werden erfasst und gegen Sollwerte geprüft, Abweichungen werden an festgelegte Stellen gemeldet. In regulierten Umgebungen dient Monitoring zugleich als Nachweis, dass Störungen und Angriffe zeitnah erkannt werden.

Verlangt das Datenschutzgesetz ein Monitoring?

Das DSG schreibt kein bestimmtes Werkzeug vor. Art. 8 DSG verlangt aber eine dem Risiko angemessene Datensicherheit, und Art. 3 DSV nennt Massnahmen, mit denen Verletzungen der Datensicherheit rasch erkannt werden. Unter bestimmten Voraussetzungen schreibt Art. 4 DSV zudem eine Protokollierung vor, die mindestens ein Jahr aufzubewahren ist.

Was verlangt die FINMA zur Überwachung?

Das Rundschreiben 2023/1 verlangt von Banken unter anderem die zeitnahe Aufzeichnung und Erkennung von Cyber-Attacken auf Basis einer systematischen und durchgängigen Überwachung der inventarisierten IKT-Bestandteile und kritischen Daten. Für meldepflichtige Cyber-Attacken gilt eine Vororientierung innert 24 Stunden und die Meldung innert 72 Stunden.

Wer muss Cyberangriffe dem BACS melden?

Seit dem 1. April 2025 müssen Betreiber kritischer Infrastrukturen Cyberangriffe innert 24 Stunden nach der Entdeckung melden, zum Beispiel Unternehmen der Energie- oder Trinkwasserversorgung, Transportunternehmen sowie die Verwaltungen von Kantonen und Gemeinden. Meldepflichtig ist ein Angriff unter anderem, wenn er die Funktionsfähigkeit der Infrastruktur gefährdet oder zu einem Abfluss von Informationen geführt hat. Grundlage ist das ISG, Art. 74b regelt, wer melden muss. Ein dokumentiertes Monitoring hilft, den Zeitpunkt der Entdeckung zu belegen.

Wie lange sollten Monitoring- und Log-Daten aufbewahrt werden?

Eine allgemeine Frist gibt es nicht. Fällt eine Bearbeitung unter Art. 4 DSV, sind die Protokolle mindestens ein Jahr getrennt vom System aufzubewahren. Darüber hinaus richtet sich die Frist nach Analysebedarf, Branchenvorgaben und dem Grundsatz der Verhältnismässigkeit. Halten Sie sie je Datenart schriftlich fest.

Wie unterstützt ky2help^® die Nachvollziehbarkeit von Vorfällen?

ky2help^® historisiert Vorgänge automatisch, bietet ein integriertes Daten-Audit und ist auf revisionssichere Dokumentation ausgelegt. Monitoring-Systeme lassen sich über die REST-API anbinden. Betrieben wird ky2help^® als SaaS mit eigener Instanz in einem Schweizer Rechenzentrum oder On-Premises.

Quellen und weiterführende Artikel

Quellen

• Fedlex: Bundesgesetz über den Datenschutz (DSG, SR 235.1), Art. 6 und 8
• Fedlex: Verordnung über den Datenschutz (DSV, SR 235.11), Art. 3 und 4
• FINMA: Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken» (PDF)
• BACS: Meldepflicht für Cyberangriffe auf kritische Infrastrukturen
• PeopleCert: ITIL^® 4 Foundation (Practice Monitoring and Event Management)
• Google: Site Reliability Engineering, Kapitel «Monitoring Distributed Systems» (englisch)
• KYBERNA: Referenzbericht CCT Software Solutions und Funktionsumfang von ky2help^®

Weiterlesen im Glossar und auf kyberna.ch

• Incident und Change Management
• CMDB und Root Cause Analysis
• ISO 27001 und Service Level Agreement (SLA)
• ky2help^® für Finanzdienstleister und Banken
• Cybersecurity Services und Cloud oder On-Premises