Audit-Begleitung im IT-Grundschutz: Referenzdokumente, Prüfschema und Auditbericht

Problem in der Praxis

Viele Institutionen behandeln das Audit als punktuelles Ereignis und tragen kurz vor dem Termin Dokumente zusammen, vereinheitlichen Versionen und schließen Lücken notdürftig. Das funktioniert selten, weil die Prüfung nicht die Schönheit einzelner Dokumente bewertet, sondern ihre innere Konsistenz und ihre Übereinstimmung mit der Realität.

Typisch ist der Bruch zwischen Papierlage und Betrieb: Der Schutzbedarf ist behauptet, aber nicht begründet, oder der IT-Grundschutz-Check weist eine Anforderung mit dem Umsetzungsstatus "ja" aus, doch vor Ort lässt sich die Maßnahme nicht zeigen. Der Check kennt dafür vier gültige Statuswerte - "ja", "teilweise", "nein" und "entbehrlich"; eine Bezeichnung wie "umgesetzt" gehört nicht dazu. Spätestens in der Vor-Ort-Prüfung wird das sichtbar, denn dort wird am Zielobjekt geprüft. Hinzu kommt Verwirrung über die Verfahren: Testat nach Basis-Absicherung und Zertifikat nach ISO 27001 auf Basis von IT-Grundschutz sind unterschiedliche Produkte mit unterschiedlicher Prüftiefe, Nachweispflicht und Ausstellung.

CISO-Einordnung

Es lohnt, die beiden Wege sauber zu trennen. Das Testat nach Basis-Absicherung erteilt der beim BSI zugelassene Auditor selbst, nicht die Zertifizierungsstelle; seine Gültigkeitsdauer richtet sich nach dem jeweils aktuellen Zertifizierungs- und Auditierungsschema des BSI, und es fordert in der Regel keine Risikoanalyse. Das Zertifikat nach ISO 27001 auf Basis von IT-Grundschutz erteilt dagegen die Zertifizierungsstelle des BSI; der Auditbericht geht an das BSI, das Verfahren ist anspruchsvoller und in einen mehrjährigen Zyklus mit Überwachungsaudits und Re-Zertifizierung eingebettet - mit den Basis- und Standard-Anforderungen der modellierten Bausteine als Maßstab und einer Risikoanalyse bei hohem oder sehr hohem Schutzbedarf.

Beiden gemeinsam ist die Grundlogik: Der Auditor prüft stichprobenbasiert die Vollständigkeit, Korrektheit und Wirksamkeit der dokumentierten Maßnahmen gegenüber den modellierten Anforderungen. Das Audit ist ein Nachweisverfahren, kein Sicherheitsgutachten.

Umsetzungsperspektive

Die Referenzdokumente sind der Kern. Sie werden dem Auditor elektronisch und geordnet bereitgestellt, sind Bestandteil des Auditberichts und werden über eine begleitende Liste mit Version, Datum und Änderungsstand geführt, die bei Überwachungsaudits und Re-Zertifizierung fortzuschreiben ist. Inhaltlich folgen sie der Logik der Sicherheitskonzeption: von der Sicherheitsleitlinie und den steuernden Richtlinien über Strukturanalyse, Schutzbedarfsfeststellung, Modellierung und die Ergebnisse des IT-Grundschutz-Checks bis zur Risikoanalyse und zum Realisierungs- beziehungsweise Risikobehandlungsplan. Verlangt werden dabei neben der Leitlinie auch Richtlinien, die das Managementsystem steuern - etwa zur Lenkung von Dokumenten, zur internen ISMS-Auditierung und zu Korrektur- und Vorbeugungsmaßnahmen. Der Realisierungsplan verdient besondere Aufmerksamkeit der Leitung: Er dokumentiert verbleibende Defizite und Risiken mit Ressourcen und Fristen und wird von der Institutionsleitung unterschrieben. Auch offene Defizite zu Basis-Anforderungen aus dem IT-Grundschutz-Check werden hier überführt und terminiert - das ist der vorgesehene Weg, nicht ein Fehler. Die eigentliche Grenze ist eine andere: Basis-Anforderungen dürfen nicht als entbehrlich eingestuft werden, und sie müssen für ein Testat oder eine Zertifizierung tatsächlich erfüllt sein - also vor Abschluss geschlossen und nicht dauerhaft offen oder risikoakzeptiert.

Das Prüfschema läuft zweiphasig: erst Dokumentenprüfung, dann Vor-Ort-Prüfung. Da eine vollständige Prüfung des Informationsverbunds wirtschaftlich nicht darstellbar ist, arbeitet der Auditor mit dokumentiertem Prüfplan und begründeter, risikoorientierter Stichprobe und nutzt mehrere Methoden - von Dokumentationsdurchsicht und Interviews über Inaugenscheinnahme und Begehung bis zur Beobachtung von Arbeitsabläufen. Jeder Prüfaspekt wird als korrekt, teilweise oder mangelhaft bewertet; daraus werden Empfehlung, geringfügige oder schwerwiegende Abweichung abgeleitet. Das Votum bezieht sich dabei auf den Stand nach möglicher Nachbesserung. Abweichungen erhalten Fristen; bleibt eine schwerwiegende Abweichung unbehoben, kann das Zertifikat ausgesetzt oder entzogen werden, und das BSI kann Auflagen aussprechen.

