Was ist ein IT-Sicherheitsaudit und was umfasst es?

Was ist ein IT-Sicherheitsaudit im Unternehmen? Zu unterscheiden sind der organisatorische Teil, der Verantwortlichkeiten, Zugriffsrechte, Backups und das Vorgehen bei Vorfällen bewertet, und der technische Teil, der Systemeinstellungen, Sicherheitslücken und Code prüft. Der Preis hängt vom Umfang der zu prüfenden Systeme und der Prüfungstiefe ab: Unsere automatisierte Sicherheitsprüfung kostet je nach Umfang 89–890 €, ein manuelles Expertenaudit ist ab 3.500 € verfügbar. Klären Sie zunächst, welchen Teil Sie benötigen und welchen Nachweis Sie erwarten, denn eine Website-Prüfung, eine Bewertung des Sicherheitsmanagements im Unternehmen und eine Zertifizierung sind unterschiedliche Aufträge mit unterschiedlichen Ergebnissen.

Stellen Sie sich vor, ein Kunde verlangt vor der Vertragsunterzeichnung ein IT-Sicherheitsaudit, doch im Anhang stehen sowohl Fragen zu den Zugriffsrechten der Beschäftigten als auch zur technischen Systemprüfung. Es reicht nicht, die Anforderung an den Entwickler weiterzuleiten: Sie müssen klären, ob der Kunde einen Website-Bericht, dokumentierte Unternehmensprozesse oder das Zertifikat einer unabhängigen Stelle erwartet und welche Systeme oder Tätigkeitsbereiche dieser Nachweis abdecken soll. Wir empfehlen, den genauen Wortlaut der Anfrage aufzubewahren und ihren Zweck zu klären, bevor Sie einen Anbieter auswählen und eine Preiskalkulation akzeptieren.

Was ist ein IT-Sicherheitsaudit: zwei Aufgaben unter einem Namen

Die beiden Teile beantworten unterschiedliche Fragen. Der organisatorische Teil untersucht, wie das Unternehmen Sicherheitsentscheidungen trifft und umsetzt, der technische Teil untersucht, wie ein bestimmtes System funktioniert und ob sich seine Schutzmechanismen umgehen lassen. Deshalb sieht dasselbe Thema in beiden Teilen ganz unterschiedlich aus: Bei der Bewertung der Rechtevergabe verlangt der Auditor Nachweise darüber, wer die Rechte eines Beschäftigten genehmigt und wie sie entzogen werden, während er beim Anwendungstest mit einem gewöhnlichen Konto versucht, etwas zu tun, das diesem Konto nicht erlaubt ist. Beide Ergebnisse sollten gemeinsam betrachtet werden, doch keines ersetzt das andere: Eine geregelte Zugriffsrichtlinie beweist nicht, dass die Anwendung sie einhält, und eine sichere Anwendung beweist nicht, dass jemand das Konto eines ausgeschiedenen Beschäftigten geschlossen hat.

Das Wort „Audit“ allein sagt in einem Auftrag deshalb wenig aus. Wir empfehlen, zwei Dinge hinzuzufügen: die Kriterien, anhand derer die Arbeit bewertet wird, und die Nachweise, die Sie im Bericht erwarten. Bei einer Bewertung von Sicherheitslücken sind das priorisierte Befunde, bei einem Penetrationstest ein konkreter Schutzmechanismus oder eine Handlungsbeschränkung, deren Umgehung versucht werden soll, und bei einem organisatorischen Konformitätsaudit ein Anforderungskatalog, mit dem Dokumente und Alltagspraxis verglichen werden.

Wenn Sie lediglich eine erste Bewertung bestehender Mängel wählen, bezeichnen Sie auch das Ergebnis entsprechend und nicht als Zertifizierung; vereinbaren Sie bereits im Auftrag, wer dieses Dokument lesen und welche Entscheidung damit getroffen werden soll. Bei einer Zertifizierung müssen Sie wissen, wer den Nachweis ausstellt: ISO selbst zertifiziert keine Unternehmen und beschreibt Zertifizierung als schriftliche Bestätigung einer unabhängigen Stelle, dass bestimmte Anforderungen erfüllt sind. In derselben Erläuterung weist ISO darauf hin, dass eine Akkreditierung die Kompetenz der Zertifizierungsstelle bestätigt, jedoch nicht verpflichtend ist; die Aussage, nur eine akkreditierte Stelle dürfe zertifizieren, wäre deshalb ungenau. Wenn Ihr Kunde eine akkreditierte Zertifizierung verlangt, klären Sie diese Bedingung vor Vertragsabschluss und prüfen Sie die Akkreditierung der ausgewählten Stelle, damit Sie später keinen Nachweis erhalten, dessen Anerkennung der Kunde nicht zugestimmt hat.

Unser Angebot umfasst die technische Prüfung von Websystemen, und im organisatorischen Teil können wir bei der Erstellung von Sicherheitsrichtlinien helfen; wir zertifizieren jedoch keine Unternehmen und betreiben Ihr Informationssicherheitsmanagementsystem (ISMS) nicht für Sie, weshalb diese Grenze auch im Auftrag festgehalten werden sollte. Wenn der Auftrag sowohl eine Website-Prüfung als auch eine Bewertung des Unternehmensmanagements umfasst, vereinbaren Sie, wer die technischen Nachweise erstellt, wer sie mit den ausgewählten Anforderungen abgleicht und wer für die abschließende Bewertung verantwortlich ist; andernfalls erwarten Sie von uns möglicherweise eine Bewertung der Managementprozesse und vom organisatorischen Auditor einen Test, den Sie nicht beauftragt haben. Den organisatorischen Teil übernimmt üblicherweise ein Berater für Informationssicherheitsmanagement oder ein ISO/IEC 27001-Auditor, während das Zertifikat von einer Zertifizierungsstelle ausgestellt wird.

