Nachweise sind der Unterschied zwischen „wir machen Security“ und „wir können es belegen“. Das klingt nach Papier, ist aber in Wahrheit Betriebsfähigkeit.
Klingt nach Bürokratie, ist aber in Wahrheit Resilienz. Am 27.01.2026 berichtete Kommune21, dass das BSI, der Südwestfalen IT ein ISO 27001 Zertifikat auf Basis von IT Grundschutz übergeben hat, also ein Label, das nur mit belastbarer Evidence entsteht. Am 29.01.2026 erinnerte die US Regulierungsbehörde FCC in ihrer Ransomware Best Practices Notiz daran, im Incident Response Beweise zu sichern, inklusive System Images und Logs. Und genau daran scheitern in der Praxis nicht Tools, sondern Entscheidungen. Der spannendste Teil ist nicht der Angriff, sondern was danach passiert.
Warum Nachweise meistens fehlen
Nachweise werden oft wie ein Nebenprodukt behandelt. Man macht die Maßnahme, aber plant den Beleg nicht mit. Kurz vor Audit wird dann aus Email, Screenshots und Excel eine Story gebaut. Das ist teuer, fehleranfällig und wirkt auf Prüfer wie Theater.
Ownership ist häufig unscharf. Eine Kontrolle hat keinen klaren Owner, keine Routine, kein Review. Ohne Routine gibt es keine Evidence, egal wie gut das Tooling ist. Eine Kontrolle ohne Nachweis ist wie ein Prozess ohne Ausgang. Er kann existieren, aber niemand kann sagen, ob er heute noch funktioniert.
Und obwohl Systeme Evidence produzieren, sammelt sie niemand gezielt ein. Logging, Ticketing, IAM, Backup, EDR, MDM. Alles erzeugt Spuren. Wenn niemand definiert, welche Spuren als Nachweis gelten, verfallen sie, werden überschrieben oder sind nicht auffindbar. Spätestens beim Stichprobentest im Audit zeigt sich dann: Man hat Daten, aber keine Beweiskette.
Der häufigste blinde Fleck ist PDCA. Plan und Do funktionieren oft. Check und Act werden verdrängt, weil der Betrieb drückt. Damit bleibt jede Kontrolle eine Momentaufnahme, ohne Lernen. Genau dadurch fehlt am Ende das, was Labels ausmacht: nachweisbare Wirksamkeit über Zeit.
Warum Nachweise wichtig sind, auch ohne Zertifikat
Nachweise sind nicht für den Auditor. Nachweise sind für euch. Sie beantworten drei Fragen, die im Ernstfall zählen:
Was haben wir beschlossen.
Was haben wir getan.
Was wissen wir heute über Wirksamkeit.
Die FCC schreibt bei Ransomware explizit, Beweise zu sichern und relevante Logs zu sammeln. Das ist keine Compliance Floskel, sondern die Grundlage, um Ursachen zu finden, Scope zu bestimmen, Versicherer zu bedienen, Behörden zu informieren und sauber zu recovern. Ohne Logs wird Incident Response zur Diskussion, statt zur Analyse.
Und es ist nicht nur Incident Response. CISA hat am 29.01.2026 mit dem POEM Ansatz beschrieben, wie Organisationen Insider Threat Programme planbar aufbauen und über die Zeit aufrechterhalten. Das funktioniert nur, wenn Rollen, Routinen und Belege stehen. Evidence ist damit auch Kultur: Verantwortlichkeit, Regelmäßigkeit, Nachvollziehbarkeit.
Wie sich der ISMS Kreislauf dadurch schließt
Ein ISMS lebt von Rückkopplung. Nachweise sind diese Rückkopplung. In PDCA bedeutet das: Plan definiert Risiken und Kontrollen, Do setzt um, Check prüft Wirksamkeit mit Reviews, Tests und Audits, Act setzt Verbesserungen um und dokumentiert sie. Ohne Evidence bricht der Kreis im Check.
Genau hier wird es 2026 noch sichtbarer. Mit der Umsetzung von NIS2 steigt der Druck auf Compliance Dokumentation, Risiko und Vorfallprozesse deutlich. Wer nur Controls hat, aber keine Nachweise, kann weder steuern noch belegen. Wer Nachweise hat, kann Prioritäten setzen, Budgets begründen und Entscheidungen der Leitung absichern.
Evidence by Design
Der Aha Moment ist fast immer derselbe: Viele investieren zuerst in Controls und zu spät in die Belegbarkeit der Controls. Das ist, als würdet ihr ein Feuerlöschsystem kaufen, aber nie testen, ob Wasser aus der Wand kommt.
In Projekten bei Kämmer Consulting GmbH drehen wir das um: Evidence wird als Produkt des Betriebs geplant, nicht als Audit Rettungsaktion.
Pragmatisch geht das mit einem kurzen Evidence Profil pro Kontrolle. Es ist keine Doku Orgie, sondern ein Vertrag mit euch selbst: Was ist der Beleg, wo liegt er, wie oft entsteht er, wer schaut drauf, was passiert bei Abweichung. Typische Evidence Arten sind Patch Reports, Access Reviews, Backup Restore Tests, Awareness Teilnahme, Lieferantenbewertungen und Freigaben.
Für TISAX wird das besonders sichtbar: Selbst bei niedrigen Assessment Levels geht es um dokumentierte Nachweise, nicht um Bauchgefühl.
Drei konkrete Schritte:
• Definiert pro Kontrolle ein Evidence Profil und legt Owner plus Frequenz fest, damit Evidence nicht mehr Zufall ist.
• Schafft eine Nachweiskette je Risiko und verlinkt Policy, Ticket, technische Logs (Protokolldaten) und Review Protokoll, damit Prüfbarkeit entsteht.
• Plant Check als Terminserie für Reviews, Tests und interne Audits (Wirksamkeitsprüfung), damit PDCA geschlossen bleibt.
Was ihr dadurch gewinnt: Audit Geschwindigkeit, weil Nachweise auffindbar und konsistent sind. Incident Ruhe, weil ihr in Stresslagen nicht erst Daten suchen müsst. Management Klarheit, weil Entscheidungen auf Beobachtung beruhen, nicht auf Gefühl. Zusätzlich verbessert ihr Vendor Gespräche und Kundenvertrauen, weil ihr nicht behauptet, sondern zeigt.
Die kritische Gegenperspektive
Die Gegenposition lautet, dass zusätzliche Sicherheitsanforderungen Aufwand schaffen, Projekte verlangsamen und gerade kleinere Organisationen überfordern können. Dieser Einwand ist berechtigt. Er spricht aber für risikogerechte, umsetzbare Kontrollen bei „Nachweise sind der Unterschied im ISMS“ – nicht dafür, bekannte Risiken einfach auszublenden.
Was beide Seiten leicht übersehen
Oft liegt der entscheidende Punkt zwischen Technik und Organisation. Werkzeuge können Grenzen setzen, aber Menschen vergeben Rechte, definieren Prozesse und reagieren auf Warnungen. Bei „Nachweise sind der Unterschied im ISMS“ müssen deshalb technische Maßnahmen, verständliche Kommunikation und eindeutige Verantwortung zusammenpassen.
Mein Fazit
Für mich zeigt „Nachweise sind der Unterschied im ISMS“ vor allem, dass einfache Antworten zu kurz greifen. Der sinnvolle Weg liegt zwischen unkritischer Begeisterung und pauschaler Ablehnung: Nutzen klar benennen, Nebenwirkungen sichtbar machen und Verantwortung so organisieren, dass Entscheidungen auch im Alltag nachvollziehbar bleiben.
Quellen und Einordnung
Grundlage dieses Beitrags ist mein ursprünglich am 2026-02-01 auf LinkedIn veröffentlichter Artikel. Die dort enthaltenen Verweise und fachlichen Einordnungen wurden für diese Fassung übernommen und um die Perspektiven dieses Blogs ergänzt.
Themen: #Informationssicherheit · #ISMS · #ISO27001 · #NIS2 · #TISAX · #Cybersecurity · #ITManagement · #Audit · #IncidentResponse · #Risikomanagement