Ich wurde gefragt, wie ich mit der steigenden Komplexität in der IT umgehe, um weiterhin eine angemessene Audit-Assurance zu erreichen. Das, finde ich, ist eine gute Frage, die ich gerne hier beantworte:
In dem komplexen System stellt sich mir die Frage, wie Audit-Assurance entsteht.
Soll ich das einzelne System prüfen oder den Prozess?
Wenn ich das einzelne System prüfe, weiß ich, dass dieses System jetzt sicher ist. Aber wie ist es morgen? Also sind mir die Prozesse wichtiger. Wenn ich weiß, dass der Prozess funktioniert, dann sollten die betreuten Systeme doch sicher sein, oder? Hier sollten wir uns die Prozessziele genau anschauen. Beinhalten sie auch die Reduzierung von Risiken und die Einhaltung von externen Anforderungen? Jetzt nähern wir uns dem Ergebnis eines Prozesses. Jede Requirement muss erfüllt sein, damit der Prozess gut ist.
Soll ich die Kontrolle oder den Prozess prüfen?
Ist es nicht das Gleiche? Sichern wir nicht die wichtigen Requirements mit Kontrollen ab, so dass diese Requirements die Kontrollziele sind? Mich interessiert nicht, ob jemand ein Häckchen gemacht hat. Wenn jemand das mit nur einem bürokratischen Schritt dokumentiert, aber das wichtige Requirement nicht erfüllt ist, sieht es auf dem Papier gut aus, aber…
Woher weiß ich denn, welche Requirement wichtig ist?
Zumindest IT-Revisoren in der Finanzindustrie haben dafür eine sehr gute „Anleitung“: Wir sollen risikoorientiert prüfen. Da sich die Geprüften an gängigen Standards ausrichten sollen, können wir diese neben den externen Anforderungen heranziehen. Damit können wir situativ die wichtigen Requirements eines Prüfungsobjektes bestimmen.
Jetzt haben wir übrigens die Bausteine eines GRCA-Tools aus Sicht eines Revisors beschrieben.
Einen Aspekt haben wir bisher nicht angesprochen, der spätestens mit DORA umgesetzt sein muss. Neben der Revision muss auch die erste bzw. zweite Verteidigungslinie die Umsetzung ihrer Regelungen überwachen. D.h. auf diesen Erkenntnissen können wir aufbauen. Ich stelle in Frage, ob wir weiter prüfen müssen, wenn beide Verteidigungslinien diesbezüglich ihre Hausaufgaben nicht gemacht haben. Umgekehrt stellt eine gute Überwachung durch erste und zweite Verteidigungslinie sicher, dass auch zwischen zwei Prüfungen die Requirements eingehalten werden.
Die alte Schule der Stichprobe
Um eine Requirement zu überprüfen, machen wir es so wie die Wirtschaftsprüfer: wir ziehen eine Stichprobe. 1000 Systeme im Betrieb – eine Stichprobe von 30 sollte ausreichen, um zu validieren, dass die Requirement eingehalten ist. Sieht gut aus – alle 30 Systeme sind gepatcht. Blöd nur, dass bei den anderen Systemen ein schwieriger Kandidat ist, der leider veraltet ist und demnächst befallen wird. Meine Lehre daraus: wenn es darauf ankommt, ist eine Stichprobe ungeeignet. Wir sollten dann sicherstellen, dass die ersten und zweiten Verteidigungslinien alles vollständig im Griff haben.
Prüfungsübergreifend
Jede Prüfung ist für mich wie ein kleines Puzzlestück. Es sieht bereits gut aus. Schaue ich jedoch mit etwas Abstand auf alle Puzzlestücke, sehe ich das ganze Bild. Vielleicht sehe ich ich dann, dass zwar jedes einzelne Stück einigermaßen gut aussah, das Gesamtbild jedoch einen kleinen Farbstich in einem bestimmten Bereich des Bildes aufweist. Oder wir sehen, dass einzelnen Bereichen Puzzlestücke fehlen.
Jetzt, glaube ich, haben wir eine gute Audit-Assurance auch bei einer steigenden Komplexität in der IT hergestellt.
Sollte jemand einwenden, dass dieser Ansatz zu aufwendig ist, so kann ich dies bejahen, wenn man keine technische Unterstützung hätte…