Organisatorischer Teil: Dokumente mit der Praxis abgleichen

Papier ist geduldig, deshalb sollte der organisatorische Teil prüfen, ob es für die Vorgaben der Sicherheitsrichtlinie Verantwortliche, die notwendigen Ressourcen und Umsetzungsnachweise gibt und ob Maßnahmen für die in der Risikobewertung benannten Probleme vorgesehen sind; der ENISA-Leitfaden für kleine und mittlere Unternehmen behandelt Führungsverantwortung, Einbindung und Schulung der Beschäftigten, Sicherheitsrichtlinien, Lieferantenmanagement, Zugriffsschutz und einen Incident-Response-Plan (Plan für die Reaktion auf Sicherheitsvorfälle). Ergänzen Sie Gespräche mit Führungskräften und Beschäftigten um die Prüfung von Dokumenten und konkreten Praxisbeispielen, damit die Bewertung zwischen vorgesehenen Abläufen und ihrer Umsetzung unterscheiden und auch benennen kann, welche Nachweise der Auditor nicht erhalten hat und welche noch erstellt werden müssen.

Bei Zugriffsrechten betrachtet ein guter Auditor nicht nur die Vergabe von Konten, sondern auch deren Schließung, den Einsatz von Mehrfaktor-Authentifizierung und die Rechte von Lieferanten; deshalb sollten die geprüften Beispiele das Ausscheiden eines Beschäftigten oder einen Lieferantenwechsel umfassen, denn gerade dabei werden Konten häufig vergessen. Bei Backups verhält es sich ähnlich, denn die Antwort „Wir erstellen Kopien“ sagt wenig aus. Ein Backup, dessen Wiederherstellung noch niemand durchgeführt hat, kann sich bei einem Vorfall als unvollständig erweisen, und das fällt erst auf, wenn die Website bereits ausgefallen ist. Für das Verzeichnis der Systeme und Geräte braucht es Verantwortliche, für Ereignisprotokolle ein Verfahren zur Durchsicht und für den Incident-Response-Plan eine namentlich benannte Person, die Entscheidungen trifft und mit den Beteiligten kommuniziert; andernfalls bleibt der Plan ein Dokument, das bei einem Vorfall niemand umsetzt.

Als Kriterien können Sie ISO/IEC 27001:2022 heranziehen, die Anforderungen an ein Informationssicherheitsmanagementsystem festlegt; „System“ bezeichnet hier das Management und nicht nur die zu prüfende Anwendung; die Erläuterung der BSI Group zur Norm nennt 93 Informationssicherheitsmaßnahmen und vier Bereiche: organisatorische, personenbezogene, physische und technologische Maßnahmen. Vereinbaren Sie, welche Anforderungen das Audit anhand welcher Nachweise bewertet, denn der Verweis auf die Norm in der Preiskalkulation sagt noch nicht, ob Sie eine Bewertung des Managementsystems oder lediglich eine technische Prüfung beauftragen, deren Ergebnisse später in ein umfassenderes Audit einfließen; halten Sie diese Entscheidung vor Arbeitsbeginn schriftlich fest.

Eine weitere Grundlage bieten die CIS Controls v8.1 mit 18 Maßnahmengruppen, die Bereiche vom Verzeichnis der Unternehmensressourcen bis zu Penetrationstests abdecken und insgesamt 153 Schutzmaßnahmen umfassen. CIS beschreibt die CIS Implementation Group 1 (IG1) als grundlegende Cyberhygiene mit 56 Schutzmaßnahmen; geben Sie deshalb im Auftrag auch die ausgewählte Gruppe an und nicht nur den Namen des Rahmenwerks. Verlangen Sie, dass der Bericht jede bewertete Anforderung mit dem erhaltenen Nachweis und dem festgestellten Mangel verknüpft, damit nach der Behebung genau dieselbe Bedingung geprüft werden kann, anstatt zwei allgemeine Bewertungen miteinander zu vergleichen.

Wann das Gesetz ein IT-Sicherheitsaudit verlangt

