Compliance-Lexikon · Praxis
Evidence erstellen: Was Auditoren wirklich sehen wollen
Die häufigste Aussage nach einem gescheiterten Audit: "Wir haben das doch alles umgesetzt." Das Problem ist selten die Maßnahme. Es ist der Nachweis. Dieser Artikel zeigt konkret, wie gute Evidence für die drei meistgeprüften Frameworks – ISO 27001, NIS-2 und DORA – aussieht, und welche Fehler immer wieder gemacht werden.
Was gute Evidence von schlechter unterscheidet
Ein Auditor prüft Evidence nach vier Kriterien: Relevanz (belegt das Dokument genau das, was die Kontrolle fordert?), Vollständigkeit (ist der Prüfungszeitraum abgedeckt?), Authentizität (kann das Dokument nachträglich erstellt worden sein?) und Aktualität (ist der Nachweis noch gültig?).
✓ Gute Evidence
Restore-Test-Protokoll
Datum: 14.05.2026 · Tester: Max Müller · System: ERP-Datenbank · Ergebnis: Vollständige Wiederherstellung in 2:34 h · RTO-Ziel: 4 h · Unterschrift: ✓
✗ Schlechte Evidence
E-Mail: "Backup läuft"
Von: IT-Admin · Betreff: Backup okay · Text: "Backup wurde heute gemacht und funktioniert." · Kein Datum, kein System, kein Testergebnis.
✓ Gute Evidence
MFA-Aktivierungsbericht
Systemexport Azure AD · Datum: 01.06.2026 · Scope: Alle 47 Benutzerkonten · MFA aktiv: 47/47 · Export-Zeitstempel vom System generiert.
✗ Schlechte Evidence
Screenshot "MFA eingeschaltet"
Screenshot der Einstellungsseite ohne Zeitstempel, ohne Scope-Angabe, ohne Nachweis, dass alle Konten betroffen sind.
Framework-spezifische Evidence-Anforderungen
ISO 27001:2022 – Kapitel 9.1
ISO 27001 fordert "aufbewahrte Information" als Nachweis für Überwachung und Messung. Das bedeutet konkret: Für jede Kontrolle aus Annex A muss ein datiertes Dokument vorliegen, das belegt, dass die Kontrolle im Prüfungszeitraum wirksam war. Die Aufbewahrungsdauer ist im ISMS-Scope festzulegen – üblich sind drei Jahre für operative Nachweise, zehn Jahre für Vertragsunterlagen.
ISO 27001 Audit-Tipp
Zertifizierungsauditoren prüfen bevorzugt die drei Kontrollen, bei denen Unternehmen typischerweise keine Evidence haben: A.8.8 (Patch-Management), A.5.24 (Incident-Management-Vorbereitung) und A.8.16 (Monitoring-Aktivitäten). Wer für diese drei solide Evidence vorlegen kann, besteht den formalen Teil fast immer.
NIS-2 / BSIG § 30 – Wirksamkeitsnachweis
NIS-2 ist strenger als ISO 27001: Es reicht nicht, eine Maßnahme umzusetzen – sie muss nachweisbar wirksam sein. Der BSI-Prüfer erwartet für jede der zehn Art.-21-Maßnahmen ein Evidence-Dokument, das Umsetzungszeitpunkt, Verantwortlichen und Wirksamkeitsbewertung enthält. Besonders kritisch: der Restore-Test (§ 30 Abs. 2c) und die Wirksamkeitsbewertung (§ 30 Abs. 2f) werden fast immer geprüft.
DORA Art. 11 – Business Continuity Evidence
DORA verlangt für Business-Continuity-Tests einen formalen Bericht, der Testzeitraum, getestete Szenarien, Ergebnisse und identifizierte Schwachstellen dokumentiert. Anders als ISO 27001 schreibt DORA auch die Häufigkeit vor: Tests müssen "regelmäßig" stattfinden – die EBA-Guidelines konkretisieren das auf mindestens jährlich für Standard-Tests, mindestens alle drei Jahre für TLPT (Threat-Led Penetration Testing) bei systemrelevanten Instituten.
Die fünf häufigsten Evidence-Fehler
Ein Screenshot ohne Systemzeitstempel ist kein Nachweis – er könnte jederzeit erstellt worden sein. Immer Systemexporte mit automatischem Zeitstempel verwenden, oder manuelle Protokolle mit Datum und Unterschrift versehen.
Das Patch-Management-Log belegt, dass Server A gepatcht wurde – aber der Audit-Scope umfasst 12 Server. Evidence muss denselben Scope haben wie die geprüfte Kontrolle. Für jede Kontrolle muss klar sein, auf welche Systeme, Prozesse oder Personen sie sich bezieht.
Ein Auditor prüft nicht den Ist-Zustand am Audittag, sondern den Prüfungszeitraum – typischerweise die letzten 12 Monate. Wer erst kurz vor dem Audit Evidence sammelt, hat für den gesamten Prüfungszeitraum eine Lücke. Evidence muss laufend entstehen, nicht punktuell.
Eine Backup-Richtlinie, die beschreibt, wie Backups durchzuführen sind, ist keine Evidence dafür, dass Backups durchgeführt wurden. Policies sind Anforderungsdokumente. Evidence ist der Nachweis der Erfüllung. Beides wird benötigt, keines ersetzt das andere.
Evidence, die nicht mehr vorhanden ist, existiert für den Auditor nicht. Aufbewahrungsfristen müssen pro Evidence-Typ definiert und eingehalten werden – besonders bei Log-Daten, die oft nach 30 oder 90 Tagen automatisch gelöscht werden.
Evidence mit BAM strukturieren
Das BAM-Objekt CROSS-EV-01 enthält für jede Sicherheitskontrolle ein Evidence-Feld, das definiert, welcher konkrete Nachweis erwartet wird. Das eliminiert die häufigste Ursache für Evidence-Lücken: dass niemand im Vorfeld festgelegt hat, was als Nachweis gilt.
Wer NIS-2-Objekt NIS2-BC-01 (Business Continuity) öffnet, findet im Evidence-Feld: "Datiertes Restore-Test-Protokoll mit Testergebnis, RTO-Messung und Unterschrift des Verantwortlichen – mindestens einmal jährlich." Das ist keine abstrakte Anforderung, sondern eine direkt umsetzbare Vorlage für das nächste Audit-Gespräch.
CISM · Prüfungsvorbereitung
Evidence ist Prüfungsthema in CISM Domäne 1 und CISA Domäne 2.
Beide Bücher enthalten praxisnahe Szenarien zu Evidence-Anforderungen – mit der typischen ISACA-Antwortlogik erklärt.
Wer mehr darüber wissen möchte, warum Evidence strategisch wichtiger ist als Dokumentation – und was der Unterschied zwischen beiden in einem Audit bedeutet – findet das auf Ebene 3: Evidence vs. Dokumentation.