6.3. Verständnis des Auditprozesses – Teil 2

Der zweite Teil dieses Abschnitts befasst sich mit dem eigentlichen Auditprozess: wie wird ein Audit geplant, durchgeführt und dokumentiert?

Audit-Planung

Verständlicherweise muss der gesamte Auditprozess sorgfältig geplant sein, um aussagekräftige und verwertbare Ergebnisse zu erzielen. Ein Audit durchläuft dabei mehrere Phasen. Die sechs Phasen nach ISO 19011 sind:

  • Initiierung des Audits – Kontaktaufnahme, Durchführbarkeit prüfen
  • Vorbereitung der Audit-Aktivitäten – Dokumentenprüfung, Audit-Plan erstellen
  • Durchführung des Audits – Fieldwork, Interviews, Evidenzsammlung
  • Erstellung des Audit-Berichts – Dokumentation der Ergebnisse und Empfehlungen
  • Abschluss des Audits – formale Übergabe und Abschluss
  • Follow-up – Nachverfolgung der Umsetzung von Maßnahmen

Die Planungsphase lässt sich grob in vier Schritte untergliedern. Wobei es sich nicht um eine feste Reihenfolge handelt, sondern um gängige Best Practices. In der Praxis ist dies ein kollaborativer Prozess, bei dem Kunde und Auditoren eng zusammenarbeiten.

  • Audit Scope Statement erstellen: Dabei werden die zu prüfende Systeme, Anwendungen und Prozesse sowie die auszuschließenden Bereiche definiert.
  • Ziele und Anforderungen festlegen: Welche Risiken oder Compliance-Bereiche sollen bewertet werden?
  • Auditoren auswählen: Nur qualifizierte und unabhängige Auditoren gewährleisten objektive Ergebnisse.
  • Readiness Assessment/Gap-Analyse durchführen: Mögliche Problemfelder werden frühzeitig erkannt, um negative Auditbefunde zu vermeiden.

Information Security Management System (ISMS)

Ein Information Security Management System (ISMS) ist ein strukturierter, organisatorischer Rahmen, um Informationssicherheitsrisiken zu identifizieren, zu bewerten und zu steuern. Ein ISMS ist kein einzelnes technisches Produkt oder Tool.

ISO/IEC 27001 definiert die Anforderungen für ein ISMS und macht es zertifizierbar. Wenn eine Organisation eine ISO-27001-Zertifizierung anstrebt, prüfen Auditoren ob:

  • ein strukturiertes ISMS eingerichtet wurde,
  • die Anforderungen der Norm umgesetzt sind,
  • Sicherheitsrisiken systematisch gemanagt werden,
  • Prozesse zur kontinuierlichen Verbesserung existieren.

Zentrale Elemente eines ISMS

Ein ISMS umfasst typischerweise folgende organisatorische Komponenten:

Sicherheitsrichtlinien – dokumentierte Regeln und Vorgaben zum Umgang mit Informationen.

Risikomanagement – Identifikation, Bewertung und Behandlung von Sicherheitsrisiken.

Sicherheitskontrollen – technische und organisatorische Maßnahmen zur Risikominderung.

Rollen und Verantwortlichkeiten – klare Zuordnung von Zuständigkeiten für Sicherheitsprozesse.

Audits und Monitoring – regelmäßige Überprüfung der Wirksamkeit der Sicherheitsmaßnahmen. 

Kontinuierliche Verbesserung – Weiterentwicklung des ISMS auf Basis von Audit-Ergebnissen und sich ändernden Risiken, umgesetzt nach dem PDCA-Zyklus (Plan-Do-Check-Act).

    • Plan – Risiken analysieren und Maßnahmen definieren
    • Do – Sicherheitsmaßnahmen implementieren
    • Check – Wirksamkeit überprüfen
    • Act – Prozesse verbessern und anpassen

Dadurch wird Informationssicherheit als fortlaufender Prozess verstanden und nicht als einmalige Implementierung.

Internal Information Security Controls System

Es handelt sich dabei nicht um einen offiziellen Begriff, sondern um die Gesamtheit aller internen Sicherheitskontrollen einer Organisation – also alle technischen und organisatorischen Maßnahmen, die intern eingeführt wurden, um Sicherheitsrisiken zu adressieren. Damit bildet es die konkrete Umsetzungsebene innerhalb eines ISMS.

Im CCSP-Kontext bedeutet das konkret:

Intern bedeutet, dass die Anforderungen von der Organisation selbst definiert und umgesetzt werden (im Gegensatz zu externen Anforderungen wie Gesetzen oder Standards).

Controls bezeichnet konkrete Maßnahmen wie Zugriffskontrolle, Verschlüsselung, Logging, Patch-Management usw.

