IT-Sicherheitsaudit im Jahr 2026: Umfang, Methodik, Nachweise und rechtliche Anforderungen

Audit, Sicherheitsbewertung, Schwachstellenscan und Penetrationstest sind nicht dasselbe

In der Praxis werden diese Begriffe häufig synonym verwendet, insbesondere in Ausschreibungen und Angeboten. Das führt zu Missverständnissen, weil jede dieser Untersuchungsformen eine andere Frage beantwortet und andere Nachweise liefert.

Ein Audit bewertet den Prüfgegenstand anhand festgelegter Kriterien. Ein Kriterium kann eine Rechtsvorschrift, eine Normanforderung, ein Vertrag, eine interne Richtlinie, ein genehmigter Konfigurationsstandard oder eine präzise bezeichnete Kombination dieser Grundlagen sein. Ein Audit umfasst Planung, Stichprobenauswahl, Erhebung und Bewertung von Nachweisen, Formulierung von Feststellungen und Berichterstattung. Gegenstand kann ein Managementsystem, ein Prozess, ein Dienst oder ein bestimmtes Informationssystem sein.

Eine Sicherheitsbewertung verfolgt häufig ein stärker diagnostisches Ziel. Sie kann die Gestaltung von Sicherheitsmaßnahmen, Konfigurationen, Widerstandsfähigkeit oder Wirksamkeit von Kontrollen untersuchen, ohne eine formale Konformitätsaussage abzugeben. NIST SP 800-53A Rev. 5 enthält in der Fassung mit Release 5.2.0 vom 27. August 2025 anpassbare Verfahren zur Bewertung von Sicherheits- und Datenschutzkontrollen.^[4] Daraus entsteht jedoch keine eigenständige Rechtspflicht in Polen.

Schwachstellenscans dienen der systematischen Erkennung bestimmter Klassen bekannter Schwachstellen und Fehlkonfigurationen. Ein Scannergebnis ist noch keine Auditfeststellung. Es ist zu prüfen, ob die Schwachstelle tatsächlich vorliegt, wie exponiert das System ist, ob kompensierende Maßnahmen bestehen und welche Bedeutung das Problem im konkreten Organisationskontext hat.

Ein Penetrationstest untersucht, ob vereinbarte Angriffsszenarien praktisch umgesetzt werden können und welche Folgen ihre Ausnutzung haben kann. Er erfordert eine eindeutige Autorisierung, Testregeln, einen definierten Umfang, zulässige Techniken, Zeitfenster, einen Notfallkontakt und Regeln für den Fall einer Störung. NIST SP 800-115 bleibt ein nützlicher Leitfaden zu technischen Testmethoden und ihren Grenzen.^[12]

Diese Untersuchungen können sich ergänzen. Ein IT-Sicherheitsaudit kann feststellen, ob eine Organisation einen Prozess zum Schwachstellenmanagement betreibt, während ein Schwachstellenscan prüft, ob im untersuchten Umfeld konkrete technische Probleme vorliegen. Ein Penetrationstest kann einen realen Angriffspfad nachweisen, bestätigt für sich allein aber nicht die Konformität des gesamten ISMS. Eine Härtungsprüfung kann Konfigurationen gegen einen genehmigten Standard bewerten, ersetzt jedoch nicht die Prüfung von Verantwortlichkeiten, Risiken, Geschäftskontinuität oder Incident Management.

Ein Zertifizierungsaudit ist wiederum eine andere Kategorie. Es handelt sich um ein Audit durch eine unabhängige dritte Stelle im Rahmen eines Zertifizierungsverfahrens. ISO/IEC 27006-1:2024 legt zusätzliche Anforderungen an Stellen fest, die ISMS nach ISO/IEC 27001 auditieren und zertifizieren.^[18] Ein internes Audit, ein Beratungs-Audit oder der Bericht eines Beratungsunternehmens ist kein Zertifikat.

Zuerst Ziel, Kriterien und Umfang

Ein häufiger Fehler entsteht, wenn eine Organisation ein "Sicherheitsaudit" beauftragt, ohne festzulegen, was genau geprüft werden soll. Auch die Formulierung "Audit der Konformität mit ISO 27001, NIS2 und DSGVO" beschreibt noch keinen hinreichenden Auditumfang. ISO/IEC 27001 ist eine Managementsystemnorm, NIS2 eine Richtlinie der Europäischen Union und die DSGVO eine Verordnung zum Schutz personenbezogener Daten. Jedes dieser Regelwerke hat einen anderen Anwendungsbereich, andere Adressaten und andere Nachweisanforderungen.