In Deutschland müssen besonders wichtige und wichtige Einrichtungen die Maßnahmen nach § 30 BSI-Gesetz (BSIG) umsetzen und ihre Einhaltung dokumentieren; eine allgemeine Pflicht zu regelmäßigen externen Audits folgt daraus nicht. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) kann nach § 61 BSIG einzelnen besonders wichtigen Einrichtungen Audits, Prüfungen oder Zertifizierungen durch unabhängige Stellen aufgeben, ohne dass dies einen Verdacht auf Verstöße voraussetzt. Gegenüber wichtigen Einrichtungen sind solche Maßnahmen nach § 62 dagegen nur zulässig, wenn Tatsachen die Annahme einer Pflichtverletzung rechtfertigen. Von anderen besonders wichtigen Einrichtungen kann das BSI frühestens drei Jahre nach dem Inkrafttreten am 6. Dezember 2025 Nachweise verlangen. Bei zugelassenen Krankenhäusern ist dies frühestens fünf Jahre nach Inkrafttreten möglich, sofern eine Rechtsverordnung nach § 56 Absatz 6 keinen früheren Zeitpunkt festlegt. Das BSI kann Anforderungen an die prüfenden Stellen veröffentlichen und selbst prüfen, auch mithilfe eines qualifizierten unabhängigen Dritten. Für seine eigene Prüfung erhebt es nur dann Gebühren und Auslagen bei der Einrichtung, wenn es aufgrund von Anhaltspunkten für berechtigte Zweifel an der Einhaltung von § 30 Absatz 1 tätig geworden ist. Eine regelmäßige Nachweispflicht trifft hingegen Betreiber kritischer Anlagen: Nach § 39 müssen sie die Umsetzung der Maßnahmen nach §§ 30 und 31 durch Sicherheitsaudits, Prüfungen oder Zertifizierungen gegenüber dem BSI belegen und auch festgestellte Sicherheitsmängel übermitteln. Den Termin setzt das BSI im Benehmen mit dem Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) fest: frühestens drei Jahre nach erstmaliger, spätestens drei Jahre nach erneuter Einstufung als Betreiber einer kritischen Anlage, danach alle drei Jahre. Der frühere Zweijahreszyklus wurde damit auf drei Jahre verlängert; registrierte Betreiber erhielten laut BSI am 8. Dezember 2025 individuelle Mitteilungen zu ihren Fristen. Nach § 5 Absatz 7 KRITIS-Dachgesetz bestimmte Betreiber sind von dieser Nachweispflicht ausgenommen. Für öffentliche Telekommunikationsanbieter und Energiebetreiber, die den §§ 5c bis 5e EnWG unterliegen, gelten diese BSI-Prüfungs- und Nachweispflichten grundsätzlich nicht; andere kritische Anlagen oder weitere erfasste Tätigkeiten können sie nach § 28 Absatz 5 wieder begründen. Die von DORA erfassten Finanzunternehmen und die in § 28 Absatz 6 genannten Telematikstellen sind von §§ 30, 31 und 39 ausgenommen. Klären Sie bei einem angebotenen Pflichtaudit deshalb Ihren Status und ob die Dokumentation nach § 30, eine BSI-Anordnung nach § 61 oder § 62 oder der dreijährliche Nachweis nach § 39 gemeint ist. In Österreich gilt seit dem 1. Oktober 2026 das NISG 2026: Wesentliche und wichtige Einrichtungen geben innerhalb von zwölf Monaten nach Eintritt der Registrierungspflicht eine Selbstdeklaration beim Bundesamt für Cybersicherheit ab; eine automatische Pflicht zu regelmäßigen externen Prüfungen besteht nicht. Eine unabhängige Prüfung ist nur auf Aufforderung der Behörde erforderlich; die erste Aufforderung ist frühestens zwei Jahre nach Inkrafttreten zulässig. Die Prüfung muss innerhalb von zwei Jahren nach der Aufforderung erfolgen; bei wesentlichen Einrichtungen gilt für die Prüfung der operativen und organisatorischen Umsetzung eine Frist von zwei Monaten. Die Einrichtung trägt die Kosten, sofern die Behörde nicht begründet anders entscheidet, und kündigt geplante Prüfungen mindestens einen Monat vorher an. In der Schweiz regeln Artikel 73a bis 79 des Informationssicherheitsgesetzes (ISG) dagegen eine Meldepflicht zur Frühwarnung, keine Auditpflicht: Die in Artikel 74b genannten Organisationen melden Cyberangriffe innerhalb von 24 Stunden nach ihrer Entdeckung dem Bundesamt für Cybersicherheit (BACS); für die Vervollständigung einer unvollständigen Erstmeldung bleiben 14 Tage.

