audit.planeth

Blog

  • 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.