Das Dokument zur Einleitung des Audits sollte mindestens Ziel, Kriterien, organisatorischen und technischen Umfang, Prüfzeitraum, Ausschlüsse, Einschränkungen, Stichprobenverfahren und Regeln für den Zugriff auf Nachweise festlegen.

• Das Ziel sollte die Entscheidung beschreiben, die der Auditbericht unterstützen soll. Dies kann die Bewertung der Konformität mit § 19 KRI, die Überprüfung ausgewählter Pflichten nach KSC, die Bewertung der Bereitschaft für eine ISO/IEC-27001-Zertifizierung oder die Prüfung der Wirksamkeit bestimmter Sicherheitsmaßnahmen sein.
• Die Kriterien sollten eindeutig und versionsbezogen sein. Wird ein Konfigurationsstandard geprüft, muss seine Version angegeben werden. Betrifft die Prüfung Rechtspflichten, sind der einschlägige Rechtsakt und der maßgebliche Rechtsstand zu bestimmen. Ist eine Norm das Kriterium, sollte die konkrete Ausgabe benannt werden. Die Vermischung unterschiedlicher Anforderungsversionen in einer Checkliste erschwert später die nachvollziehbare Begründung einer Feststellung.
• Der organisatorische und technische Umfang sollte die betroffenen Rechtsträger, Prozesse, Standorte, Dienste, Systeme, Lieferanten, Schnittstellen und Daten umfassen. Er sollte nicht bei einer Geräteliste enden. Der Auditor muss verstehen, welche Geschäftsleistungen von diesen Komponenten abhängen und welche Abhängigkeiten das Ergebnis beeinflussen können.
• Der Prüfzeitraum ist besonders bei Protokollen, Vorfällen, Berechtigungsprüfungen, Änderungen, Backups, Wiederherstellungstests und Schulungen wichtig. Eine Konfiguration an einem einzelnen Tag zu prüfen, beweist nicht, dass der zugrunde liegende Prozess das gesamte Jahr korrekt funktioniert hat.
• Ausschlüsse und Einschränkungen sind zusammen mit ihrem Einfluss auf die Aussagekraft der Ergebnisse zu dokumentieren. Hatte der Auditor keinen Zugang zur Cloud-Umgebung, konnte er die Netzwerkkonfiguration nicht prüfen oder erhielt lediglich eine Erklärung eines Dienstleisters, muss der Bericht dies deutlich benennen.

Wie ein belastbares Audit abläuft

ISO 19011:2026, im Mai 2026 als vierte Ausgabe veröffentlicht, beschreibt Auditprinzipien, die Steuerung von Auditprogrammen, die Durchführung von Audits und die Kompetenz der beteiligten Personen.^[1] Die Ausgabe von 2026 ersetzt ISO 19011:2018 und berücksichtigt Technologie, Digitalisierung, virtuelle Umgebungen und risikobasiertes Vorgehen stärker.^[1] Für ISMS-Audits liefert ISO/IEC 27007:2020 ergänzende Leitlinien.^[2] Die Bewertung einzelner Informationssicherheitskontrollen kann zusätzlich durch ISO/IEC TS 27008:2019 unterstützt werden; diese Veröffentlichung ist weiterhin gültig, befindet sich aber in Überarbeitung.^[16]

In der Praxis sollte der Auditprozess mehrere zusammenhängende Schritte umfassen.

