{"id":34269,"date":"2026-07-24T20:28:29","date_gmt":"2026-07-24T20:28:29","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/external-synthetic-monitoring-dora\/"},"modified":"2026-07-24T20:28:29","modified_gmt":"2026-07-24T20:28:29","slug":"external-synthetic-monitoring-dora","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/external-synthetic-monitoring-dora\/","title":{"rendered":"Externes synthetisches Monitoring f\u00fcr DORA Betriebsresilienz"},"content":{"rendered":"
Betriebliche Resilienz \u00b7 ICT-Risikomanagement \u00b7 Finanzdienstleistungen<\/em><\/p>\n Das Digital Operational Resilience Act (DORA), Verordnung (EU) 2022\/2554<\/a>, gilt seit dem 17. Januar 2025 f\u00fcr Finanzunternehmen der Europ\u00e4ischen Union. Zu den zentralen Zielen geh\u00f6rt die Anforderung, dass Unternehmen ICT-Vorf\u00e4lle (Informations- und Kommunikationstechnologie) unverz\u00fcglich erkennen und die Verf\u00fcgbarkeit von Diensten, die kritische oder wichtige Funktionen unterst\u00fctzen, aufrechterhalten.<\/p>\n Um dieses Ziel zu erreichen, ist ein Monitoring erforderlich, das die tats\u00e4chliche Verf\u00fcgbarkeit kundenorientierter Dienste widerspiegelt und nicht nur die interne Systemgesundheit dahinter. Interne Observability-Tools berichten \u00fcber Infrastruktur innerhalb des Unternehmensnetzwerks. Sie best\u00e4tigen nicht, ob ein Dienst von der Position eines externen Nutzers erreichbar und funktionsf\u00e4hig ist. Externes synthetisches Monitoring greift dies auf, indem es skriptgesteuerte Transaktionen gegen Produktionsdienste von au\u00dferhalb des Netzwerks nach einem definierten Zeitplan ausf\u00fchrt.<\/p>\n Dieser Artikel beschreibt die spezifischen DORA-Verpflichtungen, die sich auf kontinuierliches Monitoring und Erkennung beziehen, und erl\u00e4utert, wie externes synthetisches Monitoring<\/a> und insbesondere die Dotcom-Monitor-Plattform diese erf\u00fcllen.<\/p>\n DORA ist ergebnisorientiert und gibt keine Werkzeuge vor. Es schreibt weder ein bestimmtes Monitoring-Produkt noch eine Pr\u00fcffrequenz vor. Es legt Anforderungen an Erkennung, Verf\u00fcgbarkeit und \u00dcberwachung fest, wobei das Monitoring die operative Steuerung ist, durch die mehrere dieser Verpflichtungen erf\u00fcllt werden. Vier Bestimmungen sind am relevantesten.<\/p>\n Artikel 9 (Schutz und Pr\u00e4vention)<\/strong> verlangt von Finanzunternehmen, die Sicherheit und Funktionalit\u00e4t von ICT-Systemen und -Werkzeugen kontinuierlich zu \u00fcberwachen und zu steuern. Die Verpflichtung ist fortlaufend, was periodische oder manuelle Kontrollen als alleinige Ma\u00dfnahme ausschlie\u00dft.<\/p>\n Artikel 10 (Erkennung)<\/strong> verlangt Mechanismen, um anomale Aktivit\u00e4ten, einschlie\u00dflich ICT-Netzwerkleistungsprobleme und ICT-bezogene Vorf\u00e4lle, unverz\u00fcglich zu erkennen und potenzielle wesentliche Single Points of Failure zu identifizieren. Artikel 10(2) verlangt zus\u00e4tzlich, dass Erkennungsmechanismen mehrere Kontrollschichten erm\u00f6glichen, Alarmschwellen definieren und automatische Warnungen an das f\u00fcr die Vorfallreaktion verantwortliche Personal enthalten.<\/p>\n “Finanzunternehmen m\u00fcssen Mechanismen zur unverz\u00fcglichen Erkennung anomaler Aktivit\u00e4ten, einschlie\u00dflich ICT-Netzwerkleistungsproblemen und ICT-bezogenen Vorf\u00e4llen, vorhalten.” Artikel 17 und 19 (Vorfallmanagement und Meldung)<\/strong> verlangen einen dokumentierten Prozess zur Verwaltung ICT-bezogener Vorf\u00e4lle und bei als schwerwiegend eingestuften Vorf\u00e4llen eine Benachrichtigung der zust\u00e4ndigen Beh\u00f6rde innerhalb einer von der Aufsichtsbeh\u00f6rde vorgegebenen Frist, die in Stunden und nicht Tagen gemessen wird. Die Geschwindigkeit der Benachrichtigung h\u00e4ngt direkt von der Erkennungsgeschwindigkeit ab.<\/p>\n Artikel 28 (ICT-Drittanbieterrisiko)<\/strong> verpflichtet Organisationen, das Risiko aus ICT-Drittanbieterdiensten zu verwalten und zu \u00fcberwachen. Unterst\u00fctzt ein Anbieter eine kritische oder wichtige Funktion, f\u00e4llt dessen Verf\u00fcgbarkeit in den \u00dcberwachungsverantwortungsbereich des Unternehmens.<\/p>\n Aus diesen Bestimmungen folgen f\u00fcnf erforderliche Monitoring-F\u00e4higkeiten: kontinuierliches Monitoring, unverz\u00fcgliche Vorfallerkennung, Verf\u00fcgbarkeitsvalidierung, \u00dcberwachung von ICT-Drittanbietern und Fr\u00fchwarnung bei Dienstverschlechterung. Die Abschnitte unten behandeln jeweils eine F\u00e4higkeit.<\/p>\n Interne Werkzeuge, einschlie\u00dflich Application Performance Management (APM), Server-Metriken und Log-Analyse, \u00fcberwachen Systeme von innerhalb des Netzwerks. Sie berichten genau \u00fcber den Infrastrukturzustand, erkennen aber keine Ausfallarten, die zwischen dem Nutzer und den Servern auftreten. Dazu geh\u00f6ren:<\/p>\n In all diesen F\u00e4llen meldet das interne Monitoring normalen Betrieb, w\u00e4hrend der Dienst f\u00fcr Nutzer nicht verf\u00fcgbar ist. Externes synthetisches Monitoring f\u00fchrt die Benutzertransaktion von au\u00dferhalb des Netzwerks aus und registriert den Ausfall genau an dem Punkt, an dem er die Nutzer beeintr\u00e4chtigt.<\/p>\n Die externe Verifikation hat auch Beweiskraft f\u00fcr Compliance. Ein Verf\u00fcgbarkeitsnachweis ist f\u00fcr Pr\u00fcfer glaubw\u00fcrdiger, wenn die Messung au\u00dferhalb des gemessenen Systems erfolgt. Unabh\u00e4ngige, zeitgestempelte Verf\u00fcgbarkeitsdaten unterst\u00fctzen die Pr\u00fcf- und Meldepflichten, die DORA f\u00fcr die Erkennung vorsieht.<\/p>\n Die folgenden Unterabschnitte nennen jede Anforderung und die zugeh\u00f6rige F\u00e4higkeit, die sie erf\u00fcllt. Dotcom-Monitor ist eine synthetische Monitoring-Plattform, die Pr\u00fcfungen von au\u00dferhalb des Netzwerks durchf\u00fchrt, was mit den oben aufgef\u00fchrten Erkennungs- und Verf\u00fcgbarkeitsanforderungen \u00fcbereinstimmt.<\/p>\n Anforderung.<\/strong> Kontinuierliche \u00dcberwachung und Steuerung der Funktion von ICT-Systemen, die kundenorientierte Dienste unterst\u00fctzen.<\/p>\n Wie es adressiert wird.<\/strong> Geplante synthetische Checks laufen in definierten Intervallen, bis zu einer Minute h\u00e4ufig, und bieten unterbrechungsfreie \u00dcberwachung der Dienste. Webanwendungsmonitoring<\/a> l\u00e4dt den Dienst in einem echten Browser und misst das gerenderte Ergebnis, anstatt nur zu best\u00e4tigen, dass ein Server antwortet. So entsteht eine kontinuierliche Aufzeichnung, ob der Dienst wie vom Nutzer erlebt funktioniert.<\/p>\n Anforderung.<\/strong> Unverz\u00fcgliche Erkennung anomaler Aktivit\u00e4ten, einschlie\u00dflich ICT-Netzwerkleistungsproblemen und Vorf\u00e4llen, und Identifikation wesentlicher Single Points of Failure.<\/p>\n Wie es adressiert wird.<\/strong> Eine synthetische Transaktion, die fehlschl\u00e4gt oder eine definierte Antwortzeitgrenze \u00fcberschreitet, identifiziert den Zustand im Pr\u00fcfzyklus, unabh\u00e4ngig von Nutzerberichten. Vollst\u00e4ndige Abl\u00e4ufe werden mit dem EveryStep-Recorder<\/a> geskriptet, wodurch die Erkennung \u00fcber die Seitenverf\u00fcgbarkeit hinaus auf mehrstufige Prozesse wie Authentifizierung, Zahlung und Kontoer\u00f6ffnung erweitert wird, bei denen ein einziger fehlgeschlagener Schritt einen Vorfall darstellt.<\/p>\n Anforderung.<\/strong> Definition von Alarmschwellen und automatische Warnungen f\u00fcr das f\u00fcr die Vorfallreaktion zust\u00e4ndige Personal.<\/p>\n Wie es adressiert wird.<\/strong> Konfigurierbare Warnungen<\/a> werden bei definierten Bedingungen ausgel\u00f6st, darunter Antwortzeiten \u00fcber einem Grenzwert, Fehlerantworten oder ein fehlgeschlagener Transaktionsschritt. Warnungen werden automatisch per E-Mail, SMS oder integrierten Vorfallmanagement-Tools an bestimmte Empf\u00e4nger geschickt und nicht in eine gemeinsame Warteschlange gestellt. Schwellenwertbasierte Warnungen bei Leistungseinbu\u00dfen, nicht nur bei vollst\u00e4ndigen Ausf\u00e4llen, unterst\u00fctzen die in Artikel 10(2) verlangten mehrstufigen Kontrollmechanismen.<\/p>\n Anforderung.<\/strong> Nachweis, dass Dienste, die kritische oder wichtige Funktionen unterst\u00fctzen, verf\u00fcgbar blieben, mit Aufzeichnungen, die f\u00fcr Pr\u00fcfungen und Nachbewertungen geeignet sind.<\/p>\n Wie es adressiert wird.<\/strong> Uptime- und SLA-Berichte<\/a> bieten zeitgestempelte Verf\u00fcgbarkeitsverl\u00e4ufe f\u00fcr jeden \u00fcberwachten Dienst. Da die Messung von au\u00dferhalb des Netzwerks erfolgt, stellen die Berichte unabh\u00e4ngige Nachweise \u00fcber Verf\u00fcgbarkeit sowie Zeitpunkt und Dauer von Unterbrechungen dar. Diese Aufzeichnungen unterst\u00fctzen interne \u00dcberpr\u00fcfungen und Pr\u00fcfungsanfragen. Verf\u00fcgbarkeitsziele werden in den Plattformressourcen zum Uptime-Monitoring<\/a> erl\u00e4utert.<\/p>\n Anforderung.<\/strong> \u00dcberwachung der Verf\u00fcgbarkeit und Leistung von ICT-Drittanbietern, die kritische oder wichtige Funktionen unterst\u00fctzen.<\/p>\n Wie es adressiert wird.<\/strong> API-Monitoring<\/a> pr\u00fcft die REST-, SOAP- und GraphQL-Endpunkte, von denen eine Anwendung abh\u00e4ngt, auch solche von Drittanbietern. F\u00fcr gehostete Anwendungen im Betrieb verfolgt SaaS-Monitoring<\/a> die Verf\u00fcgbarkeit des Anbieters direkt, sodass das Unternehmen unabh\u00e4ngige Sicht auf eine Abh\u00e4ngigkeit erh\u00e4lt und nicht allein auf die Statusmeldungen des Anbieters angewiesen ist.<\/p>\n Anforderung.<\/strong> Fr\u00fchwarnung bei Dienstverschlechterung und rechtzeitige Erkennung schwerwiegender Vorf\u00e4lle, um Meldefristen einzuhalten.<\/p>\n Wie es adressiert wird.<\/strong> Da Checks kontinuierlich von au\u00dferhalb des Netzwerks laufen, werden Verschlechterungen und Ausf\u00e4lle nahe am Auftretensort erkannt, wodurch das Intervall zwischen Vorfallbeginn und Erkennung verk\u00fcrzt wird. Dieses Intervall ist besonders f\u00fcr Artikel 17 und 19 relevant, bei denen die Meldungsfrist f\u00fcr einen schweren Vorfall in Stunden gemessen wird. Fr\u00fchere Erkennung erh\u00f6ht die Zeit zur Klassifizierung, Reaktion und Meldung eines Vorfalls. Dieselbe F\u00e4higkeit unterst\u00fctzt Fr\u00fcherkennung von Ausf\u00e4llen<\/a> und wird im Kontext von synthetischem Monitoring im Finanzdienstleistungsbereich<\/a> weiter untersucht.<\/p>\n Anforderung.<\/strong> \u00dcberwachung interner Anwendungen, die kritische oder wichtige Funktionen unterst\u00fctzen, zus\u00e4tzlich zu \u00f6ffentlichen Diensten.<\/p>\n Wie es adressiert wird.<\/strong> \u00d6ffentliche Dienste werden vom globalen Monitoring-Netzwerk<\/a> \u00fcberpr\u00fcft. Interne Anwendungen hinter der Firewall werden durch Private Agents<\/a> innerhalb der Umgebung des Unternehmens \u00fcberwacht, wobei dieselben Pr\u00fcfungen auf interne und externe Systeme \u00fcber eine einzige Plattform angewandt werden.<\/p>\n Die Tabelle fasst die oben dargestellten Zuordnungen zusammen.<\/p>\n Zwei Ausfallbedingungen verdeutlichen, warum externe Verifikation erforderlich ist. Beide k\u00f6nnen durch internes Monitoring allein nicht erfasst werden.<\/p>\n Regionale DNS-Fehlkonfiguration.<\/strong> Eine DNS-\u00c4nderung wird f\u00fcr einen einzelnen Internetdienstanbieter falsch aufgel\u00f6st. Serverseitige Metriken bleiben nominal, da betroffene Anfragen die Infrastruktur nicht erreichen. Ein externer Check aus der betroffenen Region protokolliert den Ausfall im n\u00e4chsten Zyklus und l\u00f6st eine Warnung mit Angabe des betroffenen Standorts aus.<\/p>\n Drittanbieter-Authentifizierungslatenz.<\/strong> Ein externer Identit\u00e4tsanbieter ist verf\u00fcgbar, reagiert jedoch langsam und verursacht mehrere Sekunden Verz\u00f6gerung pro Authentifizierung. Es wird kein interner Fehler gemeldet. Eine synthetische Transaktion, die die komplette Anmeldung durchf\u00fchrt, misst die erh\u00f6hte Antwortzeit, \u00fcberschreitet den konfigurierten Schwellenwert und identifiziert die Abh\u00e4ngigkeit als Ursache. Dies ist die Sichtbarkeit, die Artikel 28 f\u00fcr Drittanbieter vorsieht.<\/p>\n Die folgende Konfiguration stellt eine Monitoring-Basislinie sicher, die mit den oben beschriebenen Erkennungs- und Verf\u00fcgbarkeitsverpflichtungen \u00fcbereinstimmt. Sie priorisiert kritische Pfade statt vollst\u00e4ndiger Abdeckung.<\/p>\n Schritt 1: Identifizieren Sie kritische oder wichtige Funktionen.<\/strong> Benennen Sie die kundenorientierten Dienste, deren Ausfall einen Vorfallbericht erforderlich macht, z. B. Authentifizierung, Zahlungen, \u00dcberweisungen, Kontoer\u00f6ffnung und Kontoauszugzugriff. Diese definieren die Monitoring-Priorit\u00e4t.<\/p>\n Schritt 2: Skripten Sie vollst\u00e4ndige Benutzerabl\u00e4ufe.<\/strong> F\u00fcr jede Funktion zeichnen Sie den gesamten Benutzerfluss mit dem EveryStep-Recorder auf, der mit einem Schritt endet, der best\u00e4tigt, dass der Dienst seine Funktion erf\u00fcllt hat, z. B. eine abgeschlossene \u00dcberweisung oder eine geladene Kontenansicht. Nur eine Pr\u00fcfung der Startseite erkennt keinen Fehler in einem sp\u00e4teren Schritt.<\/p>\n Schritt 3: \u00dcberwachen Sie von relevanten Standorten.<\/strong> W\u00e4hlen Sie Monitoring-Standorte aus, die der Kunden-geografie des Unternehmens \u00fcber das globale Monitoring-Netzwerk entsprechen, um regionale Ausf\u00e4lle zu erkennen.<\/p>\n Schritt 4: \u00dcberwachen Sie Drittanbieterabh\u00e4ngigkeiten.<\/strong> Konfigurieren Sie separate Pr\u00fcfvorg\u00e4nge f\u00fcr Drittanbieter-APIs und gehostete Anwendungen, von denen kritische Funktionen abh\u00e4ngen, sodass Quellen f\u00fcr Ausf\u00e4lle dem Unternehmen oder einem Anbieter zugeordnet werden k\u00f6nnen.<\/p>\n Schritt 5: Definieren Sie Schwellenwerte und Alert-Routing.<\/strong> Legen Sie Alarmgrenzen f\u00fcr Antwortzeiten und Fehlerbedingungen fest und leiten Sie Warnungen an zugewiesene Empf\u00e4nger und Vorfallmanagementsysteme. Konfigurieren Sie Alarme bei Leistungseinbu\u00dfen sowie vollst\u00e4ndigen Ausf\u00e4llen.<\/p>\n Schritt 6: Bewahren Sie Verf\u00fcgbarkeitsaufzeichnungen auf.<\/strong> Aktivieren Sie Uptime- und SLA-Berichte von Anfang an, damit Verf\u00fcgbarkeitsverl\u00e4ufe automatisch erfasst werden und f\u00fcr Pr\u00fcfungen und Nachbewertungen zur Verf\u00fcgung stehen.<\/p>\n Schritt 7: Erweitern Sie die Abdeckung auf interne Systeme.<\/strong> Setzen Sie Private Agents f\u00fcr interne Anwendungen ein, die kritische Funktionen unterst\u00fctzen, damit diese Systeme gleichwertig kontinuierlich gepr\u00fcft werden.<\/p>\n Externes synthetisches Monitoring ist eine Kontrollma\u00dfnahme innerhalb eines DORA-Programms und allein nicht vollst\u00e4ndig konform mit der Verordnung. Es liefert Verf\u00fcgbarkeitsvalidierung und unverz\u00fcgliche Erkennung, jedoch keine ICT-Risikogovernance, Vorfallklassifikation und Meldeverfahren, bedrohungsbasierte Penetrationstests, Backup und Recovery oder Vertragsregelungen mit Drittanbietern, die DORA ebenfalls fordert. Diese Verpflichtungen werden durch andere Kontrollen im Resilienzprogramm des Unternehmens erf\u00fcllt.<\/p>\n Synthetisches Monitoring verifiziert zudem nur die geskripteten Transaktionen. Nicht konfigurierte Benutzerabl\u00e4ufe werden nicht \u00fcberwacht, daher muss die Monitoring-Abdeckung bei \u00c4nderungen der Dienste gepflegt werden. Innerhalb dieses festgelegten Rahmens bietet externes synthetisches Monitoring Erkennungs- und Verf\u00fcgbarkeitsnachweise, die nur wenige andere Kontrollen erzeugen.<\/p>\n DORA verlangt von Finanzunternehmen, ICT-Vorf\u00e4lle unverz\u00fcglich zu erkennen sowie die Verf\u00fcgbarkeit und deren Nachweis f\u00fcr Dienste zu gew\u00e4hrleisten, die kritische oder wichtige Funktionen unterst\u00fctzen. Internes Monitoring berichtet \u00fcber den Infrastrukturzustand, erkennt jedoch keine fehlerhaften Zust\u00e4nde zwischen Nutzer und Servern. Externes synthetisches Monitoring \u00fcberpr\u00fcft kontinuierlich die komplette Benutzertransaktion von au\u00dferhalb des Netzwerks und \u00fcber relevante Regionen hinweg, einschlie\u00dflich Drittanbieterabh\u00e4ngigkeiten, und speichert zeitgestempelte Ergebnisprotokolle.<\/p>\n Diese F\u00e4higkeiten entsprechen direkt der Verpflichtung zum kontinuierlichen Monitoring nach Artikel 9, den Erkennungs- und Alarmierungspflichten des Artikels 10, der zeitlichen Vorgabe der Artikel 17 und 19 sowie der Drittanbieter\u00fcberwachung gem\u00e4\u00df Artikel 28. Externes synthetisches Monitoring allein stellt keine DORA-Konformit\u00e4t dar, ist aber ein direkter und belegbarer Weg, die Erkennungs- und Verf\u00fcgbarkeitsanforderungen der Verordnung zu erf\u00fcllen.<\/p>\n Wie externes synthetisches Monitoring die DORA-Anforderungen zu Erkennung und Verf\u00fcgbarkeit erf\u00fcllt, Anforderung f\u00fcr Anforderung abgebildet.<\/p>\n","protected":false},"author":39,"featured_media":34255,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[883],"tags":[],"class_list":["post-34269","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/34269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=34269"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/34269\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/34255"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=34269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=34269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=34269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
DORA-Erkennungs- und Verf\u00fcgbarkeitsverpflichtungen<\/h2>\n
\nDORA, Artikel 10 (Erkennung)<\/cite><\/p><\/blockquote>\nDie Rolle der externen Verifikation<\/h2>\n
\n

Abgleich der DORA-Anforderungen mit den Dotcom-Monitor-F\u00e4higkeiten<\/h2>\n
Kontinuierliches Monitoring (Artikel 9)<\/h3>\n
Unverz\u00fcgliche Erkennung anomaler Aktivit\u00e4ten (Artikel 10)<\/h3>\n
Alarmschwellen und automatische Warnungen (Artikel 10(2))<\/h3>\n
Verf\u00fcgbarkeitsvalidierung und Pr\u00fcfungsnachweise<\/h3>\n
ICT-Drittanbieter\u00fcberwachung (Artikel 28)<\/h3>\n
Fr\u00fchwarnung und Vorfallmeldung (Artikel 10, 17, 19)<\/h3>\n
Abdeckung interner Systeme<\/h3>\n
\u00dcbersicht der Anforderungen und F\u00e4higkeiten<\/h2>\n
\n\n
\n \nDORA-Bestimmung<\/th>\n Anforderung<\/th>\n F\u00e4higkeit von Dotcom-Monitor<\/th>\n<\/tr>\n<\/thead>\n \n Artikel 9<\/td>\n Kontinuierliches Monitoring von ICT-Systemen<\/td>\n Geplante Echtbrowser-Checks in Intervallen von bis zu einer Minute<\/td>\n<\/tr>\n \n Artikel 10(1)<\/td>\n Unverz\u00fcgliche Erkennung anomaler Aktivit\u00e4ten<\/td>\n Synthetische Transaktionen, die Ausf\u00e4lle und Schwellen\u00fcberschreitungen pro Zyklus melden<\/td>\n<\/tr>\n \n Artikel 10(2)<\/td>\n Alarmschwellen und automatische Warnungen<\/td>\n Konfigurierbare Warnungen f\u00fcr bestimmte Empf\u00e4nger bei Fehlern oder Verschlechterungen<\/td>\n<\/tr>\n \n Artikel 17, 19<\/td>\n Rechtzeitige Vorfallerkennung f\u00fcr Meldungen<\/td>\n Kontinuierliche externe Erkennung, die die Zeit bis zur Kenntnis verk\u00fcrzt<\/td>\n<\/tr>\n \n Artikel 28<\/td>\n \u00dcberwachung von ICT-Drittanbietern<\/td>\n API- und SaaS-Monitoring externer Abh\u00e4ngigkeiten<\/td>\n<\/tr>\n \n Audit und \u00dcberpr\u00fcfung<\/td>\n Nachweise der Verf\u00fcgbarkeit<\/td>\n Zeitgestempelte Uptime- und SLA-Berichte von au\u00dferhalb des Netzwerks<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Beispielhafte Erkennungsl\u00fccken<\/h3>\n
Empfohlene Monitoring-Konfiguration<\/h2>\n
Anwendungsbereich und Einschr\u00e4nkungen<\/h2>\n
Fazit<\/h2>\n