Compliance ist kein Dokumentationsproblem

Wer in einem mittelständischen Unternehmen für Informationssicherheit zuständig ist, kennt das Szenario: Ein Audit steht an, die Ordner werden hervorgeholt, PDFs aktualisiert, Verantwortlichkeiten nachgetragen. Das Ergebnis ist ein Dokumentenpaket, das in seiner Vollständigkeit beeindruckend wirkt. Und das dennoch keine einzige Frage beantwortet, die im Ernstfall tatsächlich zählt.

Die Grundannahme hinter diesem Vorgehen ist älter als die meisten der Frameworks, die es begleiten: Compliance ist ein Zustand, der sich durch Beschreibung herstellen lässt. Man schreibt auf, was gelten soll – und damit gilt es. Diese Annahme ist nicht absichtlich falsch. Sie ist das Ergebnis einer Zeit, in der Organisationen tatsächlich überschaubar waren, Bedrohungslagen stabil und Auditzyklen lang. In dieser Welt war das Dokument ein legitimes Steuerungsinstrument. Es fixierte Einigung, machte Verantwortung sichtbar und erzeugte eine prüfbare Spur.

Das Problem ist, dass diese Welt nicht mehr existiert.

NIS-2 verlangt Nachweisbarkeit in Echtzeit. DORA definiert Resilienztests, die tatsächlich durchgeführt werden müssen, nicht bloß beschrieben. Der Cyber Resilience Act bindet Produkthersteller an Sicherheitsanforderungen, die sich über den gesamten Lebenszyklus erstrecken – inklusive Patch-Management und Schwachstellenmeldepflichten, für die kein PDF eine operative Grundlage bildet. Die Frameworks haben sich verändert. Die Compliance-Praxis in vielen Organisationen nicht.

Was dabei verloren geht, ist der Unterschied zwischen einer Anforderung, die dokumentiert ist, und einer Anforderung, die erfüllt ist. Ein ISMS-Handbuch, das beschreibt, wie Zugriffsrechte vergeben werden sollen, ist kein Zugriffsrechtesystem. Eine Richtlinie zur Incident-Response ist kein Incident-Response-Prozess. Ein Asset-Inventar als Excel-Tabelle ist, drei Monate nach dem letzten Update, keine verlässliche Grundlage für irgendetwas. Das Dokument beschreibt eine Wirklichkeit, die es selbst nicht erzeugt.

Dieser Kategorienfehler ist systematisch. Er erklärt, warum Unternehmen nach bestandenen Audits trotzdem kompromittiert werden. Er erklärt, warum dieselben Findings in Folgeprüfungen wiederkehren. Und er erklärt, warum gut ausgearbeitete Frameworks wie ISO 27001 in der Praxis zu Zertifizierungsprojekten werden, die nach Abschluss wieder in Schubladen verschwinden.

Der Ausweg ist konzeptionell einfacher als er klingt, aber praktisch anspruchsvoll: Compliance muss maschinenlesbar werden. Nicht als technische Spielerei, sondern weil nur maschinenlesbare Anforderungen kontinuierlich gegen maschinenlesbare Zustände geprüft werden können. Ein Kontroll-Statement, das in natürlicher Sprache beschreibt, dass privilegierte Accounts überwacht werden sollen, lässt sich nicht automatisiert verifizieren. Dasselbe Statement, formalisiert als Relation zwischen einer Kontrolle, einem Asset-Typ, einer Messmethode und einem Schwellenwert, kann täglich gegen die tatsächliche Umgebung abgeglichen werden.

Das ist der Kern dessen, was wir mit Executable Compliance meinen. Nicht die Ablösung von Frameworks durch Code – ISO 27001 bleibt ISO 27001, NIS-2 bleibt NIS-2. Aber die Übersetzung dieser Anforderungen in eine Darstellungsform, die zwischen „beschrieben" und „erfüllt" unterscheiden kann. Die einen Compliance-Score nicht aus Checklisten aggregiert, die jemand manuell ausgefüllt hat, sondern aus Zuständen, die das System selbst erhebt. Die bei Änderungen in der Infrastruktur oder im regulatorischen Umfeld nicht einen neuen Dokumentationszyklus auslöst, sondern eine Delta-Analyse.

Dokumente haben ihren Platz. Policies müssen kommuniziert werden, Entscheidungen müssen begründet sein, Audits brauchen Nachweise. Aber das Dokument ist das Ergebnis eines Compliance-Prozesses, nicht sein Fundament. Wer das verwechselt, baut auf Sand – und bemerkt es erst, wenn der nächste Incident zeigt, dass die beschriebene Wirklichkeit und die tatsächliche nichts miteinander zu tun hatten.

Die eigentliche Frage ist nicht, ob ein Unternehmen ein ISMS hat. Sondern ob das ISMS weiß, was gerade im Netz passiert.