1. Die Planung legt Kriterien, Stichprobe, Zeitplan, Rollen, Kommunikationswege, Einschränkungen und Risiken der Prüfung selbst fest. Sind aktive Tests vorgesehen, benötigen sie eine gesonderte Autorisierung und Sicherheitsregeln.
2. Die Dokumentenprüfung dient dazu, den erwarteten Ablauf des Systems zu verstehen. Es geht nicht darum, Verfahren zu zählen. Der Auditor sollte wissen, wer eine Kontrolle verantwortet, welchem Zweck sie dient und welche Nachweise im normalen Betrieb entstehen sollten.
3. Interviews helfen, Prozesse zu verstehen, doch eine Aussage allein ist kein ausreichender Nachweis. Behauptet ein Administrator etwa, dass die Konten ausgeschiedener Beschäftigter am selben Tag gesperrt werden, ist dies an einer Stichprobe tatsächlicher Fälle zu überprüfen.
4. Beobachtung macht einen Prozess in seiner tatsächlichen Ausführung sichtbar. Sie kann die Bearbeitung eines Sicherheitsvorfalls, die Vergabe von Zugriffen, die Arbeit eines Administrators, den Zutritt zum Serverraum oder die Durchführung eines Wiederherstellungstests betreffen.
5. Stichproben sind ein grundlegendes Mittel, um den Aufwand eines Audits zu begrenzen. Eine Stichprobe kann Benutzerkonten, Änderungen, Vorfälle, Geräte, Lieferanten, Backups oder privilegierte Berechtigungen umfassen. Die Auswahlmethode sollte zum Risiko und zum Prüfziel passen.
6. Die technische Verifikation kann das Auslesen von Konfigurationen, Abfragen in Identitätsverzeichnissen, die Analyse von Cloud-Richtlinien, die Prüfung von Firewall-Regeln, die Analyse von Protokollen oder die Kontrolle des Sicherheitszustands von Endgeräten umfassen. Aktive Tests, Schwachstellenscans und Penetrationstests benötigen einen gesondert definierten Umfang und eine gesonderte Autorisierung.
7. Triangulation bedeutet, mehrere Arten von Nachweisen miteinander zu vergleichen. Eine Richtlinie kann MFA verlangen, der Administrator kann erklären, dass MFA umgesetzt ist, während die Konfiguration eine Ausnahme für ein technisches Konto zeigt. Eine solche Abweichung ist häufig aussagekräftiger als das Fehlen eines weiteren Dokuments.
8. Die Abstimmung von Tatsachen ist keine Verhandlung über das Ergebnis. Die auditierte Organisation muss die Möglichkeit haben, auf einen Sachfehler, einen fehlenden Nachweis oder ein falsches Verständnis der Architektur hinzuweisen. Sie sollte jedoch nicht erwarten, dass eine korrekt belegte Feststellung entfernt wird, nur weil sie unangenehm ist.
9. Nach dem Audit ist ein Maßnahmenplan erforderlich. Er sollte Verantwortliche, Fristen, die Art der Behebung, das verbleibende Risiko und den für die Schließung der Feststellung notwendigen Nachweis benennen. Für besonders wichtige Probleme sollte ein Retest vorgesehen werden.

Nachweise: Was ausreichend ist und was nur überzeugend wirkt

Der größte Unterschied zwischen einem belastbaren Audit und einer Sammlung von Meinungen liegt in der Qualität der Nachweise. Ein Nachweis sollte für die zu stützende Aussage geeignet, reproduzierbar und gegen unbefugte Veränderung geschützt sein.

Ein Dokument kann belegen, dass eine Organisation eine Regel festgelegt hat. Es beweist nicht automatisch, dass diese Regel angewendet wird. Ein Screenshot kann den Zustand einer Konfiguration zeigen, ist ohne Datum, Systemidentifikation und Kontext aber mitunter schwer verifizierbar. Ein Konfigurationsexport oder das Ergebnis einer Abfrage, die im Beisein des Auditors ausgeführt wurde, liefert in der Regel einen stärkeren Nachweis als ein Bild ohne nachvollziehbare Herkunft.

Für besonders sensible Nachweise sind sichere Übertragungswege, Verschlüsselung, Aufbewahrung und Löschung von Arbeitskopien festzulegen. Auditoren sollten Geheimnisse nicht "vorsorglich" sammeln. Vollständige Datenbanken, private Schlüssel oder Passwörter sind üblicherweise nicht erforderlich. Häufig genügen kontrollierte Exporte, reine Lesesitzungen oder die Vorführung des Nachweises durch den Systemverantwortlichen.

Eine Stichprobe liefert angemessene, nicht absolute Sicherheit. Werden 12 von 900 Konten untersucht, sollte der Bericht nicht behaupten, alle Konten seien korrekt. Er sollte Umfang und Auswahlverfahren der Stichprobe, das Ergebnis und die Grenzen der Verallgemeinerung beschreiben. In Bereichen mit hohem Risiko kann die Stichprobe erweitert oder die gesamte Population mit Abfragen oder Skripten analysiert werden.

Was zum Umfang eines IT-Sicherheitsaudits gehören kann

Der Umfang folgt Ziel und Risiko, nicht einem universellen Paket. In der Praxis kann ein Audit Sicherheitsgovernance, Managementverantwortung, Risikomanagement, Asset-Inventarisierung, Identitäten und Zugriffe, Infrastrukturkonfiguration, Cloud-Sicherheit, Anwendungen, Schwachstellen, Backups, Geschäftskontinuität, Monitoring, Incidents, Lieferanten und physische Sicherheit umfassen.