Neben der Dokumentation verlangt § 30 BSIG von besonders wichtigen und wichtigen Einrichtungen auch Konzepte und Verfahren zur Bewertung der Wirksamkeit ihrer Risikomanagementmaßnahmen. Diese Dokumentation bleibt bei der Einrichtung und wird nicht zu einem festen jährlichen oder dreijährlichen Termin beim BSI eingereicht. Die regelmäßigen externen Nachweise nach § 39 betreffen nur Betreiber kritischer Anlagen und erfolgen alle drei Jahre. Diese Betreiber müssen außerdem nach § 31 Absatz 2 auf den für die Funktionsfähigkeit der Anlage maßgeblichen IT-Systemen, Komponenten und Prozessen Systeme zur Angriffserkennung einsetzen, die geeignete Betriebsdaten kontinuierlich und automatisch erfassen und auswerten. Ein anderes Datum betrifft allein die Einstufung der Anlage: Nach der BSI-Kritisverordnung ist der Versorgungsgrad für jedes Kalenderjahr bis zum 31. März des Folgejahres zu ermitteln; erreicht oder überschreitet er den Schwellenwert erstmals, gilt die Anlage ab dem 1. April dieses Folgejahres als kritisch. Das ist eine Schwellenwertprüfung, keine Sicherheits-Selbstbewertung. Die Verordnung tritt außer Kraft, sobald die entsprechende Verordnung nach dem KRITIS-Dachgesetz in Kraft tritt. Für die in der Durchführungsverordnung (EU) 2024/2690 genannten digitalen Anbieter gelten deren Vorgaben nach § 30 Absatz 3 BSIG vorrangig. Nach Nummer 6.5 des Anhangs müssen sie Sicherheitsprüfungen vorsehen und deren Notwendigkeit, Umfang, Häufigkeit und Art aus ihrer Risikobewertung ableiten. Erwägungsgrund 15 nennt Penetrationstests als eine mögliche Methode, etwa bei der Einrichtung eines Systems oder nach wesentlichen Änderungen; ein fester Dreijahreszyklus folgt daraus nicht. Bedrohungsorientierte Penetrationstests (TLPT) mindestens alle drei Jahre schreibt dagegen Artikel 26 DORA für die dafür von der zuständigen Behörde bestimmten Finanzunternehmen vor, wobei die Behörde die Häufigkeit anpassen kann; das ist keine Pflicht für jedes Unternehmen. In Österreich ist die Selbstdeklaration einmalig innerhalb von zwölf Monaten nach Eintritt der Registrierungspflicht beim Bundesamt für Cybersicherheit einzureichen. Die Registrierung muss innerhalb von drei Monaten ab dem 1. Oktober 2026 beziehungsweise ab dem späteren Eintritt in den Anwendungsbereich erfolgen. Eine unabhängige Prüfung setzt eine behördliche Aufforderung voraus; für die genannten digitalen Anbieter gilt ebenfalls die Durchführungsverordnung (EU) 2024/2690. In der Schweiz sieht das ISG für private Betreiber weder einen nationalen Selbstbewertungszyklus noch einen nationalen Penetrationstestzyklus vor. Für die Organisationen nach Artikel 74b gilt die Meldung eines Cyberangriffs an das BACS innerhalb von 24 Stunden nach Entdeckung, mit 14 Tagen zur Vervollständigung einer unvollständigen Erstmeldung. Wenn Ihnen die Durchführung eines „verpflichtenden Audits“ angeboten wird, lassen Sie deshalb die konkrete Pflicht und Ihren Status benennen, damit die interne Dokumentation, ein regelmäßiger Nachweis, ein risikobasierter Sicherheitstest und ein von der Aufsichtsbehörde angeordnetes externes Audit nicht als derselbe Auftrag verstanden werden.

Technischer Teil: von öffentlichen Adressen bis zum Code

Benennen Sie im technischen Prüfauftrag die öffentlichen Adressen, DNS-Einträge, offenen Dienste und TLS-Einstellungen sowie die Server- oder Cloud-Konfiguration, Webanwendungen und den Quellcode, deren Prüfung Sie erlauben, und geben Sie für jeden Teil an, ob der Anbieter Zugang zu den Einstellungen erhält oder nur das von außen Sichtbare bewertet, denn das sind unterschiedliche Aufgaben. Die NIST-Einteilung der Sicherheitstestverfahren unterscheidet die Durchsicht von Dokumenten, Protokollen und Konfigurationen von der Identifizierung und Analyse von Prüfobjekten sowie der Bestätigung von Sicherheitslücken; diese Einteilung können Sie nutzen, um die ausgewählten Methoden und das erwartete Ergebnis in der Preiskalkulation genauer zu beschreiben.

Für Webanwendungen bieten die OWASP Top 10:2025 eine gemeinsame Sprache: zehn Risikokategorien, deren erste beiden fehlerhafte Zugriffskontrolle und unsichere Konfiguration sind. Die Liste selbst prüft nichts, deshalb überträgt ein guter Auditor jede Kategorie in eine Frage zu Ihrer Anwendung: Bei der Zugriffskontrolle bedeutet das, Aktionen einer Rolle mit dem Konto einer anderen Rolle zu versuchen, bei der Kategorie unsicheres Design hingegen, einen Geschäftsprozess auszuwählen, dessen Regeln sich umgehen lassen könnten. Ergänzen Sie den OWASP-Verweis um den Prüfungsumfang, damit beiden Seiten klar ist, welche Funktionen und Benutzerrollen dieser Auftrag tatsächlich umfasst.

Sehen Sie im E-Mail-Teil eine Bewertung der SPF-, DKIM- und DMARC-Einstellungen vor und beziehen Sie dabei die Systeme ein, aus denen das Unternehmen Nachrichten versendet: Die Google-Anforderungen an Absender sehen seit dem 1. Februar 2024 vor, dass jeder Absender an Gmail-Konten SPF oder DKIM einrichtet, während Absender von mehr als 5.000 Nachrichten pro Tag SPF, DKIM und DMARC einrichten müssen. Die DMARC-Richtlinie darf „none“ lauten, bei direkten Sendungen muss die Domain im From-Feld jedoch mit der SPF- oder DKIM-Domain übereinstimmen; verlangen Sie deshalb im Auftrag eine Bewertung sowohl der Einstellungen als auch Ihrer Versandwege, statt lediglich das Vorhandensein von Domain-Einträgen abhaken zu lassen.

Der häufigste Befund in unseren Audits sind nicht installierte Updates für PHP, den CMS-Core und Software-Frameworks. Wir empfehlen deshalb, eine Übersicht der verwendeten Versionen, Plugins und Abhängigkeiten in den technischen Prüfauftrag aufzunehmen und in der Befundbeschreibung die konkrete Komponente und die erforderliche Maßnahme benennen zu lassen, damit der Entwickler eine ausführbare Aufgabe erhält und nicht nur einen allgemeinen Hinweis auf eine veraltete Website. Wenn es Ihnen vor allem darum geht, was Benutzer im System tun dürfen, reicht eine Versionsübersicht nicht aus: Dann sind auch Zugriffskontrolltests und Tests der Geschäftslogik erforderlich. Wir haben kritische Fehler erlebt, durch die jeder Benutzer Administratorrechte erlangen konnte und deren Behebung schließlich eine vollständige Neuprogrammierung des Systemkerns erforderte; eine Versionsübersicht hätte einen solchen Fehler nicht gefunden.

