audit.planeth

Autor: Thorsten Planeth

  • 23.08.2026 – GRCA.PLANETH – Wo stehen wir?

    Ich bin jetzt etwa seit einem halben Jahr dabei, GRCA.PLANETH.DE aufzusetzen. Jetzt ist es mal Zeit zu schauen, wo wir stehen.

    Aktueller Stand

    System

    Das System selbst läuft stabil. Die Objekte stehen in festen Beziehungen. Technisch habe ich bereits Labels realisiert, um die Sourcen besser zu strukturieren.

    Ein Feature funktioniert bereits in der Entwicklung: Wir können eine Regulierung nehmen und schauen, wie sie sich in den einzeln Standards wiederfindet. Es funktioniert auch schon als angemeldeter Benutzer. Dauert jedoch die Zusammenstellung zu lange, bricht der Webserver ab. D.h. auf der Webseite kann man nur für kleinere Regelungen / oder Abschnitte die Analyse erstellen lassen.

    Technisch sehe ich derzeit keine Notwendigkeit, etwas anzupassen.

    Sourcen

    Die Sourcen habe hier aufgelistet. Einen Großteil der Sourcen habe ich automatisiert eingelesen. Hier ist mein Ziel, dass ich regelmäßig ein Update-Script laufen lasse und dann die Sourcen automatisiert aktualisiert werden. Dies habe ich bereits bei den deutschen Gesetzen realisiert. Als nächstes werde ich es bei den EU-Gesetzen umsetzen.

    Sowohl bei den europäischen als auch bei den deutschen Gesetzen muss ich bei dem automatischen Import noch einmal ran: Artikel werden korrekt importiert, ein Import der einzelnen Absätzen erscheint jedoch sinnvoll. Das habe ich noch nicht realisert. Dies ist auch der einzige Grund, warum die DORA noch separat aufgeführt sind.

    Gesamtheit der Sourcen

    Mit der Aufstellung der Sourcen habe ich aktuell den Eindruck, dass ich die Wünsche eines IT-Revisors abdecke. Sollte etwas fehlen, speziell aus der deutschen oder europäischen Regulatorik, so bin wäre ich für einen Hinweis dankbar.

    Sowohl von der CSA für das CCM als auch von der ISACA für COBIT habe ich zwei Statements, dass ich die Frameworks einbinden dürfte. Sobald ich alle anderen Themen umgesetzt habe, nehme ich mich dem gerne an.

    Verknüpfung der Sourcen

    Das Secure Controls Framework nimmt an dieser Stelle eine besondere Rolle ein, da eine Verknüpfungsmatrix zu diversen Standards gibt. Ich habe bereits angefangen, diese einzulesen. Das Ergebnis sieht man bereits auf der Webseite…

    Mein Ziel

    Mein großes Ziel ist, eine Plattform zu schaffen, auf der IT-Revisoren alle frei verfügbaren Sourcen aufrufen können und Auslegungshinweise erhalten. Oder, wenn sie Prüfungen durchführen sollen, Hinweise zu relevanten Anforderungen erhalten. Im Idealfall würde man bereits vorbereite Prüfungskonzepte erhalten.

    Hier ist die Frage wo wir stehen?

    • Sourcen eingebunden – erledigt
    • Sourcen in relevante Anforderungen zerlegt – teilweise erledigt
    • Einheitliche Prüfungsobjekte geformt und relvante Sourcen zugeordnet- offen

    M.E. beginnt jetzt der aufwendige Schritt. Jetzt gilt es, die anhand von Prüfungsobjekten die externen Anforderungen zu untersuchen und Requirements abzuleiten. Das wird jetzt sukzessive geschehen.

    Diesen Teil werde ich jedoch nicht mehr frei veröffentlichen. Ich bin an Mitarbeit interessiert. Soll heißen – wer etwas beisteuert, erhält auch Zugriff. Wer nichts beisteuert bleibt draußen.

  • Deutsche Gesetze – stets aktuell

    Deutsche Gesetze – stets aktuell

    Mittlerweile bin ich in der Lage, die Deutschen Gesetze automatisch einzulesen. Im Moment habe ich die für die deutsche Finanzindustrie relevanten Gesetze eingelesen:

    Fehlt Euch etwas? Es ist kein Aufwand weitere Gesetze zu ergänzen.

    Mit jedem „Lauf“ findet auch ein Update statt. D.h. wenn es einen neuen Build gibt, wird dieser direkt importiert.

    Aktuell hadere ich noch damit, wie ich mit Löschungen umgehen soll. Sollen sie sichtbar bleiben, oder direkt aus der Datenbank gelöscht werden? (Ich muss noch programmieren, dass der Status aktualisiert wird und damit der Eintrag als ungültig markiert wird…)

    Gleiches gilt für Änderungen. Aktuell lasse ich die Verknüpfungen und ändere lediglich den Text. Hat das Nachteile? Klar, aber vorerst ist das das Einfachste, sorry!

  • Blocked By Analyse – Mapping von Regulation

    Mittlerweile habe ich diverse Sourcen eingebunden. Um adhoc eine Gap-Analyse für eine bestimmte Regulierung zu erhalten, habe ich die Blocked By Analyse erstellt:

    In dem Beispiel (https://grca.planeth.de/de/grcaplaneth/issue/3816/mappingblockedby/) werden der DORA alle zugeordneten Standards gegenübergestellt.

    Einen Nachteil der aktuellen Implementierung möchte ich nennen:

    Bei jedem Aufruf wird die Aufstellung neu zusammengestellt. Bei hunderten von Einträgen wie bei der DORA kann es dann schon einmal etwas länger dauern – 2 Minuten, bis die Seite geladen ist.

    Dafür ist sie aber auch stets aktuell.

    Die Ansicht kann übrigens aus jeder Regulierung aufgerufen werden, wenn man angemeldet ist. Sie verbirgt sich direkt unter der Überschrift einer Regulation unter „Blocked By Analysis“

  • Neue MaRisk-Novelle veröffentlicht

    Neue MaRisk-Novelle veröffentlicht

    Am 30.06.2026 hat die Bafin das Rundschreiben 06/2026 (BA) Mindestanforderungen an das Risikomanagement (MaRisk) veröffentlicht. Ich habe das Rundschreiben ebenfalls auf grca.planeth eingebunden (https://grca.planeth.de/de/grcaplaneth/opensource/issue/8345).

    Was ändert sich für uns IT-Revisoren?

    Ich sehe für uns folgende relevante Änderungen:

    • AT 7.2 wird von dem Digital Operational Resilience Act „gefressen“. D.h. die Bibel (den DORA-Dokumenten) erlaubt es, dass alle Passagen bis auf zwei relevante Statements gestrichen werden können:
      • Angemessene Ausstattung
        „Umfang und Qualität der technisch-organisatorischen Ausstattung sind an den internen Erfordernissen, den Geschäftsaktivitäten sowie der Risikosituation auszurichten.“ AT 7.2 Tz. 1
        „Für die Generierung von Daten und Informationen zu wesentlichen Risikoarten sind angemessene technische und organisatorische Kapazitäten vorzuhalten.“ AT 7.2 Tz. 2
      • Datagovernance für Risikodaten
        „Zudem sind effektive Prozesse zur Sicherstellung der Datenqualität einzurichten, die eine korrekte und vollständige Erfassung und Darstellung der wesentlichen Risikokomponenten ermöglichen.“ AT 7.2 Tz. 2
    • AT 9 berücksichtigt DORA in der Form, dass entweder DORA (bei ICT-Services) oder AT 9 anzuwenden ist, aber nicht mehr beides. (vgl. hierzu AT 9 Tz.1 Erläuterung:
      „Ausgelagerte oder fremdbezogene IKT-Dienstleistungen gemäß Art. 3 Nr. 21 DORA, die dem IKT-Drittparteienrisikomanagement gemäß Art. 28-30 DORA unterliegen, fallen nicht in den Anwendungsbereich des AT 9.“)
    • AT 7.3 wurde zwar angepasst, ist jedoch bereits in DORA für die IT-Revision ausreichend geregelt…

    Was ist mir noch aufgefallen?

    • Wir schreiben das Jahr 2026
    • Digitalisierung bedeutet, dass Daten in einer strukturierten Form erfasst, gespeichert und weitergegeben werden.
    • Mittlerweile etablieren sich als State-Of-The-Art zur Formatierung von regulatorischen Texten:
    • Was liefert ein deutscher Regulator? PDF

    Im Zeitalter der Inklusion ist es wenig erfreulich, dass das Format „nicht barrierefrei“ ist. Man könnte auch sagen, dass es schwer maschinenlesbar ist.

    Für die Zukunft wünsche ich mir, dass auch Behörden an „ihre“ Kunden denken. Ihre zentralen Dokumente werden nicht nur einmal gelesen, gelöchert und abgelegt, sondern heutzutage in allerhand Tools verarbeitet. Wenn wir an dieser Stelle Aufwand bei den Unternehmen dadurch senken, dass kein Mensch 3 Stunden die Texte kopiert und formatiert, damit sie weiterverarbeitet werden könne, kann der Bürokratieabbau in Deutschland auch spürbar werden :-).

  • Labels fertig

    In der Zwischenzeit habe ich Labels eingeführt.

    Wozu sind diese gut?

    Wir wollen Objekte von fremden Sourcen kategorisieren? Dann können wir uns Labels (Stichworte) anlegen und die Objekte mit den Labels markieren. Über den Label kann auf die so markierten Objekte direkt zugreifen. Denkbare Labelarten sind:

    • Bearbeitungsfortschritte
    • Bedeutung / Wichtigkeit
    • Thematisch

    Wie gehe ich vor?

    1. In meinem Workspace oder Source lege ich die Labels an (siehe Bild oben)
    2. Über die hierarchische Organisation kann ich Statistiken erstellen. Hierzu erstelle ich ein abstraktes Oberlabel und ordne diesem die Unterlabels zu. Sobald dies geschehen ist, kann man im Oberlabel bereits Statistiken zu den Unterlabels sehen.

    3. Anschließend können wir jedes Objekt öffnen und eines der erstellten Labels zuweisen:

    Fazit

    Dies ermöglicht eine interne Organisation nach belieben – auch von „fremden“ Sourcen, bei denen man nur Leserechte hat.

  • BSI veröffentlicht C3A – Criteria enabling Cloud Computing Autonomy

    Unter C3A hat das BSI den C3A – Criteria enabling Cloud Computing Autonomy veröffentlicht. Ich habe ihn in das https://grca.planeth.de unter https://grca.planeth.de/de/grcaplaneth/opensource/source/26/ integriert.

  • Cloud Computing Compliance Criteria Catalogue (C5:2026)

    Cloud Computing Compliance Criteria Catalogue (C5:2026)

    Die Version 2026 des Cloud Computing Compliance Criteria Catalogue (C5:2026) wurde vor kurzem vom Bundesamt für Sicherheit in der Informationstechnik veröffentlicht. Erfreulicherweise wurde eine maschinenlesbare Version in Form von YML-Dateien veröffentlicht.

    Heute habe ich diese auf grca.planeth.de importiert. Begehbar ist diese unter https://grca.planeth.de/de/grcaplaneth/opensource/source/24/

    Bei dem Import sind mir zwei Dinge aufgefallen:

    • Die Datei GC weicht von den übrigen in Bezug auf den Identifier / ID ab. Ebenfalls sind die Items anders strukturiert.
    • Zwei weitere Dateien hatten in den Identifiern marginale Fehler, die der Parser aufgeworfen hatte und leicht zu beheben waren.

    Insgesamt wäre es wünschenswert, wenn sich eine einheitliche Beschreibungssprache entwickeln würde.

  • Wie kommen die Daten in das GRCA-Tool?

    Solltet Ihr Euch fragen, wie ich die externen Anforderungen importieren kann, so kann ich Einblicke gewähren:

    1. Manuell
      Wenn nichts geht, muss ich manuell die Daten übertragen. Dann kopiert man aus einer PDF-Datei die Texte manuell in eine Tabelle und überträgt diese in die Plattform. Bringt es Spaß? Nein, das möchte ich Euch ersparen!
    2. Automatisch über OSCAL
      Es gibt von der NIST die Open Security Controls Assessment Language. Mit einem Interpreter kann man die Daten charmant importieren. Ein erster – nicht perfekter – Interpreter ist fertig. Ich arbeite dran!
    3. Automatisch über YML-Dateien
      Das BSI hat YML-Dateien angeboten. Das ist top! Damit kann man die Daten einfach und schnell importieren.
    4. Automatisch über XML-Dateien
      Das Bundesjustizministerium stellt die Gesetze als XML-Datei bereit. Ebenfalls top! Ein Import ist rasch möglich!

    Müsst Ihr einen Interpreter für die jeweiligen Datenquellen bauen? Ja – kann man machen!

    Oder Nein! Es muss nur einer die Daten in ein einheitliches Format bringen, so dass man die Daten wieder woanders importieren kann.

    Ihr seht: Der Vorteil einer gemeinsamen Plattform beginnt bereits, ehe die große Zusammenarbeit startet!

  • DORA in Control Framework

    DORA in Control Framework

    Von NOREA, de beroepsorganisatie van IT-auditors habe ich das DORA in Control Framework in das grca.planeth integrieren dürfen. Vielen Dank dafür!:

    Das Control Framework organisiert DORA in 95 Controls:

    Jedem Control sind die jeweiligen DORA-Artikel zugeordnet:

    Hier ist der Link zum DORA Control Framework in grca.planeth

  • grca.planeth.de: POC gestartet

    Mit diesem Blog möchte ich Euch an dem Fortschritt von grca.planeth.de teilhaben lassen. Es ist rein privat. Es hat weder mit meinem Arbeitgeber noch mit den Workshops und Verbänden zu tun, in denen ich tätig war oder bin.

    Was ist grca.planeth.de? – Warum sehe ich nichts?

    grca.planeth.de steht für

    • G overnance
    • R isk
    • C ompliance
    • A udit

    und ist von mir, Thorsten Planeth, erstellt – daher grca.planeth.de!

    Es richtet sich ausschließlich an Revisorinnen und Revisoren und soll dem Austausch dienen. Daher sind Zugangsdaten erforderlich. Und es befindet sich erst im Aufbau!

    Mein Ziel

    Ich möchte gerne Arbeit sparen:

    Wenn ich die externen Anforderungen, relevanten Standards und Risiken zu einem Audit Object zusammengetragen habe, wieso kann ein anderer Revisor dieses nicht nutzen?

    Und umgekehrt?

    Und hier fängt grca.planeth.de an!

    Ich möchte mit Euch externe Anforderungen mit Euch zerlegen und mit frei zugänglichen Standards verbinden.

    Am Ende sollten Audit Objekte herauskommen, die jeder verwenden kann.

    Was ist bisher passiert?

    • Ich habe dieses WordPress-Blog aufgesetzt, um einfach eine Hilfe aufzusetzen.
    • https://grca.planeth.de ist live gegangen. Es ist eine eigene Anwendung auf einem eigenen Server.