Im Identitätsbereich ist der gesamte Lebenszyklus eines Kontos zu untersuchen: Erstellung, Rollenwechsel, Berechtigungsvergabe, Reviews, privilegierter Zugriff, MFA, technische Konten und Entzug von Zugriffen. Die bloße Prüfung, ob "MFA aktiviert" ist, kann Ausnahmen, schwache Verfahren zur Kontowiederherstellung oder unkontrollierte Dienstkonten übersehen.

In der Infrastruktur sind Endgeräte, Server, mobile Geräte, Netzwerke, Segmentierung, Administrationsdienste, Konfigurationsmanagement und Härtung relevant. CIS Controls v8.1 können bei der Priorisierung von Sicherheitsmaßnahmen helfen, und CIS Benchmarks können technische Kriterien für konkrete Technologien liefern, sofern die Organisation sie als Standard übernommen hat.^[13] CIS Controls sind jedoch weder eine Auditmethodik noch polnisches Recht.

In Cloud-Umgebungen sind nicht nur Ressourcen zu prüfen, sondern auch Tenant-Struktur, Identitäten, Rollen, Schlüssel, Logging, Richtlinien, Netzwerkkonfiguration, Datensicherungen und die Verantwortungsaufteilung mit dem Anbieter. Fehlender Zugriff auf die Administrationsoberfläche eines Cloud-Anbieters darf nicht durch die Annahme ersetzt werden, "Cloud sei per Definition sicher".

Für Anwendungssicherheit kann OWASP ASVS 5.0.0, im Mai 2025 veröffentlicht und am 29. August 2026 weiterhin die stabile Ausgabe, als Katalog überprüfbarer technischer Anforderungen für Webanwendungen und Webdienste dienen.^[14] Ein Anwendungsaudit kann durch Code-Reviews, Penetrationstests, Abhängigkeitsanalysen und die Prüfung des Softwareentwicklungsprozesses ergänzt werden.

Beim Schwachstellenmanagement sind Informationsquellen, Scanfrequenz, Verifikation der Ergebnisse, Priorisierung, Behebungsfristen, Ausnahmebehandlung und erneute Prüfung zu untersuchen. Die Bewertung von Schwachstellen sollte nicht ausschließlich auf einem CVSS-Wert beruhen.

CVSS 4.0 beschreibt die technische Kritikalität einer Schwachstelle mithilfe der Metrikgruppen Base, Threat, Environmental und Supplemental.^[15] FIRST weist ausdrücklich darauf hin, dass Organisationen die Bewertung um Bedrohungsinformationen und ihren eigenen Umgebungskontext ergänzen sollen; Faktoren wie regulatorische Anforderungen, finanzielle Verluste, Zahl betroffener Kunden oder Reputationsfolgen liegen außerhalb des CVSS.^[15] Ein CVSS-Wert ist daher ein Eingangswert für die Risikobewertung und keine fertige Risikobewertung der Organisation.

Bei der Geschäftskontinuität ist nicht nur zu prüfen, ob Backups existieren, sondern auch Wiederherstellungsziele, Abhängigkeiten, Schutz und Trennung der Sicherungen, Tests und tatsächliche Wiederherstellungsergebnisse. RPO bezeichnet den angestrebten Wiederherstellungspunkt und damit den akzeptierbaren Datenverlust in Zeiteinheiten. RTO bezeichnet die angestrebte Zeit bis zur Wiederherstellung eines Dienstes. Ein Backup-Zeitplan beweist nicht automatisch, dass RPO oder RTO erfüllt werden.

Monitoring und Incident Management erfordern die Prüfung von Logquellen, Zeitsynchronisation, Aufbewahrung, Integrität, Detektionsregeln, Eskalation, Verantwortlichkeiten und Nachweisen aus realen Fällen. In diesem Bereich kann ein IT-Sicherheitsaudit durch eine Bewertung des SOC 24/7 ergänzt werden: Entscheidend ist nicht nur, ob Logs gesammelt werden, sondern ob kritische Szenarien sichtbar sind, jemand sie tatsächlich analysiert und eine reale Reaktionsmöglichkeit besteht.

Wie Feststellungen und Risiken beschrieben werden sollten

Eine gute Feststellung muss dem Empfänger verständlich machen, was gefordert war, was festgestellt wurde und warum dies relevant ist. Der Mindestinhalt umfasst Kriterium, Ist-Zustand, Nachweis, Stichprobenumfang, mögliche Ursache, Auswirkung und Empfehlung.