Die Frage, was ein Benutzer tun darf, ist eine andere als die nach den installierten Versionen, und für jede braucht der Bericht einen eigenen Nachweis. NIST definiert das Scannen nach Sicherheitslücken als Verfahren zur Identifizierung von Hosts, ihren Merkmalen und den zugehörigen Sicherheitslücken; in unserer automatisierten Sicherheitsprüfung ist das Scannen dagegen einer der technischen Arbeitsschritte. Kennzeichnend für einen Penetrationstest nach der NIST-Erläuterung ist die Nachbildung realer Angriffe, um Möglichkeiten zur Umgehung von Schutzmechanismen und häufig auch Kombinationen von Sicherheitslücken zu finden, die weitergehenden Zugriff ermöglichen. Die Auswahl des Tests behandeln wir ausführlicher im Artikel über den Penetrationstest; für den Auditauftrag ist hier entscheidend festzulegen, welche Mängel der Anbieter lediglich suchen und bei welchen er innerhalb der vereinbarten Grenzen die praktische Ausnutzung nachweisen soll und welche Handlungen bewusst außerhalb des Auftrags bleiben.

Der Auditablauf: vom Auftrag bis zum Nachtest

Beginnen Sie mit einer schriftlichen Beschreibung des Umfangs des Audits, die die zu prüfenden Systeme, Anwendungen, Adressen und Benutzerrollen benennt und ausdrücklich festhält, was in diesem Auftrag nicht geprüft wird, und ergänzen Sie Ziel und Grenzen der Arbeit: welche Handlungen Sie erlauben, in welcher Umgebung sie stattfinden, wer die Prüfung stoppen darf und wer bei unerwarteten Situationen zu kontaktieren ist; vereinbaren Sie beispielsweise bei einem Bestellsystem gesondert, wie Aktionen geprüft werden, die sonst eine echte Bestellung auslösen würden. Diese Vereinbarung muss auch Ihr Systembetreuer lesen, damit erlaubte Handlungen, Zugänge und Ansprechpersonen vor Beginn der technischen Arbeit abgestimmt sind.

Bereiten Sie vor Arbeitsbeginn die Dokumente und Gesprächspartner in dem Umfang vor, den der Auftrag erfordert: für den organisatorischen Teil Richtlinien, Beispiele der Rechtevergabe, Aufzeichnungen zur Wiederherstellung von Backups und den Incident-Response-Plan, für den technischen Teil eine Systembeschreibung und die vereinbarten Zugänge; halten Sie dabei auch fest, was noch fehlt. Wenn Sie eine Kopie prüfen lassen, dokumentieren Sie deren Unterschiede zum produktiv genutzten System und vereinbaren Sie, wie diese im Bericht dargestellt werden, damit später erkennbar ist, auf welche Umgebung sich die Ergebnisse beziehen und welche Fragen offenblieben, weil Dokumente, Zugänge oder die betreffende Funktion nicht verfügbar waren. Vereinbaren Sie für die technische Arbeit konkrete Testzeiten und Kommunikationswege und legen Sie für die Dokumentenbewertung eine Frist fest, bis zu der Ihre Kollegen Ergänzungen einreichen können, damit das Ergebnis klar zwischen Geprüftem und noch nicht Bestätigtem unterscheidet.

Wenn der Anbieter während der Arbeit ein erhebliches Problem entdeckt, verlangen Sie dessen Meldung auf dem vereinbarten Weg, während die übrige Arbeit weiterläuft, ohne den Abgabetermin des vollständigen Berichts abzuwarten. Vereinbaren Sie auch, wer über weitere Tests an dieser Stelle entscheidet und wie erteilte Genehmigungen oder Einschränkungen dokumentiert werden, denn diese Entscheidungen werden benötigt, um zu erklären, wie weit sich der konkrete Befund bestätigen ließ.

Im Zeitplan muss auch Platz für die Behebung sein

Ein Audit mit unserem System dauert einige Tage, die eigentliche Arbeit am manuellen Audit dagegen je nach Umfang des Audits 1–3 Wochen; bis zu ihrem Beginn kann Wartezeit entstehen, da dieser von der Auslastung des Auditors abhängt. Die Leistungsseite nennt für die gesamte Durchführung eine Spanne von 1–60 Tagen; verstehen Sie diese Angaben deshalb nicht als eine einheitliche garantierte Frist und stimmen Sie vor der Beauftragung Startdatum, Berichtsübergabe und Nachtest ab. Wenn ein Kunde oder eine Ausschreibung einen Termin vorgibt, planen Sie auch Zeit für die Bewertung und Behebung der Befunde sowie für die Antworten Ihres Teams auf Rückfragen ein, denn der Abschluss der Prüfung und der gewünschte Termin für die Mängelbeseitigung sind unterschiedliche Planungspunkte.

