Audit und Compliance vorbereiten
Die Prüfankündigung liegt auf dem Tisch. 8 Wochen. Jetzt stellen Sie fest, was Sie nicht nachweisen können.
Compliance existiert in den meisten Unternehmen als Absicht: beschrieben in Word-Dokumenten, bekannt als internes Wissen, gelebt als Praxis ohne Beleg. Der Auditor fragt anders. Er fragt nach konkreten Nachweisen, nach Zeitstempeln, nach dokumentierten Ausnahmen und nach dem Prozess dahinter.
lennlay baut Audit-Readiness strukturell auf: definierte Baselines als versionierte Policy-Artefakte, automatisierte Compliance-Scans mit strukturierten Reports, GitOps-basierte Änderungshistorie und risikobasiertes Ausnahmen-Management. Was der Auditor sehen will, ist vorhanden.
Was der Auditor fragt. Was die meisten zeigen können.
Die klassische Lücke: Compliance als Intention dokumentiert, nicht als technischen Nachweis. Die folgenden vier Fragen sind keine Ausnahmen, sie sind der Standard.
"Welcher Härtungsstandard gilt für Ihren JBoss-Server?"
"Wir folgen internen Richtlinien."
Auditor: "Zeigen Sie mir den Nachweis."
"Wer hat wann welche Konfiguration geändert?"
"Das steht im Ticket-System... irgendwo."
"Gibt es Abweichungen vom Sollzustand? Sind diese dokumentiert?"
"Wir haben keine bekannten Abweichungen."
Auditor: "Wie wissen Sie das?"
"Was ist Ihr Prozess bei einem Security-Incident?"
"Wir haben einen Plan."
Auditor: "Wo ist der Plan? Wurde er getestet?"
Vier Kategorien. Jede mit konkreten Nachweispflichten.
Härtungsnachweis
Welcher Härtungsstandard? Welche Kontrollen angewendet? Welche Version des Benchmarks? Nicht "wir haben Härtung", sondern: CIS L1, Policy-ID 24.2, angewendet am 2025-03-15, 3 dokumentierte Ausnahmen.
Änderungshistorie
Jede Konfigurationsänderung muss nachvollziehbar sein. Wer hat was geändert, wann, warum, mit welcher Freigabe. Ohne Git-basiertes Konfigurationsmanagement bedeutet das manuelle Rekonstruktion unter Zeitdruck.
Ausnahmen-Management
Jede Security-Ausnahme braucht Dokumentation, Risikobewertung und ein Ablaufdatum. "Wir haben diese Kontrolle nicht angewendet" muss schriftlich vorliegen, mit fachlicher Begründung und Gültigkeitszeitraum.
Drift-Nachweis
Hat das System seit dem letzten Audit vom definierten Zustand abgewichen? Dafür braucht man kontinuierliches oder periodisches Scanning, keinen Point-in-time-Check eine Woche vor dem Prüftermin.
Sechs Bausteine für strukturelle Audit-Readiness
Definierte Baselines
CIS Level 1 oder Level 2 als versioniertes Policy-Artefakt pro Plattform: JBoss, Linux, Tomcat. Keine Beschreibung, sondern eine maschinenlesbare Policy mit IDs, Datum und Scope.
Automatisierter Compliance-Scan
lennlay Compliance Scanner läuft gegen produktive Instanzen und erzeugt strukturierte Reports. Keine manuellen Checklisten, sondern direkt verwendbare Ausgaben für interne Revision und externe Auditoren.
Änderungshistorie durch GitOps
Konfiguration als Code, verwaltet in Git. Jede Änderung ist ein Commit mit Autor, Zeitstempel und Beschreibung. Rollback auf jeden früheren Zustand jederzeit möglich.
Ausnahmen-Dokumentation
Risikobasiertes Ausnahmen-Management: Ausnahme-ID, betroffene Kontrolle, Risikobewertung, fachliche Begründung, Freigabedatum, Ablaufdatum. Strukturiert, nachweisbar, auditierbar.
Audit-Report-Export
Reports im Auditorenformat: Compliance-Status pro Kontrolle, dokumentierte Abweichungen, Ausnahmen mit Begründung, Remediation-Plan. Intern und extern direkt einsetzbar.
Drift-Erkennung
Kontinuierliches oder geplantes Scanning vergleicht Ist-Zustand mit der Baseline. Drift wird sichtbar, bevor der Auditor ihn findet, nicht danach.
Welche regulatorischen Anforderungen lennlay auf Plattformebene adressiert
| Framework | Zielgruppe | Was lennlay auf Plattformebene adressiert |
|---|---|---|
| NIS2 / NIS2UmsuCG | KRITIS, regulierte Sektoren | Artikel 21 technische Maßnahmen: Plattformhärtung, Schwachstellenmanagement, Logging und Nachweisführung |
| CIS Benchmarks | Alle Sektoren | Level 1 und Level 2 als operative Baseline pro Plattform mit kontrollierten, dokumentierten Ausnahmen |
| BSI IT-Grundschutz | Behörden, KRITIS | SYS.1.1, SYS.2.2, APP.3: Systemhärtung, Konfigurationsmanagement, Änderungsdokumentation |
| ISO 27001 | Alle Sektoren | Annex A: Technische Sicherheitsmaßnahmen, Zugangskontrollen, Änderungsmanagement auf Plattformebene |
| DORA | Banken, Finanzdienstleister | Artikel 9 technisches Risikomanagement: Plattformhärtung, Incident-Dokumentation, Auditierbarkeit |
| BaFin BAIT | Banken | IT-Härtung, Änderungsdokumentation, revisionssichere Nachweisführung auf Plattformebene |
| PCI-DSS | Zahlungsverkehr | TLS-Konfiguration, Zugangskontrolle, Änderungsmanagement, Härtungsnachweis pro Kontrolle |
Das 8-Wochen-Fenster ist nicht der Startpunkt. Es ist der Validierungspunkt.
Plattformhärtung und Audit-Readiness müssen im laufenden Betrieb verankert sein. Als Reaktion auf eine Prüfankündigung lässt sich strukturelle Auditierbarkeit nicht mehr aufbauen.
Das erste externe oder interne Audit steht an. Es gibt keine etablierte Baseline, keine dokumentierten Ausnahmen, keine strukturierte Änderungshistorie. Das sind drei separate Lücken, die gleichzeitig adressiert werden müssen.
Das jährliche Audit fühlt sich jedes Mal wie ein Neustart an. Nachweise werden zusammengesucht, Lücken werden überbrückt, das Team arbeitet Überstunden. Dann ist der Auditor weg und der Zyklus beginnt von vorn.
Das letzte Audit hat Lücken identifiziert. Ein Remediation-Plan ist gefordert, und beim nächsten Termin muss der Nachweis der Behebung vorliegen. Jetzt ist der Druck struktureller Natur, nicht nur terminlicher.
Beschreiben Sie uns Ihre Audit-Situation. In 15 Minuten zeigen wir, welche Lücken bestehen und wie strukturelle Audit-Readiness in Ihrer Umgebung aussieht.
Audit-Readiness einschätzen