Compliance-Lexikon · Grundbegriff
Evidence
[ˈɛvɪdəns] · auch: Audit-Nachweis, Nachweisdokument, Compliance-Beleg
In der IT-Compliance bezeichnet Evidence ein Dokument oder einen Datensatz, der belegt, dass eine Sicherheitskontrolle zu einem bestimmten Zeitpunkt tatsächlich wirksam war – nicht nur, dass sie existiert oder geplant ist.
Warum Evidence der entscheidende Unterschied ist
Die häufigste Verwechslung in der Compliance-Praxis: Ein Unternehmen implementiert eine Maßnahme und hält sie für nachgewiesen. Der Auditor sieht das anders. Implementierung und Nachweis sind zwei verschiedene Dinge.
Eine Firewall-Regel, die technisch aktiv ist, erzeugt noch keine Evidence. Evidence ist das Log, das zeigt, dass die Regel im Prüfungszeitraum aktiv war, korrekt konfiguriert war und keine unautorisierten Zugriffe durchgelassen hat. Eine Schulungspflicht im Arbeitsvertrag erzeugt keine Evidence. Evidence ist die datierte Teilnahmeliste mit Unterschriften oder der Systemauszug aus dem LMS.
Dieser Unterschied zwischen Maßnahme und Nachweis ist der häufigste Grund, warum Audits scheitern, obwohl das Unternehmen technisch compliant ist. Im Zweifel gilt: Was nicht nachgewiesen werden kann, existiert für den Auditor nicht.
Wo Evidence gefordert wird
| Framework | Referenz | Anforderung |
|---|---|---|
| ISO 27001:2022 | Kap. 9.1 | Überwachung, Messung, Analyse und Bewertung der ISMS-Leistung müssen dokumentiert und als aufbewahrte Information verfügbar sein. |
| NIS-2 / BSIG | § 30 Abs. 2 | Geeignete technische und organisatorische Maßnahmen müssen nachweisbar umgesetzt und regelmäßig auf Wirksamkeit geprüft werden. |
| DORA | Art. 11 Abs. 6 | Tests der Business-Continuity-Pläne und Notfallverfahren müssen dokumentiert und Ergebnisse aufbewahrt werden. |
| DSGVO | Art. 5 Abs. 2 | Rechenschaftspflicht: Der Verantwortliche muss die Einhaltung der Grundsätze nachweisen können ("Accountability"). |
| EU AI Act | Art. 9 Abs. 7 | Hochrisiko-KI-Systeme: Technische Dokumentation und Logs müssen für Konformitätsbewertungen verfügbar gehalten werden. |
| CRA | Art. 13 Abs. 3 | Hersteller müssen technische Unterlagen erstellen und 10 Jahre nach Inverkehrbringen aufbewahren. |
BAM-Objektreferenz
Typische Formen von Evidence
Systemlogs und Protokolldateien. Automatisch erzeugte Aufzeichnungen – Firewall-Logs, Zugriffsprotokoll, Patch-Management-Berichte. Stärke: tamper-evident, keine manuelle Arbeit. Schwäche: ohne Kontext oft schwer interpretierbar; der Auditor muss verstehen, was das Log belegt.
Unterschriebene Protokolle und Checklisten. Datierte, unterzeichnete Dokumente – Restore-Test-Protokoll, Schulungsteilnahmeliste, Review-Protokoll. Stärke: unmittelbar verständlich. Schwäche: manuell, fehleranfällig, kann nachträglich erstellt werden – was Auditoren wissen und prüfen.
Screenshots und Systemausdrucke. Zeitgestempelte Ansichten aus Systemen – MFA-Aktivierungsstatus, Patch-Stand, Konfigurationsauszug. Stärke: schnell erstellt. Schwäche: Zeitstempel muss verlässlich sein; Screenshots ohne Systemkontext werden oft nicht anerkannt.
Externe Berichte und Zertifikate. Penetrationstest-Berichte, Vulnerability-Scan-Ergebnisse, ISO-Zertifikat, SOC-2-Bericht eines Dienstleisters. Stärke: unabhängige Drittpartei erhöht Glaubwürdigkeit. Schwäche: Gültigkeit zeitlich begrenzt, Scope muss zum geprüften Kontrollziel passen.