Der Auditbericht folgt einem festen Muster, das nicht verändert werden darf, damit Ergebnisse vergleichbar bleiben. Er führt durch Dokumentenprüfung mit Einzelvoten, Prüfplan, Vor-Ort-Audit und Gesamtvotum und muss Prüfschritte nachvollziehbar belegen. Beim BSI-Zertifikat unterschreibt der Auditteamleiter das Gesamtvotum erst nach Freigabe durch die Prüfbegleitung des BSI.

Typische Fehler

1. Das Audit wird als Termin behandelt, nicht als Ergebnis eines laufenden Nachweisbetriebs.
2. Referenzdokumente sind in sich widersprüchlich, weil Struktur, Schutzbedarf, Modellierung und Check nicht zueinander passen.
3. Der IT-Grundschutz-Check beschreibt Soll-Zustände statt der vor Ort zeigbaren Umsetzung.
4. Basis-Anforderungen werden fälschlich als entbehrlich eingestuft oder bleiben im Realisierungsplan dauerhaft offen, statt termingerecht geschlossen zu werden.
5. Versionsstände der Prüfgrundlagen werden nicht verfolgt, und die Liste der Referenzdokumente wird nach der Erstzertifizierung nicht fortgeschrieben.

Risiken und Trade-offs

Zu viel Dokumentation erzeugt Pflegelast und neue Inkonsistenzen, zu wenig lässt Nachweise und Begründungen vermissen. Der Steuerungspunkt ist Nachvollziehbarkeit, nicht Umfang.

Der Zuschnitt des Untersuchungsgegenstands ist ein echter Trade-off: Ein kleiner Geltungsbereich erleichtert das Erstaudit, kann aber die Aussagekraft des Zertifikats schwächen; zugleich muss er eine geeignete Mindestgröße besitzen. Auch die Stichprobenlogik hält das Audit zwar wirtschaftlich, verlagert aber Verantwortung in den Betrieb: Da der Auditor risikoorientiert vertieft, trägt nur ein durchgängig konsistenter Informationsverbund - punktuelle Vorzeigeobjekte genügen nicht.

Entscheidungspunkte

• Welches Verfahren passt zu Reife und Ziel: Testat nach Basis-Absicherung oder Zertifikat nach ISO 27001 auf Basis von IT-Grundschutz?
• Wie wird der Untersuchungsgegenstand abgegrenzt, sodass er aussagekräftig und zugleich beherrschbar bleibt?
• Wer verantwortet Pflege und Versionierung der Referenzdokumente im Regelbetrieb?
• Wie wird sichergestellt, dass der dokumentierte Umsetzungsstatus jederzeit vor Ort belegbar ist?

Praktische Empfehlungen

1. Behandeln Sie Referenzdokumente als Produkt des Regelbetriebs, nicht als Audit-Sonderaufgabe.
2. Prüfen Sie die Konzeptionskette auf innere Konsistenz: Struktur, Schutzbedarf, Modellierung, Check und Realisierungsplan müssen aufeinander verweisen.
3. Verproben Sie vor dem Audit gegen die Realität - lässt sich jede als umgesetzt gemeldete Maßnahme vor Ort zeigen?
4. Halten Sie die Prüfgrundlagen versionssicher; maßgeblich ist der Stand zu Beginn der Sichtung.
5. Verankern Sie den Realisierungsplan als Leitungsinstrument mit Ressourcen, Fristen und Genehmigung - führen Sie offene Basis-Anforderungen darin mit verbindlichen Terminen und schließen Sie sie vor Testat oder Zertifizierung, statt sie als entbehrlich einzustufen oder dauerhaft offen zu lassen.

Relevante Normreferenzen

• BSI-Standard 200-2 (IT-Grundschutz-Methodik): Referenz für die Konzeptionsartefakte, die den Referenzdokumenten zugrunde liegen.
• BSI-Standard 200-3 (Risikoanalyse auf Basis von IT-Grundschutz): Referenz für die Risikoanalyse bei hohem und sehr hohem Schutzbedarf.
• IT-Grundschutz-Kompendium: Referenz als Prüfkatalog der modellierten Anforderungen (jeweils aktuelle Edition).
• ISO/IEC 27001:2022: Referenz für die zugrunde liegenden ISMS-Anforderungen.
• BSI-Zertifizierungs- und Auditierungsschema samt Hinweisen zur Bereitstellung der Referenzdokumente: Referenz für Verfahren, Auditbericht und Nachweispflichten.