Konformitätsbewertung und Risikobewertung sollten getrennt werden. Konformität beantwortet die Frage, ob eine bestimmte Anforderung erfüllt wurde. Risiko beschreibt Wahrscheinlichkeit und Auswirkung eines unerwünschten Ereignisses im Kontext von Assets, Exposition, Bedrohungen und bestehenden Sicherheitsmaßnahmen.

Die Verletzung einer Rechtspflicht kann formell erheblich sein, auch wenn die technische Schadenswahrscheinlichkeit gering ist. Umgekehrt kann ein schwerwiegender Angriffspfad aus mehreren kleineren Schwächen entstehen und keiner einzelnen Position einer Checkliste entsprechen.

Eine Skala "Wahrscheinlichkeit x Auswirkung" sollte nicht automatisch multipliziert werden, wenn die Organisation die Bedeutung dieser Werte nicht definiert hat. Eine Risikomatrix ist nur dann nützlich, wenn die Kriterien reproduzierbar sind, die Verantwortlichen die Skala verstehen und das Ergebnis zu einer Entscheidung führt.

Was ein Auditbericht enthalten sollte

Ein Auditbericht sollte für zwei unterschiedliche Zielgruppen lesbar sein: für die Leitung und für die Personen, die Maßnahmen umsetzen müssen. Deshalb ist es sinnvoll, eine Managementzusammenfassung von technischen Details zu trennen.

Die Managementzusammenfassung sollte die wichtigsten Risiken, Pflichten, Abhängigkeiten und erforderlichen Entscheidungen darstellen. Sie sollte keine Liste von Ports, IP-Adressen und Konfigurationsparametern sein.

Der methodische Teil sollte Ziel, Kriterien, Umfang, Daten, Stichprobenmethode und Einschränkungen angeben. So kann der Empfänger beurteilen, wie weit die Ergebnisse verallgemeinert werden dürfen.

Jede Feststellung sollte auf einen identifizierbaren Nachweis zurückgeführt werden können. In einem breit verteilten Bericht müssen keine Geheimnisse, vollständigen Konfigurationsausschnitte oder personenbezogenen Daten enthalten sein. Technische Details können in einen besonders geschützten technischen Anhang ausgelagert werden.

Die Priorität einer Behebung sollte sich aus Risiko, Rechtspflicht, Abhängigkeiten und Umsetzbarkeit ergeben. Die Empfehlung "MFA einführen" ist schwach, wenn nicht festgelegt ist, für welche Konten und Systeme sie gilt, welche Ausnahmen bestehen und wie die Wirksamkeit später bestätigt wird.

Ein Bericht sollte weder vollständige Sicherheit noch das Ausbleiben zukünftiger Vorfälle versprechen. Er beschreibt den Zustand eines definierten Umfangs zu einem definierten Zeitpunkt auf Basis bestimmter Nachweise.

Methodiken und Standards richtig auswählen

ISO 19011:2026 ist ein Referenzrahmen für Prinzipien und Organisation von Managementsystemaudits.^[1] Sie ist keine Zertifizierungsnorm für Organisationen und ersetzt nicht das eigentliche Auditkriterium.

ISO/IEC 27007:2020 betrifft das Auditieren von ISMS und ergänzt ISO 19011.^[2] Am 29. August 2026 ist die Ausgabe von 2020 weiterhin veröffentlicht, befindet sich aber in Überarbeitung.

ISO/IEC 27001:2022 einschließlich Amd 1:2024 enthält Anforderungen an ein ISMS und kann ein Auditkriterium bilden.^[3] Ein internes Audit der Konformität mit ISO/IEC 27001 ist nicht dasselbe wie ein Zertifizierungsaudit.

ISO/IEC TS 27008:2019 enthält Leitlinien zur Prüfung und Bewertung der Implementierung und des Betriebs von Informationssicherheitskontrollen einschließlich technischer Kontrollen.^[16] Die Veröffentlichung ist weiterhin gültig, befindet sich jedoch in Überarbeitung.

NIST SP 800-53A Rev. 5 enthält anpassbare Verfahren zur Bewertung von Kontrollen.^[4] Es ist besonders hilfreich, wenn Gestaltung, Implementierung und Betrieb bestimmter Sicherheitsmaßnahmen systematisch bewertet werden sollen.

NIST CSF 2.0 strukturiert erwartete Ergebnisse des Cybersicherheitsmanagements und kann für Profile des Ist- und Zielzustands genutzt werden.^[5] Es ist weder ein Zertifikat noch eine polnische Rechtspflicht.