Unser Angebot für das manuelle Expertenaudit umfasst einen Nachtest innerhalb von 30 Tagen nach den Korrekturen. Damit Sie ihn sinnvoll nutzen können, vereinbaren Sie bei der Berichtsübergabe, wer jeden Befund behebt, wer die Fertigstellung meldet und welche Nachweise der Anbieter erneut prüft; Umfang und Vergütung der Korrekturen klären Sie gesondert, denn der Auditpreis ist keine Vereinbarung über sämtliche nachfolgenden Entwicklungsarbeiten. Sie können die Korrekturen mit Ihrem eigenen Team umsetzen und anschließend von uns prüfen lassen oder uns damit als gesonderten Auftrag betrauen, den wir nach dem Bericht kalkulieren. Verlangen Sie im Nachtestbericht eine Unterscheidung zwischen behobenen, zurückgestellten und noch nicht erneut geprüften Mängeln sowie die Angabe des zugrunde gelegten Systemstands, damit Ihr Team und der Berichtsempfänger zu jedem ursprünglichen Befund dieselbe verständliche Antwort erhalten.

Was Sie im Auditbericht verlangen sollten

Verlangen Sie am Anfang des Berichts eine für die Geschäftsleitung verständliche Übersicht über Prüfungsziel, erfasste Systeme und wichtigste Befunde, damit sich über Arbeiten und Ressourcen entscheiden lässt, ohne das gesamte technische Material zu lesen, und lassen Sie dort auch die Grenzen der Prüfung benennen. Wenn der Quellcode nicht zugänglich war oder eine Benutzerrolle nicht betrachtet wurde, sollte das ausdrücklich gesagt werden, statt die Leser darüber rätseln zu lassen, was die kurze Bewertung des Systemzustands bedeutet; beurteilen Sie eine solche Übersicht danach, ob Ihre Führungskraft daraus die nächste Entscheidung, die verantwortliche Person und die noch offene Frage benennen kann.

Verlangen Sie für jeden technischen Befund die betroffene Stelle im System, die Umstände seiner Entdeckung, die verwendete Benutzerrolle, eine Beschreibung zur Wiederholung der Schritte und einen Ergebnisnachweis; bei einer organisatorischen Abweichung sollte neben dem Verweis auf die Anforderung das Dokument oder Praxisbeispiel genannt werden, auf dem die Bewertung beruht. Aus der Korrekturempfehlung muss hervorgehen, was genau geändert werden soll; konkretisieren Sie deshalb eine Formulierung wie „Zugriffe in Ordnung bringen“ bis hin zu den Rechten und der Funktion, die Ihr Entwickler ändern muss, und geben Sie das erwartete Verhalten nach der Korrektur an, damit der Bericht sowohl zur Aufgabenübergabe als auch zur späteren Kontrolle dient, ohne dass jeder weitere Leser die Absicht des Auditors neu entschlüsseln muss.

Wenn der Bericht das Common Vulnerability Scoring System (CVSS) verwendet, verlangen Sie auch die Angabe der Version: FIRST veröffentlicht CVSS, darunter Version 4.0, deren Schweregradskala die Bezeichnungen „keiner“ (0,0), „niedrig“ (0,1–3,9), „mittel“ (4,0–6,9), „hoch“ (7,0–8,9) und „kritisch“ (9,0–10,0) umfasst; die Verwendung dieser sprachlichen Bezeichnungen ist optional. Verlangen Sie neben der Zahl eine Begründung und eine Erläuterung für den Betrieb Ihres Unternehmens, etwa welche Tätigkeit oder welchen Datenbestand der konkrete Befund betrifft und warum diese Reihenfolge der Behebung empfohlen wird, damit Sie die Priorität anhand der beschriebenen Umstände und nicht nur anhand der Zahl besprechen können.

Unsere Erfahrung mit solchen kritischen Fehlern nutzen wir, um eine klare Beschreibung der Folgen zu verlangen, nicht um zu behaupten, jede Website müsse umgebaut werden: Der Bericht muss zwischen einer gezielten Korrektur und einem Problem unterscheiden können, dessen Lösung eine Überprüfung der grundlegenden Systemfunktionsweise erfordert. Wenn der Bericht eine umfassende Überarbeitung vorsieht, lassen Sie zeigen, welche Nachweise diese Empfehlung stützen, was sich einzeln beheben lässt und welche Frage ungelöst bleibt, wenn das Unternehmen nur einen Teil der vorgeschlagenen Arbeiten auswählt.

Verlangen Sie die Datei mit den unbearbeiteten Scanner-Ergebnissen als Anhang, wenn Ihr technisches Team sie benötigt, knüpfen Sie die Abnahme des Berichts jedoch an die Nachweise, Prioritäten und umsetzbaren Korrekturempfehlungen, die Sie für Ihren Auftrag erwarten; wählen Sie die Zeilenzahl nicht als Qualitätsmaßstab. Bitten Sie den Anbieter, einen Befund von Anfang bis Ende zu erläutern: wie er festgestellt wurde, was das Ergebnis belegt, wie er Ihr System betrifft und wie nach den Änderungen seine Behebung überprüft wird; außerdem soll er alles benennen, was in dieser Schlussfolgerung noch eine Annahme ist. Eine solche Durchsicht schafft eine konkrete Grundlage für die Berichtsabnahme und die Verteilung der weiteren Arbeit.

Warum sich Auditpreise so stark unterscheiden

