Nachweis- und Kontrollagent: Compliance-Belege als prüfbare Arbeitsakte

Mittelständische Unternehmen müssen heute an vielen Stellen belegen, dass sie ihre Informationssicherheit und ihre Prozesse im Griff haben. Großkunden verlangen Fragebögen und Zertifikate, Versicherer fragen nach Sicherheitsmaßnahmen, ein Informationssicherheits-Managementsystem nach ISO/IEC 27001 braucht laufende Nachweise, und für einen Teil der Unternehmen kommen gesetzliche Pflichten aus der NIS-2-Umsetzung hinzu.

Die Maßnahmen selbst existieren oft. Berechtigungen werden geprüft, Backups getestet, Schulungen durchgeführt. Was fehlt, ist der geordnete Beleg: Das Ticket zur Rezertifizierung liegt im einen System, das Schulungsprotokoll im anderen, die aktuelle Richtlinie in einem Ordner mit drei Versionen. Vor jedem Audit beginnt deshalb eine Suche, die Wochen bindet und trotzdem Lücken übersieht.

ISO/IEC 27001 in der Ausgabe von 2022 legt Anforderungen an ein Informationssicherheits-Managementsystem fest. Die Norm verlangt einen Risikomanagementprozess und dokumentierte Informationen, die zeigen, dass Maßnahmen umgesetzt und wirksam sind. Ob ein Unternehmen sich zertifizieren lässt, ist freiwillig; der Nachweisbedarf entsteht aber schon beim internen Betrieb eines ISMS.

In Deutschland ist das NIS-2-Umsetzungsgesetz laut BSI am 6. Dezember 2025 in Kraft getreten, umgesetzt vor allem durch eine Novelle des BSI-Gesetzes. Betroffene wichtige und besonders wichtige Einrichtungen müssen sich nach Angaben des BSI registrieren, erhebliche Sicherheitsvorfälle melden sowie Risikomanagementmaßnahmen umsetzen und dokumentieren. Die gesetzliche Registrierungsfrist ist laut BSI bereits abgelaufen. Ob ein Unternehmen betroffen ist, muss es selbst prüfen; das BSI stellt dafür eine Betroffenheitsprüfung bereit.

Der EU AI Act ergänzt diese Pflichten, sobald KI-Systeme eingesetzt werden. Nach Angaben der EU-Kommission gelten die Transparenzregeln seit August 2026, während die Pflichten für Hochrisiko-Systeme durch die sogenannte AI-Omnibus-Verordnung verschoben wurden: für Anwendungsfälle aus Anhang III ab dem 2. Dezember 2027, für in Produkte eingebettete Systeme nach Anhang I ab dem 2. August 2028. Ein Nachweisagent kann diese Termine als Fristen führen, die rechtliche Einordnung einzelner Systeme aber nicht ersetzen.

Grundlage ist ein Kontrollkatalog, den das Unternehmen selbst pflegt. Jede Kontrolle beschreibt, was regelmäßig getan wird, wer verantwortlich ist und welcher Beleg das zeigt, etwa eine quartalsweise Berechtigungsprüfung mit Bericht aus dem IAM-System und abgeschlossenem Ticket. Diesen Katalog verknüpft das Unternehmen mit den Anforderungen, die für es gelten, sodass ein Beleg mehrere Anforderungen gleichzeitig abdecken kann.

Der Agent arbeitet diesen Katalog ab. Er sucht in den angebundenen Systemen nach passenden Belegen, prüft Datum, Geltungsbereich und Vollständigkeit und schlägt eine Zuordnung vor. Stimmt etwas nicht, etwa ein Bericht ohne Freigabevermerk oder eine Richtlinie ohne Überprüfung im vorgesehenen Turnus, wird das als Befund mit Owner und Frist geführt.

Die zentrale Regel lautet: Lücken werden sichtbar gemacht, nicht simuliert geschlossen. Ein Sprachmodell kann mühelos eine plausibel klingende Richtlinie oder ein Protokoll formulieren. Genau das darf in einer Nachweisakte nicht passieren. Der Agent erzeugt deshalb keine Belege, sondern verweist ausschließlich auf vorhandene Dokumente und Datensätze, die er mit Fundstelle angibt.

Ebenso wenig bewertet der Agent, ob eine gesetzliche Pflicht erfüllt ist, oder stellt eine Konformitätsaussage aus. Solche Aussagen bleiben bei Informationssicherheitsbeauftragten, Rechtsabteilung, Geschäftsführung und externen Prüfern. Bei NIS-2 betont das BSI ausdrücklich die Verantwortung der Geschäftsleitung für Umsetzung und Überwachung der Risikomanagementmaßnahmen; diese Verantwortung lässt sich nicht an ein Werkzeug delegieren.

Nachweisquellen enthalten sensible Informationen: Schwachstellenberichte, Berechtigungslisten, Vorfallsdokumentation. Der Agent erhält deshalb ausschließlich Leserechte auf die Bereiche, die der Kontrollkatalog benennt, und eine eigene technische Identität, deren Zugriffe protokolliert werden. Sicherheitsvorfälle und Schwachstellendetails können zusätzlich auf eine lokal oder in der EU betriebene Modellumgebung beschränkt werden.

Jede Zuordnung und jede Statusänderung wird versioniert. So lässt sich bei einem Audit zeigen, wann ein Beleg erfasst, von wem er freigegeben und wann er durch einen neueren ersetzt wurde. Diese Historie ist für Prüfer oft wertvoller als die Belege selbst, weil sie zeigt, dass Kontrollen tatsächlich regelmäßig gelebt werden.