Mappings zwischen Standards können doppelte Prüfungen reduzieren, erzeugen aber keine automatische Gleichwertigkeit. Derselbe Nachweis kann mehrere Anforderungen unterstützen, doch jede Anforderung ist in ihrem eigenen Anwendungsbereich und Kontext zu bewerten.

Was sich tatsächlich aus KRI ergibt

Am 29. August 2026 gilt die Verordnung des polnischen Ministerrats vom 21. Mai 2024 über den Nationalen Interoperabilitätsrahmen (KRI).^[6] ELI weist aus, dass diese Verordnung am 23. Februar 2027 außer Kraft tritt.^[6]

§ 19 Abs. 2 Nr. 14 verpflichtet Einrichtungen, die öffentliche Aufgaben wahrnehmen, mindestens einmal jährlich ein periodisches internes Audit der Informationssicherheit sicherzustellen.^[6] Die Rechtsgrundlage liegt in § 19, nicht in § 20. § 20 betrifft Nachvollziehbarkeit und Systemprotokolle, einschließlich der verpflichtenden Protokollierung bestimmter Aktivitäten und, sofern keine speziellere Vorschrift gilt, einer zweijährigen Aufbewahrungsfrist für Logs.^[6]

§ 19 Abs. 3 enthält einen Mechanismus, nach dem die Anforderungen der Absätze 1 und 2 als erfüllt gelten, wenn das ISMS auf PN-ISO/IEC 27001 basiert und die Festlegung von Sicherheitsmaßnahmen, das Risikomanagement und das Auditieren auf den mit dieser Norm verbundenen Polnischen Normen beruhen, darunter PN-ISO/IEC 27002 und PN-ISO/IEC 27005.^[6] Daraus folgt keine allgemeine Pflicht zu einer ISO/IEC-27001-Zertifizierung.

Im Jahr 2026 läuft das Verfahren für eine neue KRI-Verordnung, Entwurf RD313.^[17] Der Entwurf sieht unter anderem vor, ISMS-bezogene Regelungen aus der neuen KRI-Verordnung zu entfernen, weil diese Fragen im KSC geregelt wurden. Am 29. August 2026 handelt es sich jedoch weiterhin um einen Entwurf und nicht um geltendes Recht.^[17] Ein KRI-Audit im Jahr 2026 sollte sich daher auf die geltende Verordnung von 2024 stützen.

KSC nach Umsetzung von NIS2

Die KSC-Novelle vom 23. Januar 2026 trat im Wesentlichen am 3. April 2026 in Kraft.^[8] Der konsolidierte Text des polnischen Gesetzes über das nationale Cybersicherheitssystem nach dem Stand der Kanzlei des Sejm vom 18. August 2026 sollte für ein Audit Ende August 2026 die maßgebliche Primärquelle sein.^[7]

Art. 15 Abs. 1 KSC bestimmt, dass eine wesentliche Einrichtung auf eigene Kosten mindestens einmal alle drei Jahre ein Sicherheitsaudit des Informationssystems durchführt, das im Prozess der Erbringung ihrer Dienstleistung eingesetzt wird. Der Zeitraum wird ab Erstellung und Unterzeichnung des Berichts des vorherigen Audits berechnet.^[7] Die wesentliche Einrichtung übermittelt dem zuständigen Cybersicherheitsorgan innerhalb von drei Arbeitstagen nach Erhalt des Berichts eine elektronische Kopie.^[7]

Das zuständige Cybersicherheitsorgan kann einer wesentlichen Einrichtung jederzeit ein externes Audit auferlegen und einer wichtigen Einrichtung nach einem erheblichen Sicherheitsvorfall oder einem anderen Verstoß gegen das Gesetz.^[7] Das regelmäßige Dreijahresaudit nach Art. 15 Abs. 1 ist daher keine allgemeine Pflicht aller wichtigen Einrichtungen.

Art. 16 sieht vor, dass eine wesentliche oder wichtige Einrichtung die Pflichten aus Kapitel 3 innerhalb von zwölf Monaten ab dem Tag erfüllt, an dem sie die Kriterien für diese Einstufung erfüllt, und dass eine wesentliche Einrichtung ihr erstes Audit innerhalb von 24 Monaten ab diesem Tag sicherstellt.^[7] Für Einrichtungen, die die Kriterien bereits am Tag des Inkrafttretens der Novelle erfüllten, sieht Art. 33 des Änderungsgesetzes entsprechende Fristen von zwölf und 24 Monaten ab dem 3. April 2026 vor.^[8] Die Übergangsbestimmungen enthalten Ausnahmen, unter anderem für frühere Betreiber wesentlicher Dienste, die bereits ein Audit durchgeführt hatten.^[8]