Die Preise unterscheiden sich hauptsächlich deshalb, weil Angebote unterschiedlich viele Systeme und eine unterschiedliche Prüfungstiefe abdecken: Automatisiertes Scannen und eine Versionsübersicht kosten einige Hundert Euro, während manuelle Zugriffskontrolltests und Tests der Geschäftslogik, ein Sourcecode Review (manuelle Quellcodeprüfung) und ein Nachtest mehrere Arbeitstage eines Experten erfordern. Bei unserem Website-Sicherheitsaudit kostet die automatisierte Sicherheitsprüfung je nach Umfang 89–890 € und ist für WordPress-, Laravel-, Drupal-, Joomla- und Moodle-Systeme vorgesehen. Das Angebot umfasst automatisiertes Scannen nach Sicherheitslücken, die Prüfung von Versionen, Plugins und Abhängigkeiten, die Bewertung der Konfiguration und Servereinstellungen sowie einen Bericht mit Befunden und Prioritäten; nutzen Sie diese Inhalte beim Preisvergleich mit anderen Angeboten und klären Sie, welche Ihrer Installationen geprüft werden. Betrachten Sie den unteren Betrag der Spanne im Zusammenhang mit dem vereinbarten Prüfumfang, damit Sie den Preis für die Prüfung einer einzelnen Website nicht auf die gesamte Systemlandschaft des Unternehmens übertragen, deren Grenzen der Anbieter noch nicht bewertet hat.

Unser manuelles Expertenaudit ist ab 3.500 € verfügbar und umfasst eine manuelle Prüfung nach den OWASP Top 10, Zugriffskontrolltests und Tests der Geschäftslogik auf Umgehungsmöglichkeiten, ein Sourcecode Review und einen autorisierten Penetrationstest. Das Sourcecode Review ist für Laravel, WordPress und individuell entwickelte Lösungen vorgesehen; im Bericht ordnen wir die Befunde nach dem tatsächlichen Risiko und ergänzen jeweils eine Korrekturempfehlung, außerdem ist ein Nachtest nach den Korrekturen enthalten. Die Angabe „ab“ gilt auch dann, wenn Ihr System nur eine öffentliche Adresse hat, denn für die Preiskalkulation müssen Funktionen, Rollen und zu prüfender Code noch abgestimmt werden.

Eine vollständige Prüfung mit unserem System kostet üblicherweise 500–800 €. Diesen Betrag sehen wir innerhalb der Preisspanne der automatisierten Sicherheitsprüfung am häufigsten; er ist kein gesonderter Preis für eine gemeinsame Bewertung des Unternehmensmanagements, sämtlicher Systeme und der Zertifizierung, weshalb Sie das Wort „vollständig“ auf den konkret vereinbarten technischen Prüfumfang beziehen sollten. Für die meisten Websites empfehlen wir regelmäßige automatisierte Sicherheitsprüfungen, die sich häufig wiederholen lassen, und ein manuelles Expertenaudit, wenn das System Zahlungen oder personenbezogene Daten verarbeitet oder geschäftskritisch ist, denn Fehler bei Zugriffsrechten und die Umgehung von Geschäftsregeln findet nur ein Mensch; in der Praxis bewähren sich regelmäßige automatisierte Sicherheitsprüfungen und ein manuelles Audit pro Jahr.

Dieser Unterschied hilft auch im Budgetgespräch: Wenn Sie Antworten zu Website-Komponenten und Einstellungen benötigen, verlangen Sie eine Kalkulation für diese Aufgabe; wenn dagegen die Umgehung von Benutzerrechten oder Geschäftsregeln die zentrale Frage ist, nehmen Sie die entsprechenden manuellen Tests auf und lassen Sie den Anbieter deren Aufwand gesondert bewerten.

Erstellen Sie für den Vergleich eine einheitliche Beschreibung der Systeme, Anwendungen, Benutzerrollen und, falls auch ein organisatorischer Teil erforderlich ist, der Unternehmensstandorte und bitten Sie anschließend um eine getrennte Aufstellung automatisierter und manueller Tätigkeiten. Stellen Sie sich eine Kalkulation nur für die öffentliche Website und eine zweite für dieselbe Website einschließlich Kundenbereich, Administration und Quellcode vor: Klären Sie vor dem Vergleich der Beträge die Grenzen jedes Angebots. Halten Sie für jeden Teil auch die erforderlichen Zugänge, die ausgewählten Konformitätskriterien und den Berichtsempfänger fest, denn so geben Sie dem Anbieter eine konkrete Kalkulationsgrundlage und sich selbst die Möglichkeit, eine ausgelassene Aufgabe zu erkennen.

Klären Sie gesondert, ob der Preis die Erläuterung der Befunde für Ihren Entwickler, deren Zuordnung zu den Anforderungen der ausgewählten Norm und einen Nachtest umfasst und wo die Auditarbeit endet und die Entwicklung der Korrekturen beginnt; wir empfehlen außerdem, bei der Auditbudgetplanung auch über die Behebung der festgestellten Mängel zu entscheiden. Wenn sich die Preise auch bei Angeboten gleichen Umfangs noch erheblich unterscheiden, bitten Sie die Anbieter, ihre Arbeit und deren Grenzen anhand einer konkreten Funktion wie der Änderung eines Benutzerzugriffs zu erläutern, statt zusätzliche Leistungsnamen aufzuzählen; so können Sie nach konkretem Ergebnis und Verantwortung auswählen, ohne sich auf das Versprechen umfassender Sicherheit zu verlassen.