Das System besteht nicht aus isolierten Maßnahmen, sondern ist als zusammenhängendes, strukturiertes Regelwerk organisiert.

Richtlinien

Wenn ich das Wort „Richtlinien” höre, denke ich direkt an Microsoft GPOs. Die Richtlinien (Policies) im CCSP-Kontext sind die obersten Handlungsanweisungen für alle Mitarbeitenden und Systeme. Sie beschreiben vor allem, was in welcher Situation zu tun ist. Somit bilden sie das Fundament jeder Sicherheits- und Compliance-Strategie. In den Richtlinien wird festgelegt, wie eine Organisation ihre Informationssicherheit, Datenverwaltung und Risikosteuerung gestaltet, um Risiken wie finanzielle Verluste, Datenschutzverletzungen oder Reputationsschäden zu minimieren.

An der Entwicklung, Implementierung und Einhaltung von Richtlinien sind normalerweise mehrere Gruppen beteiligt, z. B.:

  • Unternehmensführung: gibt strategische Richtung und Genehmigung.
  • Mitarbeitende und Nutzer: setzen Richtlinien im Alltag um.
  • IT- und Sicherheitsteams: Sie definieren technische Kontrollen.
  • Compliance- und Rechtsabteilung: sorgt für eine gesetzeskonforme Umsetzung.

Arten von Richtlinien

Richtlinien lassen sich in drei Hauptkategorien unterteilen:

Organisatorische Richtlinien – legen Verhaltensstandards und interne Regeln fest, damit alle Mitarbeitenden die Werte und Sicherheitsziele des Unternehmens verstehen und einhalten. Sie helfen, Risiken wie finanzielle Verluste, Non-Compliance oder Reputationsschäden zu vermeiden. Mein Lieblingsbeispiel sind die Social-Media-Guidelines.

Funktionale Richtlinien – regeln Verfahren für den sicheren Umgang mit Systemen und Daten. Typische Beispiele sind Nutzungsrichtlinien (Acceptable Use Policy), Richtlinien zur Datenspeicherung oder Passwortverwaltung. Sie verfolgen ein klares Ziel: ein einheitliches Verständnis zu etablieren, wie Systeme genutzt werden dürfen und wie Sicherheits- und Compliance-Vorgaben einzuhalten sind.

Cloud-Computing-Richtlinien – speziell auf die Nutzung, Sicherheit und Verwaltung von Cloud-Diensten ausgerichtet. Sie definieren z. B. welche Cloud-Dienste überhaupt genutzt werden dürfen (Approved Services), wo Daten gespeichert werden müssen (Datensouveränität) und wie der Zugriff auf Cloud-Ressourcen kontrolliert wird.  Darüber hinaus definieren sie die geltenden Verschlüsselungsanforderungen. Damit schließen sie die Lücke zwischen allgemeinen Sicherheitsrichtlinien und den spezifischen Anforderungen einer Cloud-Umgebung.

Identifizierung und Einbeziehung relevanter Interessengruppen

Dieser Punkt ist nicht nur für Audit- und Compliance-Prozesse relevant – alle Projekte können nur erfolgreich sein, wenn relevante Stakeholder frühzeitig identifiziert und eingebunden werden. An der Entwicklung, Implementierung und Einhaltung von Richtlinien sind typischerweise mehrere Gruppen beteiligt:

  • die Unternehmensführung, die für strategische Richtung und Genehmigung verantwortlich ist,
  • IT- und Sicherheitsteams, die technische Kontrollen definieren,
  • die Compliance- und Rechtsabteilung, die für gesetzeskonforme Umsetzung sorgt,
  • sowie die Mitarbeitenden, die Richtlinien im Alltag umsetzen.

Spezielle Compliance-Anforderungen für stark regulierte Branchen

Wie bereits bekannt, unterliegen einige Branchen nicht nur allgemeinen, sondern auch branchenspezifischen Anforderungen, die weit über gesetzliche Normen hinausgehen. Die regulatorischen Rahmenwerke für Branchen wie Gesundheitswesen, Finanzwesen oder Energieversorgung sind bereits oben erläutert.

Im aktuellen Kontext ist es wichtig, das Konzept der Shared Responsibility immer im Blick zu behalten: Die Verantwortung für Compliance liegt immer beim Cloud-Kunden – der Cloud Service Provider stellt je nach Modell nur die technische Grundlage bereit.

Auswirkungen des Modells der verteilten IT

Eine verteilte Cloud-Infrastruktur, die sich über mehrere geografischen Standorte erstreckt, führt zu einer zusätzlichen Komplexitätsebene. Daten können gleichzeitig verschiedenen nationalen Rechtssystemen unterliegen, was in bestimmten Konstellationen zu widersprüchlichen Anforderungen führen kann, wie im Abschnitt „Widersprüchliche internationale Rechtsvorschriften” bereits erläutert.