KSC regelt außerdem detailliert, wer das gesetzliche KSC-Audit durchführen darf. Dies kann eine entsprechend akkreditierte Konformitätsbewertungsstelle, mindestens zwei Auditoren, die die gesetzlichen Voraussetzungen erfüllen, oder der zuständige sektorale CSIRT sein, sofern dessen Auditoren diese Voraussetzungen erfüllen.^[7] Art. 15 Abs. 2a schließt Personen aus, die bei der auditierten Einrichtung Aufgaben nach Art. 8 sowie Art. 9-13 wahrnehmen oder diese innerhalb eines Jahres vor Beginn des Audits wahrgenommen haben.^[7] Dies ist eine konkrete gesetzliche Anforderung und nicht lediglich ein allgemeines Prinzip der Unparteilichkeit.

NIS2 ist als unionsrechtlicher Regelungsrahmen und Quelle des Aufsichtsmodells zu verstehen. Art. 32 der Richtlinie verlangt, dass zuständige Behörden gegenüber wesentlichen Einrichtungen unter anderem Vor-Ort-Kontrollen, externe Aufsichtsmaßnahmen, regelmäßige und gezielte Sicherheitsprüfungen, Ad-hoc-Prüfungen und Sicherheitsscans durchführen können.^[9] Für eine polnische Einrichtung sind die konkreten Pflichten jedoch in erster Linie anhand des aktuellen KSC zu bestimmen.

DSGVO: regelmäßige Wirksamkeitsprüfung, nicht zwingend "ein Audit pro Jahr"

Die DSGVO enthält keine allgemeine Pflicht, jedes Jahr ein IT-Sicherheitsaudit durchzuführen. Art. 32 Abs. 1 Buchst. d verlangt jedoch risikoadäquat ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Sicherheit der Verarbeitung.^[10]

Ein Audit kann Teil dieses Verfahrens sein, ist aber nicht die einzige zulässige Methode. Je nach Risiko können Konfigurationsreviews, Wiederherstellungstests, Schwachstellenscans, Penetrationstests, Incident-Übungen, Lieferantenbewertungen und andere Prüfungsformen erforderlich sein.

Bei einem DSGVO-Audit ist außerdem zwischen Sicherheit und vollständiger Datenschutzkonformität zu unterscheiden. Ein technischer Test kann Nachweise zu Art. 32 liefern, bewertet für sich allein aber weder die Rechtmäßigkeit der Verarbeitungsgrundlagen noch Informationspflichten, Aufbewahrung, Betroffenenrechte oder Datenübermittlungen.

DORA und das Verhältnis zum KSC

DORA gilt seit dem 17. Januar 2025 für die im Rechtsakt bezeichneten Finanzunternehmen.^[11] Für andere Finanzunternehmen als Kleinstunternehmen unterliegt der IKT-Risikomanagementrahmen regelmäßigen internen Audits nach einem Auditplan; Häufigkeit und Gegenstand der Audits müssen dem IKT-Risiko angemessen sein.^[11]

DORA sieht außerdem Threat-Led Penetration Testing (TLPT) als erweiterte Resilienzprüfung vor. Die Pflicht, TLPT mindestens alle drei Jahre durchzuführen, betrifft die nach Art. 26 bestimmten Finanzunternehmen und nicht jede von DORA erfasste Organisation.^[11] TLPT ist weder ein Synonym für ein ISMS-Audit noch für einen gewöhnlichen Penetrationstest.

Besondere Aufmerksamkeit erfordert das Verhältnis von DORA und KSC. Art. 8i KSC bestimmt, dass für wesentliche oder wichtige Einrichtungen aus den Sektoren Bankwesen und Finanzmarktinfrastrukturen bestimmte KSC-Vorschriften zum ISMS und zur Meldung erheblicher Sicherheitsvorfälle nicht gelten; zugleich enthält die Vorschrift einen ausdrücklich bezeichneten Katalog von Ausnahmen.^[7] Art. 15 gehört nicht zu diesem Katalog. Deshalb darf nicht mechanisch angenommen werden, dass ein DORA unterliegendes Finanzunternehmen zusätzlich das periodische KSC-Audit nach Art. 15 durchführen muss, nur weil es die Kriterien einer wesentlichen oder wichtigen Einrichtung erfüllt. Zunächst sind sein konkreter sektoraler Status und der Anwendungsbereich von Art. 8i zu bestimmen.

