Die Nichtkonformitätsklausel der ISO und NISTs Leitfaden zur Überwachung machen aus einer fehlgeschlagenen geplanten Prüfung eine Reaktion, die jemand dokumentieren muss; eine Prüfung, die nicht laufen konnte, hat dagegen nichts gezeigt und gehört in keine der beiden Spalten.
Die Nichtkonformitätsklausel der ISO und NISTs Leitfaden zur Überwachung machen aus einer fehlgeschlagenen geplanten Prüfung eine Reaktion, die jemand dokumentieren muss; eine Prüfung, die nicht laufen konnte, hat dagegen nichts gezeigt und gehört in keine der beiden Spalten.
Kontinuierliche Überwachung findet nach NISTs eigener Darstellung in Intervallen statt. Die NIST- und ISO-Texte zitiere ich im Folgenden im englischen Original, jeweils mit einer sinngemässen deutschen Wiedergabe. SP 800-137, der Leitfaden zu Information Security Continuous Monitoring, definiert die Praxis als „maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions" (sinngemäss: fortlaufendes Bewusstsein über Informationssicherheit, Schwachstellen und Bedrohungen, um Risikomanagemententscheidungen der Organisation zu stützen). Fussnote 2 erklärt dann, was „continuous" und „ongoing" bedeuten: Controls und Risiken werden „assessed and analyzed at a frequency sufficient to support risk-based security decisions" (sinngemäss: in einer Häufigkeit bewertet und analysiert, die für risikobasierte Sicherheitsentscheidungen ausreicht). Sie endet mit diesem Satz:
„Data collection, no matter how frequent, is performed at discrete intervals."
Sinngemäss: Datenerhebung erfolgt, wie häufig auch immer, in diskreten Intervallen.
Eine automatisierte Prüfung, die jede Nacht läuft, ist eine Reihe datierter Beobachtungen. Eine quartalsweise Überprüfung der Zugriffsrechte ebenso. Beides ist Überwachung. Die Frage des Auditors ist in beiden Fällen dieselbe: Wer hat das Intervall gewählt, und mit welcher Begründung?
Die ISO-Seite stellt dieselbe Frage. ISO/IEC 27001 gehört zu den Managementsystemnormen, die auf der Harmonisierten Struktur (Harmonized Structure, HS) aufbauen. Die Directives der ISO beschreiben sie als „identical clause numbers, clause titles, text and common terms and core definitions" (sinngemäss: identische Klauselnummern, Klauseltitel und Texte sowie gemeinsame Begriffe und Kerndefinitionen). Ihre Klausel 9.1 lautet:
„The organization shall determine:- what needs to be monitored and measured;- the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results;- when the monitoring and measuring shall be performed;- when the results from monitoring and measurement shall be analysed and evaluated.Documented information shall be available as evidence of the results."
Sinngemäss: Die Organisation muss bestimmen, was überwacht und gemessen werden muss; mit welchen Methoden überwacht, gemessen, analysiert und bewertet wird, soweit zutreffend, um gültige Ergebnisse sicherzustellen; wann überwacht und gemessen wird; und wann die Ergebnisse der Überwachung und Messung analysiert und bewertet werden. Dokumentierte Information muss als Nachweis der Ergebnisse verfügbar sein.
ISO/IEC 27001 ergänzt diesen Text um eigene Formulierungen. Die Norm ist kostenpflichtig, deshalb zitiere ich nur den gemeinsamen Kern. Für dieses Argument genügt er. Die Häufigkeit ist eine Entscheidung, die die Organisation trifft und verantwortet. Keine Klausel gibt Ihnen eine Zahl vor.
Der Control-Katalog von NIST sagt dasselbe in seinem eigenen Format. SP 800-53 Rev. 5, Control CA-7, verlangt „[Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessment of control effectiveness" (sinngemäss: von der Organisation festgelegte Häufigkeiten für die Überwachung und für die Bewertung der Wirksamkeit von Controls). Die Erläuterung (Discussion) ergänzt: „Different types of controls may require different monitoring frequencies." (Sinngemäss: Unterschiedliche Arten von Controls können unterschiedliche Überwachungshäufigkeiten erfordern.) SP 800-137 §2.2 geht weiter: Häufigkeiten „are not static, and they are not uniform across all metrics" (sinngemäss: sind weder statisch noch über alle Kennzahlen hinweg einheitlich).
In der Praxis heisst das: Schreiben Sie das Intervall neben jede Prüfung, zusammen mit der Begründung dafür. „Täglich, weil ein einzelner Admin die Branch Protection in wenigen Sekunden abschalten kann" ist eine Begründung, die ein Auditor prüfen kann. Ein blosses „wir überwachen kontinuierlich" gibt ihm nichts zu prüfen.
Die Harmonisierte Struktur definiert Überwachung in Klausel 3.20 als „determining the status of a system, a process (3.8) or an activity" (sinngemäss: Bestimmung des Zustands eines Systems, eines Prozesses oder einer Tätigkeit). Ein bestandener Lauf sagt Ihnen den Zustand zum Zeitpunkt des Laufs, und nicht mehr.
Deshalb ist ein einzelnes Bestanden ein schwacher Nachweis und eine Reihe davon ein starker. Nehmen Sie eine Prüfung, die gestern bestanden hat, ohne Aufzeichnung der Läufe davor. Sie zeigt, dass die Einstellung gestern aktiv war. Nehmen Sie dieselbe Prüfung mit einem Jahr datierter Läufe im gewählten Intervall, jeder davon aufbewahrt. Diese Reihe zeigt, dass der Control über den gesamten Zeitraum gewirkt hat. 9.1 schliesst genau mit diesem Punkt: „Documented information shall be available as evidence of the results." Bewahren Sie die Ergebnisse auf, auch die bestandenen, denn aus ihnen besteht die Reihe.
Eine fehlgeschlagene Prüfung hat eine Nichtkonformität gefunden, die die Harmonisierte Struktur in Klausel 3.16 als „non-fulfilment of a requirement" definiert (sinngemäss: Nichterfüllung einer Anforderung). Klausel 10.2 sagt dann, was folgt. Tritt eine Nichtkonformität auf, muss die Organisation:
„a) react to the nonconformity, and as applicable:- take action to control and correct it;- deal with the consequences;b) evaluate the need for action to eliminate the cause(s) of the nonconformity, in order that it does not recur or occur elsewhere, by:- reviewing the nonconformity;- determining the causes of the nonconformity;- determining if similar nonconformities exist, or can potentially occur;c) implement any action needed;d) review the effectiveness of any corrective action taken;e) make changes to the XXX management system, if necessary."
Sinngemäss: a) auf die Nichtkonformität reagieren und, soweit zutreffend, Massnahmen ergreifen, um sie unter Kontrolle zu bringen und zu korrigieren, sowie mit den Folgen umgehen; b) bewerten, ob Massnahmen nötig sind, um die Ursache(n) der Nichtkonformität zu beseitigen, damit sie nicht erneut oder an anderer Stelle auftritt, und zwar durch Überprüfen der Nichtkonformität, Bestimmen ihrer Ursachen und Bestimmen, ob ähnliche Nichtkonformitäten bestehen oder auftreten könnten; c) alle erforderlichen Massnahmen umsetzen; d) die Wirksamkeit aller ergriffenen Korrekturmassnahmen überprüfen; e) falls erforderlich, das XXX-Managementsystem ändern.
Sie endet mit der Dokumentation:
„Documented information shall be available as evidence of:- the nature of the nonconformities and any subsequent actions taken;- the results of any corrective action."
Sinngemäss: Dokumentierte Information muss verfügbar sein als Nachweis über die Art der Nichtkonformitäten und alle daraufhin ergriffenen Massnahmen sowie über die Ergebnisse jeder Korrekturmassnahme.
Neben eine rote Prüfung gelegt, ist diese Liste eine Arbeitsliste. Jemand dämmt das Problem ein; jemand fragt, warum die Einstellung abgewichen ist und ob dieselbe Abweichung auch in anderen Repositories oder Konten besteht; jemand behebt sie und bestätigt später, dass die Behebung gehalten hat. All das wird schriftlich festgehalten.
NIST benennt ausdrücklich eine Reaktion, die 10.2 nicht nennt. SP 800-137 §3.5 sagt: „Response to findings at all tiers may include risk mitigation, risk acceptance, risk avoidance/rejection, or risk sharing/transfer, in accordance with organizational risk tolerance." (Sinngemäss: Die Reaktion auf Befunde kann auf allen Ebenen Risikominderung, Risikoakzeptanz, Risikovermeidung/-ablehnung oder Risikoteilung/-übertragung umfassen, entsprechend der Risikotoleranz der Organisation.) Ein Fehlschlag muss nicht mit einer Behebung enden. Er kann mit der Entscheidung enden, das Risiko zu akzeptieren: das Legacy-Repository, das keine Branch Protection verträgt, oder das Service-Konto, das ohne MFA auskommen muss. Diese Entscheidung ist legitim. Sie muss trotzdem von jemandem getroffen werden, der dazu befugt ist, und mit ihrer Begründung dokumentiert werden. CA-7(f) verlangt „response actions to address results of the analysis" (sinngemäss: Reaktionsmassnahmen auf die Ergebnisse der Analyse). Welche Reaktion Sie auch wählen, sie muss schriftlich existieren.
Eine Prüfung kann das Erkennen übernehmen und nichts, was danach kommt. SP 800-137 §2.3 sagt unmissverständlich, dass „it is not possible to fully automate all of an organization's information security program functions" (sinngemäss: es nicht möglich ist, alle Funktionen des Informationssicherheitsprogramms einer Organisation vollständig zu automatisieren) und dass Werkzeuge weiterhin menschliche „interpretation of findings" (Interpretation der Befunde) erfordern. Die Entscheidung über eine Ausnahme gehört zu den Funktionen, die bei einem Menschen bleiben. Jeder Workflow, der eine fehlgeschlagene Prüfung ohne Verantwortlichen und ohne Begründung auf Grün setzt, hat genau die Dokumentation gelöscht, die 10.2 verlangt.
Geplante Prüfungen haben ein drittes Ergebnis. Die Prüfung konnte die API des Anbieters nicht erreichen, die Zugangsdaten wurden widerrufen, oder der Endpunkt lief in einen Timeout. Der Lauf ist zu Ende, hat aber nichts über den Control gezeigt.
Zählt man diesen Lauf als bestanden, verdeckt man eine Lücke: Solange die Fehler andauern, haben Sie überhaupt keine Beobachtung. Zählt man ihn als fehlgeschlagen, erfindet man eine Nichtkonformität. Jemand eröffnet einen 10.2-Vorgang für eine Einstellung, die womöglich völlig in Ordnung ist, und die Historie der Korrekturmassnahmen füllt sich mit Rauschen, nach dem ein Auditor fragen wird. Ehrlich ist beides nicht. Ein Fehler ist ein Versagen der Überwachung, und er braucht einen eigenen Verantwortlichen und eine eigene Reaktion.
NIST behandelt das Versagen eines Überwachungsmechanismus bereits als eigenes Ereignis, in einem benachbarten Kontext. Control AU-5 in SP 800-53 betrifft die Audit-Protokollierung, nicht Compliance-Prüfungen, doch die Logik lässt sich übertragen. Er verlangt von Organisationen: „Alert [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period] in the event of an audit logging process failure" (sinngemäss: von der Organisation festgelegtes Personal oder festgelegte Rollen innerhalb einer von der Organisation festgelegten Frist alarmieren, wenn der Audit-Protokollierungsprozess ausfällt). Die kaputte Log-Pipeline bekommt ihren eigenen Alarm und einen eigenen, namentlich festgelegten Empfänger, unabhängig davon, was die Logs gezeigt hätten. Die Erläuterung zu CA-7 macht einen verwandten Punkt zur Diagnose: „a root-cause analysis may be needed to determine the specific control that has failed" (sinngemäss: eine Ursachenanalyse kann nötig sein, um den konkreten Control zu bestimmen, der versagt hat). Bevor Sie einen Vorgang gegen einen Control eröffnen, vergewissern Sie sich, dass es der Control war, der versagt hat.
| Ergebnis | Was es zeigt | Zustand des Nachweises | Dokumentation, die folgen muss |
|---|---|---|---|
| Bestanden | Den Zustand zum Zeitpunkt des Laufs | Aktuell bis zum nächsten geplanten Lauf | Das datierte Ergebnis, aufbewahrt als Teil der Reihe |
| Fehlgeschlagen | Eine Nichtkonformität zum Zeitpunkt des Laufs | Fehlgeschlagen | Art, Eindämmung, Ursache, Massnahme oder akzeptiertes Risiko samt Begründung, und die Bestätigung, dass die Massnahme gehalten hat (HS 10.2) |
| Fehler | Nichts über den Control | Unverändert seit dem letzten tatsächlichen Prüfergebnis | Eine Benachrichtigung an den Verantwortlichen der Überwachung, und ein Vermerk der Lücke, falls sie andauert |
Gleichen Sie Ihr Setup mit der letzten Spalte ab. Wenn ein Fehlschlag ohne benannte Entscheidung geschlossen werden kann oder ein Fehler einen Monat lang unbemerkt bleibt, sehen Ihre Ergebnisse gut aus, genau bis zum Audit.
devguard hat im September 2026 Integrationsprüfungen veröffentlicht, aufgebaut um die obige Tabelle.
Eine Prüfung läuft nach einem Zeitplan, den Sie ihr zuweisen. Jeder Lauf wird mit seinem Ergebnis aufbewahrt, sodass ein Nachweis eine Historie hat statt nur eines einzelnen Upload-Datums.
Ein Bestanden setzt den verknüpften Nachweis auf erledigt und hält den Lauf als letzte Überprüfung fest. Ein Fehlschlag setzt den Nachweis auf fehlgeschlagen, hält fest, was nicht stimmte, und lässt die Überprüfungsdaten, wo sie waren; der Nachweiseigentümer wird benachrichtigt, sobald die Prüfung zu scheitern beginnt. Ein Fehler lässt den Nachweis unberührt, denn abgelehnte Zugangsdaten oder eine nicht erreichbare API beweisen nichts über den Control. Nach drei Fehlern in Folge wird die Prüfung als gestört markiert, und der Nachweiseigentümer erhält eine E-Mail. Ein Testlauf zeigt das vollständige Ergebnis, ohne einen Nachweis zu schreiben.
Zwei dieser Entscheidungen haben ihren Preis, und devguard nimmt beide bewusst in Kauf.
Die erste: Ein Fehler lässt den Nachweis in Ruhe. Solange eine Prüfung weiter mit Fehler endet, behält der Nachweis den Status seines letzten tatsächlichen Prüfergebnisses; ein als erledigt markierter Nachweis kann also einige Läufe lang auf einer API aufsetzen, die nicht mehr antwortet. Ihn auf fehlgeschlagen zu setzen, würde eine falsche Nichtkonformität in die Dokumentation bringen; stattdessen erreicht die Lücke den Eigentümer über die Markierung als gestört.
Die zweite: Die Benachrichtigung über einen Fehlschlag geht einmal raus. Sie wird beim Wechsel in den Zustand fehlgeschlagen ausgelöst, nicht bei jedem Lauf, solange die Prüfung rot bleibt, denn eine stündliche Prüfung würde sonst pro Stunde eine E-Mail zum selben Problem verschicken. Der Status fehlgeschlagen bleibt die ganze Zeit sichtbar, aber niemand wird per E-Mail daran erinnert.
Die Prüfung entscheidet nicht über die Reaktion. Sie hält fest, dass der Nachweis fehlgeschlagen ist, und informiert den Eigentümer; nichts wird automatisch behoben oder ausgenommen. Die Arbeit nach 10.2 bleibt bei einem Menschen: die Ursache, die Behebung oder das akzeptierte Risiko, und die Begründung dafür.
Bevor Sie eine Prüfung automatisieren, schreiben Sie drei Dinge daneben: das Intervall und warum Sie es gewählt haben, wer für einen Fehlschlag verantwortlich ist, und wer davon erfährt, wenn die Prüfung selbst kaputtgeht.
devguard führt Integrationsprüfungen nach dem von Ihnen festgelegten Zeitplan aus und erfasst Bestanden, Fehlgeschlagen und Fehler als getrennte Ergebnisse an Ihren Nachweisen; die Details stehen im Changelog.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.