Schritt 1: Einheitliche Governance in iTop

Der erste Schritt vom CMDB- zum Audit-Werkzeug: Mit einer einheitlichen Governance-Struktur werden Verantwortlichkeiten und regelmäßige Reviews direkt mit den vorhandenen iTop-Objekten verbunden – als Grundlage für nachvollziehbare und später automatisierbare Audit-Dokumentation.

Im ersten Teil meines Projekts geht es bewusst noch nicht um Risiken, Controls oder umfangreiche ISO-Strukturen.

Der erste Schritt ist wesentlich grundlegender:

Für die bereits vorhandenen Informationen in iTop sollen Verantwortlichkeiten und regelmäßige Reviews einheitlich abgebildet werden.

Warum mit Governance beginnen?

In einer gut gepflegten CMDB befinden sich bereits viele wertvolle Informationen. Server, Anwendungen, Software, Netzwerkkomponenten, Standorte oder Geschäftsprozesse sind dokumentiert und teilweise sogar automatisiert gepflegt.

Für eine nachvollziehbare Dokumentation fehlen jedoch häufig zwei einfache Antworten:

Wer ist dafür verantwortlich?

und

Wann wurde zuletzt geprüft, ob diese Information noch aktuell und korrekt ist?

Genau hier setzt die Governance-Erweiterung an.

Eine gemeinsame Struktur

Statt für Server, Anwendungen, Software oder andere Objekte jeweils eigene Lösungen zu entwickeln, möchte ich eine möglichst einheitliche Struktur verwenden.

Dafür erhalten relevante Objekte einen gemeinsamen Bereich „Governance“ mit wenigen zentralen Angaben:

• Owner
• Verantwortliche Person
• Review erforderlich
• Review-Intervall
• Letztes Review
• Nächstes Review
• Review-Status

Die bereits vorhandene Kritikalität eines Objekts bleibt davon unabhängig bestehen.

Damit erhält beispielsweise ein Server neben seinen technischen Informationen zusätzlich einen klaren organisatorischen Kontext.

Reviews statt nur Daten pflegen

Ein Review bedeutet dabei nicht, dass regelmäßig sämtliche Informationen manuell neu eingegeben werden müssen.

Viele technische Daten können bereits automatisiert in iTop einfließen und aktuell gehalten werden.

Beim Review geht es vielmehr darum zu bestätigen:

Ist das Objekt noch erforderlich, stimmen Verantwortlichkeiten und Beziehungen und entspricht die Dokumentation noch der Realität?

Vom Review-Termin zum dokumentierten Vorgang

Für den Ablauf kann ich auf bereits vorhandene Funktionen in iTop und meine Checklist-Erweiterung zurückgreifen.

Sobald das Datum für ein Review erreicht ist, greift die vorhandene Triggerlogik in iTop. Automatisch wird ein entsprechendes Ticket erstellt und mit dem zu prüfenden Objekt verknüpft.

An dieses Ticket wird die passende Review-Checkliste angehängt. Je nach Objekt können dadurch unterschiedliche Punkte geprüft werden – beispielsweise bei einem Server andere als bei einer Anwendung oder einem VPN.

Der Ablauf bleibt damit einfach:

Review-Datum erreicht → Trigger → Ticket wird automatisch erstellt → passende Checkliste → Review durchführen → Ticket abschließen

Das Ticket dokumentiert gleichzeitig, wann der Review durchgeführt wurde, wer beteiligt war und welche Prüfungen erfolgt sind.

So wird aus einem einfachen Review-Datum ein nachvollziehbarer und weitgehend automatisierter Prozess.

Wie geht es weiter?

Damit steht der erste Baustein des Projekts.

Im nächsten Schritt geht es um die Verbindung von Geschäftsprozessen, Anwendungen und der vorhandenen IT-Landschaft.