Remote, vor Ort oder hybrid auditieren

Es gibt keine belastbare universelle Quote wie "70 Prozent eines Audits können remote durchgeführt werden". Die Prüfungsform richtet sich nach dem benötigten Nachweis und dem Risiko.

Dokumente, Konfigurationsexporte, Logs, Teile von Interviews und viele Einstellungen von Cloud-Diensten können häufig remote geprüft werden. Eine Vor-Ort-Prüfung kann bei physischen Sicherheitsmaßnahmen, isolierten Umgebungen, OT, Datenträgerlagerung, der Beobachtung realer Prozesse oder immer dann erforderlich sein, wenn remote kein ausreichend belastbarer Nachweis gewonnen werden kann.

ISO 19011:2026 berücksichtigt Entwicklungen in Technologie, Digitalisierung und virtuellen Umgebungen und stärkt das risikobasierte Vorgehen.^[1] Sie schreibt jedoch weder eine prozentuale Aufteilung noch eine einzige richtige Auditform vor.

Remote-Arbeit sollte über genehmigte Kanäle, personenbezogene Konten mit minimalen Berechtigungen und angemessener Zugriffsprotokollierung erfolgen. Kann ein Nachweis in einer kontrollierten Sitzung präsentiert werden, ist das Kopieren einer vollständigen Datenbank oder Konfiguration in die Umgebung des Auditors häufig unnötig.

Unabhängigkeit, Kompetenz und Vertraulichkeit

Unparteilichkeit bedeutet nicht, dass ein Auditor nie zuvor für eine Organisation tätig gewesen sein darf. Der konkrete Interessenkonflikt ist zu bewerten: Wer hat eine Sicherheitsmaßnahme entworfen, wer hat sie implementiert, wer betreibt sie, wer genehmigt das Ergebnis und hängt die Vergütung vom Auditergebnis ab?

Bei einem gewöhnlichen Beratungs-Audit ergeben sich Anforderungen an Unabhängigkeit aus der gewählten Methodik, dem Vertrag und dem erwarteten Maß an Prüfungssicherheit. Für das gesetzliche KSC-Audit gelten zusätzliche konkrete Bedingungen nach Art. 15, einschließlich Anforderungen an Auditstellen und Auditoren sowie der einjährigen Ausschlussfrist für Personen, die in der Einrichtung Aufgaben nach Art. 8 sowie Art. 9-13 wahrnehmen.^[7]

Vor Vertragsabschluss sollten Erfahrung des Teams im jeweiligen Sektor und in den untersuchten Technologien, Stichprobenmethodik, Qualitätssicherung des Berichts, Schutz der Nachweise und Fähigkeit zur Durchführung eines Retests geprüft werden. Ein Personenzertifikat kann einen bestimmten Wissensstand belegen, ersetzt jedoch weder praktische Erfahrung noch beseitigt es einen Interessenkonflikt.

Vertraulichkeit ist besonders wichtig, weil Auditunterlagen eine nahezu fertige Karte der Schwachstellen einer Organisation darstellen können. Berichte, Konfigurationsexporte, Scannergebnisse und Arbeitsunterlagen sollten eine definierte Klassifizierung, Empfängerkreise, Verarbeitungsorte, Aufbewahrungsfristen und sichere Löschverfahren haben.

Wie eine Feststellung nach dem Audit geschlossen wird

Eine Feststellung sollte nicht dadurch geschlossen werden, dass ihr Status in einer Tabelle von "offen" auf "geschlossen" geändert wird. Erforderlich ist ein Nachweis, dass die Ursache behoben oder das verbleibende Risiko auf der zuständigen Entscheidungsebene akzeptiert wurde.

Betrifft eine Feststellung fehlende MFA, können Konfiguration, Liste der erfassten Konten und ein Testergebnis als Nachweis dienen. Betrifft sie eine Schwachstelle, kann ein erneuter Scan oder Test erforderlich sein. Betrifft sie unklare Verantwortlichkeiten, reicht ein Dokument allein nicht aus; die Rolle muss tatsächlich zugewiesen und der Prozess umgesetzt werden.

Ein Retest sollte zur Feststellung proportional sein. Nicht immer muss das gesamte Audit wiederholt werden. Bei einem kritischen Problem sollte allerdings nicht nur die eigentliche Korrektur geprüft werden, sondern auch, ob sie neues Risiko eingeführt hat.