Wann ein Unternehmen ein IT-Sicherheitsaudit benötigt

Wir empfehlen, ein Audit zu beauftragen, wenn das Unternehmen eine konkrete Sicherheitsentscheidung treffen oder einen überprüfbaren Nachweis vorlegen muss, und bereits zu Beginn festzuhalten, ob sich die Entscheidung auf das Management, den technischen Zustand oder beides bezieht. Wenn NIS2 der Anlass ist, klären Sie zunächst Ihren Status und die anwendbaren Anforderungen, auch mithilfe unseres Artikels über NIS2 und seinen Anwendungsbereich, und formulieren Sie anschließend den Prüfauftrag. Die Reihenfolge ist hier entscheidend: Klären Sie vor der Auswahl einer Leistung, ob die Anforderung anwendbar ist und welcher Nachweis benötigt wird, damit die Beauftragung eines technischen Berichts nicht Ihre einzige Antwort auf eine Frage bleibt, bei der auch die Verantwortlichkeiten und Prozesse des Unternehmens zu bewerten sind. Wenn die Website weder Benutzerkonten noch Zahlungen oder die Verarbeitung personenbezogener Daten umfasst und niemand einen Nachweis verlangt, ist ein umfassendes Audit üblicherweise nicht erforderlich: Installieren Sie zunächst Updates; danach reicht eine automatisierte Sicherheitsprüfung.

Wenn ein Versicherer oder Kunde die Prüfung verlangt, bitten Sie um eine Präzisierung des erwarteten Ergebnisses und übergeben Sie dem Anbieter den Anforderungstext selbst; trennen Sie beispielsweise die Frage nach Mitarbeiterschulungen oder der Prüfung einer Backup-Wiederherstellung von der Anforderung, die Zugriffsrechte der Anwendung zu prüfen, und bereiten Sie entsprechende Nachweise für die Antworten vor. Wenn ein Lieferantenfragebogen die Bestätigung eines umfassenderen Sicherheitsprozesses verlangt, als Ihr technisches Audit abdeckt, stimmen Sie mit dem Kunden die zusätzlichen Informationen ab und benennen Sie im Unternehmen eine Person, die sie zusammenträgt, statt die Aussagekraft des technischen Berichts auszuweiten; klären Sie zugleich, ob der Empfänger den Bericht selbst, Antworten auf konkrete Fragen oder eine andere Nachweisform erwartet und welche Frist gilt.

Bewahren Sie bei einer Ausschreibung die geforderte Prüfungsart und die Qualifikationsanforderungen an den Anbieter genau im Wortlaut des Auftraggebers auf und klären Sie Unklarheiten vor der Preisanfrage, damit das Angebot nach Arbeitsbeginn nicht umgeschrieben werden muss. Die Auswahl behandeln wir ausführlicher im Artikel über die in einer Ausschreibung verlangte Sicherheitsprüfung; zur Vorbereitung des technischen Prüfauftrags können Sie uns den Wortlaut der Anforderung und eine Systembeschreibung senden. Geben Sie auch den Abgabetermin, die verfügbare Dokumentation und die auf Ihrer Seite für Korrekturen zuständige Person an, denn das Gespräch über die Durchführung der Prüfung muss neben der Berichtserstellung auch berücksichtigen, ob Ihr Team bis zum benötigten Termin mit den Ergebnissen arbeiten kann.

Nach einem Vorfall und zwischen geplanten Prüfungen

Nach einem Vorfall empfehlen wir, den Auditauftrag an der konkreten offenen Frage auszurichten: Behebt die Korrektur das festgestellte Problem, muss in einer anderen Funktion nach einem ähnlichen Zugriffsfehler gesucht werden und wie wird das Unternehmen die Einhaltung des betreffenden Ablaufs künftig überprüfen? Übergeben Sie dem Anbieter eine Beschreibung der bekannten Ereignisse und trennen Sie bestätigte Fakten von Annahmen. Wenn Sie den Ablauf des Vorfalls aufklären möchten, benennen Sie auch diese Arbeit gesondert und vereinbaren Sie ihr Ergebnis, ohne anzunehmen, dass ein allgemeines Website-Audit automatisch alle Fragen zum Vorfall beantwortet; erhalten Sie bei den zu prüfenden Korrekturen zugleich die Verbindung zu den ursprünglichen Befunden, damit Sie nach den Änderungen sagen können, welches Problem Sie genau wie erneut geprüft haben.

Unsere Kunden beauftragen üblicherweise ein- oder zweimal im Jahr ein Audit; das ist eine Beobachtung aus unserer Erfahrung und kein für alle Unternehmen festgelegtes Intervall. Wir empfehlen, neben dem nächsten Termin auch Änderungen in Ihren Plan aufzunehmen, nach denen Sie den Prüfungsumfang erneut bewerten, etwa eine neue Benutzerrolle, eine neu programmierte Zugriffsfunktion oder einen gewechselten Lieferanten mit Systemrechten. Beauftragen Sie die verantwortliche Person damit, diese Änderungen mit dem Umfang des vorherigen Audits abzugleichen und den konkret zu prüfenden Teil vorzuschlagen; übernehmen Sie außerdem ungelöste Befunde aus dem vorherigen Bericht zusammen mit den Entscheidungen über deren Zurückstellung in den nächsten Prüfauftrag, damit die neue Prüfung von der bekannten Situation ausgeht.