Der gemeinsame Text der ISO-Managementsystemnormen verlangt in einer Klausel ein gelenktes Verfahren und in einer anderen den Nachweis, dass es durchgeführt wurde. Auditoren prüfen das Zweite Durchführung für Durchführung, und so hängt ein Control nach dem Muster „das machen wir jeden Monat“ davon ab, was jede einzelne Durchführung hinterlässt.
Der gemeinsame Text der ISO-Managementsystemnormen verlangt in einer Klausel ein gelenktes Verfahren und in einer anderen den Nachweis, dass es durchgeführt wurde. Auditoren prüfen das Zweite Durchführung für Durchführung, und so hängt ein Control nach dem Muster „das machen wir jeden Monat“ davon ab, was jede einzelne Durchführung hinterlässt.
Der gemeinsame Text, auf dem ISO/IEC 27001 aufbaut, verlangt zweimal dokumentierte Information, und er meint damit zwei verschiedene Dinge.
Dieser Text ist die Harmonisierte Struktur (Harmonized Structure, HS), die die Directives der ISO als gemeinsamen Kern ihrer Managementsystemnormen veröffentlichen. ISO/IEC 27001 selbst steht hinter einer Paywall und legt eigenen Wortlaut darüber, deshalb zitiere ich hier nur den gemeinsamen Text. Die ISO-Texte, ebenso die von PCAOB und ENISA weiter unten, zitiere ich im englischen Original, jeweils mit einer sinngemässen deutschen Wiedergabe.
Klausel 7.5.3 betrifft die Dokumente, die Sie schreiben. Sie müssen gelenkt werden, damit jedes davon „is available and suitable for use, where and when it is needed“ (sinngemäss: verfügbar und für die Verwendung geeignet ist, wo und wann es benötigt wird), und die Organisation behandelt dabei:
- „distribution, access, retrieval and use;- storage and preservation, including preservation of legibility;- control of changes (e.g. version control);- retention and disposition.“
Sinngemäss: Verteilung, Zugriff, Auffindung und Verwendung; Ablage und Erhaltung, einschliesslich der Erhaltung der Lesbarkeit; Überwachung von Änderungen (z. B. Versionskontrolle); Aufbewahrung und Verbleib.
Das ist das Leben eines Verfahrens: ein Dokument mit Versionen, einem Verantwortlichen und einem Ort, an dem man es findet.
Klausel 8.1 verlangt etwas anderes. Nachdem sie Kriterien für Prozesse und deren Steuerung „in accordance with the criteria“ (sinngemäss: in Übereinstimmung mit den Kriterien) gefordert hat, heisst es:
„Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned.“
Sinngemäss: Dokumentierte Information muss in dem Umfang verfügbar sein, der nötig ist, um darauf vertrauen zu können, dass die Prozesse wie geplant durchgeführt wurden.
„Carried out as planned“, wie geplant durchgeführt, beschreibt ein Ereignis. Ein Verfahren kann nicht zeigen, dass es befolgt wurde, so gut es auch geschrieben und gelenkt ist. Dafür braucht es ein zweites Artefakt mit Datum, das bei jeder Durchführung entsteht. Das Verfahren wird einmal geschrieben und ab und zu überarbeitet, Durchführungsprotokolle dagegen müssen jedes einzelne Mal entstehen, und deshalb ist ihr Stapel meist der dünnere.
Die beiden altern auch unterschiedlich. Ein Verfahren ändert sich ein paar Mal im Jahr, und jede Änderung ersetzt die alte Version. Durchführungsprotokolle häufen sich an, eines pro Durchführung, und keines ersetzt je ein anderes. Liegen beide Arten im selben Ordner unter demselben Benennungsschema, wird eine davon falsch behandelt.
Die Attestierungsleitlinien zu SOC 2 zitiere ich hier nicht. Die frei lesbare Darstellung dessen, wie Auditoren Controls testen, ist AS 2201 der US-Aufsichtsbehörde für Abschlussprüfer. Der Standard regelt Prüfungen des internen Kontrollsystems über die Finanzberichterstattung, also einen anderen Auftrag, aber die Testmethode, die er beschreibt, ist die, mit der alle arbeiten, die Controls testen.
Absatz .44 legt den Test fest: ob „the control is operating as designed and whether the person performing the control possesses the necessary authority and competence to perform the control effectively“ (sinngemäss: das Control wie konzipiert funktioniert und ob die Person, die es ausführt, über die nötige Befugnis und Kompetenz verfügt, um es wirksam auszuführen). Der Test umfasst also das Verfahren, wie es durchgeführt wurde, und die Person, die es durchgeführt hat.
Absatz .45 nennt die Werkzeuge: Befragung, Beobachtung, „inspection of relevant documentation“ (sinngemäss: Einsichtnahme in relevante Dokumentation) und Nachvollzug. Absatz .50 ordnet sie in dieser Reihenfolge vom geringsten zum grössten Nachweiswert und fügt eine Anmerkung hinzu:
„Inquiry alone does not provide sufficient evidence to support a conclusion about the effectiveness of a control.“
Sinngemäss: Befragung allein liefert keinen ausreichenden Nachweis, um eine Schlussfolgerung über die Wirksamkeit eines Controls zu stützen.
„Das machen wir jeden Monat“ ist eine Antwort auf eine Befragung. Dort beginnt der Test. Absatz .51 sagt, der richtige Test hänge davon ab, „whether the operation of the control results in documentary evidence of its operation“ (sinngemäss: ob die Durchführung des Controls dokumentarische Nachweise ihrer Durchführung hinterlässt). Ein monatlicher Rundgang durch den Serverraum, der nichts hinterlässt, lässt sich nur prüfen, indem man danach fragt oder dabei zusieht. Einer, der ein datiertes, einer Person zugeordnetes Protokoll hinterlässt, lässt sich einsehen, Durchführung für Durchführung, über den ganzen Zeitraum. Absatz .52 ergänzt: „Testing controls over a greater period of time provides more evidence of the effectiveness of controls than testing over a shorter period of time.“ (Sinngemäss: Wer Controls über einen längeren Zeitraum testet, erhält mehr Nachweise für ihre Wirksamkeit als bei einem Test über einen kürzeren Zeitraum.)
Dann gibt es Abweichungen. Absatz .48 verlangt vom Auditor, die Auswirkung jeder gefundenen Abweichung zu beurteilen, und seine Anmerkung ist ein kleines Entgegenkommen: „an individual control does not necessarily have to operate without any deviation to be considered effective“ (sinngemäss: ein einzelnes Control muss nicht zwingend ohne jede Abweichung funktionieren, um als wirksam zu gelten). Ein ausgelassener Schritt mit schriftlicher Begründung ist eine Abweichung, die der Auditor gewichten kann; ein ausgelassener Schritt, den niemand aufgeschrieben hat, hinterlässt nur die Lücke.
Die Durchführungsverordnung (EU) 2024/2690 der Kommission zieht dieselbe Unterscheidung über ihre Verben. Nach ihrem Artikel 1 bindet sie eine aufgezählte Gruppe digitaler Anbieter direkt (DNS, Cloud, Rechenzentren, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Online-Marktplätze und weitere). Für die übrigen NIS2-Einrichtungen ist sie die konkrete Fassung, in der die Kommission selbst die Massnahmen nach Artikel 21(2) ausbuchstabiert.
Anhangspunkt 7.1 lautet: Die betreffenden Einrichtungen „legen … ein Konzept und Verfahren fest, setzen sie um und wenden sie an, um zu bewerten, ob die ergriffenen Risikomanagementmaßnahmen im Bereich der Cybersicherheit wirksam umgesetzt und aufrechterhalten werden.“ Ein Verfahren festzulegen und es anzuwenden sind dort getrennte Pflichten, in einem einzigen Satz.
Die Reaktion auf Sicherheitsvorfälle zeigt, wie sich die Trennung auswirkt:
Der technische Umsetzungsleitfaden der ENISA (Technical Implementation Guidance, Juni 2025, nicht verbindlich) führt unter jedem Punkt Beispiele für Nachweise auf. Unter 3.5.1 zeigen die Beispiele, dass das Verfahren existiert: zugewiesene Rollen, die Standards, auf die es sich stützt, und „Playbooks or incident response plans for common types of incidents“ (sinngemäss: Playbooks oder Reaktionspläne für häufige Arten von Sicherheitsvorfällen). Unter 3.5.5 erscheinen das Verfahren und seine Durchführungen gemeinsam: „Documented plans or schedules for future incident response tests“ (sinngemäss: dokumentierte Pläne oder Zeitpläne für künftige Tests der Vorfallreaktion) und „Records from tests of different types of incidents“ (sinngemäss: Aufzeichnungen von Tests zu verschiedenen Arten von Vorfällen). Der Zeitplan sagt, wann eine Durchführung fällig ist, und die Aufzeichnungen zeigen, dass jede einzelne stattgefunden hat.
Am meisten über Abweichungen sagt Punkt 6.4.3 zum Änderungsmanagement. Der Anhang rechnet damit, dass ein Verfahren hin und wieder nicht eingehalten wird, und verlangt auch dafür einen Nachweis:
„Konnten die regulären Änderungsmanagementverfahren aufgrund eines Notfalls nicht befolgt werden, dokumentieren die betreffenden Einrichtungen das Ergebnis der Änderung und die Begründung für die Nichteinhaltung der Verfahren.“
ENISAs Beispiele dazu umfassen „Logs and records of past change requests“ (sinngemäss: Logs und Aufzeichnungen vergangener Änderungsanträge) mit dem Grund für den Notfall, der Genehmigung, dem Grund für die Verzögerung und den Folgemassnahmen. Die Verordnung behandelt eine Abweichung mit schriftlicher Begründung als normalen Teil der Aufzeichnungen.
Zusammen gelesen ergeben die drei Texte fünf Eigenschaften, die jede Durchführung eines wiederkehrenden Verfahrens im Protokoll hinterlassen sollte:
| Das Durchführungsprotokoll zeigt | Warum | Grundlage |
|---|---|---|
| Die Schritte, wie sie an jenem Tag galten | Eine Durchführung wird an dem Verfahren gemessen, das galt, als sie stattfand. Hat sich das Verfahren seither geändert, sagt die heutige Fassung nichts über den März. | HS 7.5.3 „control of changes“; HS 8.1 „as planned“ |
| Wer welchen Schritt wann erledigt hat | Der Test umfasst die Person ebenso wie das Verfahren. | AS 2201 .44 |
| Was ausgelassen wurde und warum | Eine Abweichung mit Begründung lässt sich beurteilen. Eine ohne Aufzeichnung nicht. | AS 2201 .48; 2024/2690 6.4.3 |
| Auf welchen Fälligkeitstermin es antwortete | Ohne Zeitplan sehen Sie keine fehlende Durchführung, und eine Stichprobe braucht die vollständige Liste der Durchführungen im Zeitraum. | AS 2201 .52; ENISA unter 3.5.5 |
| Dass es seit der Ablage unverändert ist | Sonst zeigt das Protokoll nur, was heute darin steht, und der Prüfer hat keine Grundlage, sich darauf zu verlassen. | HS 7.5.3 „loss of integrity“ |
Nichts davon erfordert ein bestimmtes Tool. Ein Papierformular mit einer in der Fusszeile gedruckten Versionsnummer, Kürzeln neben jeder Zeile, einem Feld für Bemerkungen und einem nach Monaten sortierten Ordner erfüllt alle fünf. Das Problem beim Papier ist die Lücke zwischen den Durchführungen: Nichts verrät Ihnen, dass das Juni-Formular nie ausgefüllt wurde, bis jemand den Ordner durchzählt.
Eine Gewohnheit würde ich ganz aufgeben: die leere Vorlage als Nachweis für ein wiederkehrendes Control beizulegen. Sie beantwortet 7.5.3 und sagt nichts zu 8.1.
devguard hat Prozesse am 22. September 2026 mit App 2.3.0 veröffentlicht.
Ein Prozess ist entweder eine Checkliste, die jemand abarbeitet, oder ein Meldeformular, das jemand einreicht, wenn etwas passiert. Durchgeführt werden sie im Mitarbeiterportal. Jede Durchführung behält ihre eigene Kopie der Schritte, wie sie zu Beginn galten, sodass eine spätere Änderung am Prozess keine eingereichte Durchführung verändert. Jede Zeile der Checkliste hält fest, wer sie abgehakt hat und wann, dazu eine optionale Notiz, und eine Kollegin oder ein Kollege kann eine offene Checkliste übernehmen und abschliessen. Ist eine Checkliste eingereicht, lässt sie sich nicht mehr bearbeiten, und die verantwortliche Rolle wird benachrichtigt, mit der Angabe, wie viele Zeilen abgehakt wurden. Eine einzelne Durchführung lässt sich mit einem Nachweis und über diesen mit Controls verknüpfen oder als PDF exportieren, das jede Zeile mit Person und Zeitpunkt des Abhakens auflistet, entnommen aus der eigenen Kopie der Schritte dieser Durchführung.
Wiederkehrende Checklisten erscheinen unter Fristen. Wird eine fällig oder überfällig, werden die Personen benachrichtigt, die sie durchführen, oder die verantwortliche Rolle, wenn alle sie durchführen dürfen. Meldeformulare können Felder als erforderlich markieren und eine Meldung ohne sie zurückweisen. Eine eingereichte Meldung durchläuft die Status Eingereicht, Wird bearbeitet und Behoben, und wer eine behobene Meldung bearbeiten will, muss sie ausdrücklich entsperren, was in der Timeline der Durchführung festgehalten wird.
Drei Dinge fehlen bewusst, und jedes hat seinen Preis.
Erstens versioniert und genehmigt die App das Verfahren selbst nicht. Die Versionsnummer ist ein Freitextfeld, das Sie pflegen, und für die Schritte gibt es keinen Genehmigungsablauf. Die eigene Kopie jeder Durchführung beantwortet die Frage, welche Schritte an jenem Tag galten. Die Änderungshistorie und die Freigabe des Verfahrens selbst gehören in Ihren Richtlinien- oder Aufzeichnungsprozess.
Zweitens hat eine eingereichte Checkliste keinen Prüfschritt. Sie ist mit dem Einreichen abgeschlossen. Eine Checkliste lässt sich auch mit nicht abgehakten Zeilen einreichen, und die verantwortliche Rolle sieht die Anzahl. Verlangt Ihr Control, dass eine zweite Person jede Durchführung prüft, wird diese Prüfung hier nicht erfasst.
Drittens richtet sich der Fälligkeitstermin nach der Arbeit. Der nächste Termin wird ab dem Abschluss der letzten Durchführung berechnet, sodass eine verspätete Durchführung nicht alle folgenden Zyklen zusammenstaucht. Der Preis ist, dass sich die Termine verschieben: Sagt Ihr Control „in jedem Kalendermonat“, prüfen Sie die Daten selbst. Wer die Rolle Eigentümer oder Admin hat, kann zudem eine Einreichung löschen, samt Antworten und Verlauf; legen Sie also fest, wer diese Rollen innehat.
Wählen Sie vor Ihrem nächsten Audit ein Control, das Ihr Team mit „das machen wir jeden Monat“ beschreibt, und versuchen Sie, seine letzten drei Durchführungen vorzulegen. Für jede brauchen Sie die Schritte, wie sie an jenem Tag geschrieben standen, wer welchen erledigt hat und was ausgelassen wurde und warum.
Mit den Prozessen von devguard laufen Checklisten und Meldeformulare im Mitarbeiterportal, und jede Durchführung wird als datierte Aufzeichnung abgelegt; Einzelheiten 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.