Zenarmor-Berichte als Audit-Nachweis für NIS2 und ISO 27001

Für NIS2 und ISO 27001:2022 müssen Sie nachweisen, dass Sie Netzwerkaktivität protokollieren, schützen, auswerten und darauf reagieren. Das ist der Kern von A.8.15 (Protokollierung) und A.8.16 (Überwachungstätigkeiten) und die Grundlage dafür, einen erheblichen Sicherheitsvorfall innerhalb von 24 Stunden, 72 Stunden und einem Monat melden zu können. Zenarmor liefert die Bausteine: über 60 Berichte, Alarmregeln, geplante PDF-Berichte, einen Audit-Trail in Zenconsole, lokale Speicherung in Elasticsearch oder SQLite sowie Streaming an Ihr SIEM, einen Syslog-Server oder ein externes Elasticsearch. Zum Nachweis wird das aber erst, wenn Sie je Anforderung festlegen, welches Protokoll oder welcher Bericht sie belegt, wie lange Sie ihn aufbewahren, wie oft ihn jemand prüft und wer verantwortlich ist.

Dieser Beitrag zeigt, was Auditoren und Aufsichtsbehörden sehen wollen, was Zenarmor protokolliert, wie Sie Aufbewahrungsfristen wählen, die vor NIS2 und DSGVO bestehen, und wie ein vollständiges Evidence Pack aussieht. Secrotec schreibt als unabhängiger ISO 27001 Lead Auditor und offizieller Zenarmor-Partner in den Niederlanden: Wir sehen täglich den Unterschied zwischen „Logging ist aktiviert“ und „Logging ist nachweislich wirksam“.

Was NIS2, BSIG und ISO 27001 verlangen

NIS2-Richtlinie: Artikel 21 und 23

Artikel 21 der NIS2-Richtlinie verpflichtet wesentliche und wichtige Einrichtungen zu geeigneten Risikomanagementmaßnahmen, unter anderem zur Bewältigung von Sicherheitsvorfällen (Abs. 2 lit. b) und zur Bewertung der Wirksamkeit dieser Maßnahmen (Abs. 2 lit. f). Das Wort „Protokollierung“ steht dort nicht, doch ohne Protokolle lassen sich weder Vorfälle bewältigen noch Wirksamkeit messen. Artikel 23 regelt die Fristen: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens einen Monat nach der Meldung.

Konkreter wird die Durchführungsverordnung (EU) 2024/2690. Nummer 3.2 des Anhangs („Überwachung und Protokollierung“) verlangt Verfahren und Werkzeuge, um Aktivitäten in Netz- und Informationssystemen zu überwachen und zu protokollieren, mit Protokollen unter anderem zu ein- und ausgehendem Netzwerkverkehr, Authentifizierung, privilegierten Zugriffen, Konfigurationsänderungen und Sicherheitswerkzeugen wie Firewalls. Protokolle sind für einen festgelegten Zeitraum aufzubewahren und zu sichern, vor unbefugtem Zugriff und Veränderung zu schützen, und Systeme müssen synchronisierte Zeitquellen nutzen. Die Verordnung gilt unmittelbar für digitale Anbieter wie Cloud-, Rechenzentrums- und Managed-(Security-)Service-Provider, ist aber für jede Organisation ein guter Maßstab. Die NIS2 Technical Implementation Guidance der ENISA (Juni 2025) ergänzt Beispiele für Nachweise.

Deutschland: NIS2UmsuCG und BSI-Gesetz

In Deutschland wurde NIS2 mit dem NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) umgesetzt; die Pflichten stehen im neu gefassten BSI-Gesetz. Nach der Informationsseite des BSI zur Meldepflicht gelten die Meldepflichten ab dem 6. Dezember 2025. § 30 BSIG verpflichtet besonders wichtige und wichtige Einrichtungen zu geeigneten, verhältnismäßigen und wirksamen Risikomanagementmaßnahmen, darunter die Bewältigung von Sicherheitsvorfällen und Konzepte zur Bewertung der Wirksamkeit. § 32 BSIG regelt die frühe Erstmeldung binnen 24 Stunden, die Meldung binnen 72 Stunden und die Abschlussmeldung nach einem Monat. Mehr zu den Gesamtpflichten auf unserer Seite zur NIS2-Compliance.

ISO 27001:2022

ISO 27001 ist expliziter. Die relevanten Maßnahmen aus Anhang A im Überblick:

Maßnahme	Kern	Was der Auditor sehen will
A.8.15 Protokollierung	Protokolle über Aktivitäten, Ausnahmen, Fehler und relevante Ereignisse erstellen, speichern, schützen und auswerten	Protokollierungsrichtlinie, Umfang, Aufbewahrung, Manipulationsschutz, dokumentierte Reviews
A.8.16 Überwachungstätigkeiten	Netze und Systeme auf anomales Verhalten überwachen und angemessen reagieren	Alarmregeln, Nachverfolgung, Verknüpfung mit Vorfällen
A.8.17 Uhrensynchronisation	Eine verlässliche Zeitquelle für alle Systeme	NTP-Konfiguration, konsistente Zeitstempel
A.5.25 Beurteilung von Ereignissen	Entscheiden, ob ein Ereignis ein Vorfall ist	Triage-Kriterien, dokumentierte Entscheidungen
A.5.26 Reaktion auf Vorfälle	Vorfälle nach dokumentiertem Verfahren behandeln	Vorfallsakte mit Zeitleiste und Maßnahmen
A.5.28 Sammeln von Beweismaterial	Beweise identifizieren, sammeln und sichern	Exporte mit Integritätsschutz und dokumentierter Beweiskette

Was Auditor und Aufsicht sehen wollen

Ein Auditor prüft drei Ebenen: die Angemessenheit (gibt es eine Protokollierungsrichtlinie, die zur Risikoanalyse passt?), die Umsetzung (sind Logging und Alarme wirklich auf den richtigen Systemen aktiv?) und die Wirksamkeit (wird nachweislich und über längere Zeit geprüft und reagiert?). An der letzten Ebene scheitern die meisten Organisationen. Ein Dashboard zu zeigen genügt nicht; der Auditor will eine Stichprobe von Alarmen sehen, die zu einem Ticket geführt haben, und Reviews mit Datum und Namen.

Typische Fragen, die wir als Auditoren stellen:

• Welche Systeme protokollieren, und warum genau diese? Wo steht das in Ihrer Risikoanalyse?
• Wie lange bewahren Sie welche Protokolle auf, und wie begründen Sie die Frist?
• Wer kann Protokolle einsehen, ändern oder löschen, und wird das selbst protokolliert?
• Wie oft werden Berichte geprüft, und wo ist das belegt?
• Welcher Alarm führte zu welchem Vorfall, und wie schnell wurde reagiert?
• Können Sie einen Vorfall von vor sechs Wochen rekonstruieren?

Was Zenarmor protokolliert und berichtet

Zenarmor erfasst je Sitzung, welches Gerät oder welcher Nutzer mit welchem Ziel kommunizierte, welche Anwendung und Kategorie betroffen war und welche Policy gegriffen hat. Laut der Dokumentation zum Streaming von Berichtsdaten gibt es fünf Datenströme: Connections, Web, DNS, TLS und Alerts. Darauf baut Zenarmor über 60 Berichte und Dashboards auf, ergänzt um Live Sessions für Echtzeit-Einblick.

• Alarmregeln: Threat & Activity Alert Rules melden zum Beispiel blockierte Bedrohungen oder auffällige Aktivität; seit Version 2.7 auch mit täglicher Frequenz.
• Geplante Berichte: Laut der Dokumentation zu Scheduled Reports werden Berichte als PDF per E-Mail versendet, über Ihren eigenen SMTP-Server oder den Mail-Dienst von Zenconsole, an den Tagen Ihrer Wahl. Unified Secure enthält 20 geplante Berichte, die Enterprise-Pläne unbegrenzt viele.
• Audit-Trail in Zenconsole: Seit Version 2.6 (Juni 2026) wird jede Aktion eines Zenconsole-Nutzers protokolliert, etwa Policy-Updates, Konfigurationsänderungen sowie das Hinzufügen oder Entfernen von Zenarmor-Instanzen. Version 2.7 ergänzte Audit-Logs für Endpoint-Agents und OPNsense-Gateways, unter anderem für An- und Abmeldungen, Änderungen des Engine-Status und Updates (Release Notes).

Dieser Audit-Trail ist im Audit Gold wert: Er beantwortet auf einen Blick, wer wann welche Firewall-Regel geändert hat. In ISO 27001 berührt das auch das Änderungsmanagement (A.8.32) und privilegierte Zugangsrechte (A.8.2).

Speicherung und Aufbewahrung: lokal, Cloud oder SIEM

Wo Ihre Protokolle liegen, bestimmt, wie weit Sie zurückblicken können und wie gut sie geschützt sind. Zenarmor unterstützt mehrere kombinierbare Optionen:

Option	Ort	Aufbewahrung	Geeignet für
SQLite (lokal)	Auf dem Gateway	Einstellbar, begrenzt durch Speicherplatz	Kleine Umgebungen bis etwa 100 Geräte
Elasticsearch (lokal)	Auf dem Gateway, mindestens 8 GB RAM	Einstellbar, begrenzt durch Speicherplatz	Größere Netze mit längerer lokaler Historie
Elasticsearch (remote)	Eigener Server oder Cluster	Nach eigener Richtlinie	Zentrale Speicherung außerhalb des Gateways
Streaming an Syslog/SIEM	Syslog-Server, SIEM (z. B. Wazuh), externes Elasticsearch	Nach eigener Richtlinie, Monate bis Jahre	Langfristige Nachweise, Korrelation, SOC
Zenconsole Cloud Reporting	Zenarmor-Cloud, Region wählbar (u. a. Deutschland und Niederlande)	15 Tage (Unified Secure), 30 (Plus), 90 (SSE/ZTNA/SASE)	Zentraler Überblick über Standorte hinweg

Die Wahl zwischen SQLite und Elasticsearch beschreibt die Zenarmor-Dokumentation zur Berichtsdatenbank; die Aufbewahrung je Plan steht auf der Preisseite (Stand Oktober 2026). Beachten Sie: Die lokale Speicherdauer steht laut Zenarmor-Dokumentation standardmäßig auf 7 Tagen und lässt sich per Schieberegler anpassen. Streaming an externe Systeme ist in den Editionen Free und Home nicht verfügbar.

Warum 15 Tage oft zu kurz sind

Laut M-Trends 2025 von Mandiant lag die weltweite mediane Verweildauer von Angreifern bei 11 Tagen und bei 26 Tagen, wenn eine externe Stelle die Organisation informierte. Wer erst nach drei Wochen merkt, dass etwas nicht stimmt, hat bei 15 Tagen Aufbewahrung den Beginn des Angriffs bereits verloren. Hinzu kommt, dass die Abschlussmeldung eine vollständige Zeitleiste verlangt. Unsere Faustregel: Cloud- oder lokale Berichte für den Tagesbetrieb nutzen und sicherheitsrelevante Protokolle an ein SIEM oder einen Syslog-Server streamen, mit einer Frist aus Ihrer Risikoanalyse, in der Praxis oft 6 bis 12 Monate.

Zum Speicherort: Seit Zenarmor 2.7 wählen Sie die Region der zentralen Berichtsdatenbank, unter anderem Deutschland und die Niederlande. Auf der Preisseite ist „customizable data residency“ bei den Enterprise-Plänen auf Anfrage aufgeführt; lassen Sie sich die Region für Ihren Plan im Angebot bestätigen.

Aufbewahrungsfristen und DSGVO

Firewall-Protokolle enthalten personenbezogene Daten: IP-Adressen, Benutzernamen, besuchte Domains. Die DSGVO nennt keine feste Frist, verlangt aber Zweckbindung und Speicherbegrenzung (Art. 5) sowie angemessene Sicherheit (Art. 32). Die Spannung zu NIS2 liegt daher weniger in der Frist selbst als in ihrer Begründung. In der Praxis:

• Nach Protokollart differenzieren. Alarme und blockierte Bedrohungen haben länger Beweiswert als detaillierte Web- und DNS-Protokolle je Nutzer.
• Fristen dokumentieren in der Protokollierungsrichtlinie und im Verzeichnis der Verarbeitungstätigkeiten, mit Begründung je Frist.
• Zugriff begrenzen auf die Personen, die ihn brauchen, und diesen Zugriff selbst protokollieren.
• Protokolle nicht zur Leistungskontrolle nutzen. Sonst ändert sich der Zweck, und die Mitbestimmung des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG ist berührt; regeln Sie das in einer Betriebsvereinbarung. Unser Beitrag zur TLS-Inspektion, DSGVO und Betriebsrat zeigt, wie Sie das abgrenzen.

Mehr zum Zusammenspiel von Datenschutz und Informationssicherheit lesen Sie in DSGVO und ISO 27001.

Das Evidence Pack: von der Anforderung zum Bericht

Ein Evidence Pack verknüpft jede Anforderung mit einem konkreten Nachweis, einer Frequenz und einem Verantwortlichen. Die folgende Tabelle ist unser Ausgangspunkt bei Kunden; passen Sie sie an Ihre Risikoanalyse und Ihre Erklärung zur Anwendbarkeit (SoA) an.

Anforderung	Zenarmor-Bericht oder -Protokoll	Frequenz	Verantwortlich
ISO A.8.15, DVO 2024/2690 Nr. 3.2	Protokollierungsrichtlinie plus Export der Aufbewahrungs- und Streaming-Einstellungen	Jährlich und bei Änderung	ISB / ISMS-Verantwortlicher
ISO A.8.16, § 30 BSIG (Vorfallsbewältigung)	Threat & Activity Alert Rules und Alarmübersicht	Alarme täglich, wöchentliches Review	IT-Betrieb / SOC
ISO A.8.7, A.8.23	Geplanter PDF-Bericht zu blockierten Bedrohungen und Webkategorien	Wöchentlich oder monatlich	IT-Betrieb
ISO A.8.20, A.8.22	Verkehrsbericht je Interface/VLAN und Policy je Segment	Monatlich	Netzwerkteam
ISO A.8.32, A.8.9	Audit-Trail Zenconsole: Policy- und Konfigurationsänderungen	Monatliches Review	ISB
ISO A.8.2	Audit-Logs der Gateways: Administrator-Anmeldungen	Monatlich	ISB
ISO A.5.25, A.5.26, A.5.28	Vorfallsakte mit verknüpften Alarmen und Protokollexporten	Je Vorfall	Incident Manager
§ 32 BSIG / NIS2 Art. 23	Zeitleiste aus Protokollen: Erkennung, Ausmaß, Maßnahmen	Je erheblichem Vorfall: 24 h, 72 h, 1 Monat	Incident Manager und Geschäftsleitung
ISO A.8.17	NTP-Einstellungen von Gateway und SIEM	Jährlich	IT-Betrieb
§ 30 BSIG (Wirksamkeit), ISO 9.1 und 9.3	KPI-Übersicht: Blockierungen, Alarme, Reaktionszeit, Trends	Quartalsweise	ISB, an die Geschäftsleitung

Bewahren Sie das Pack an einem festen Ort mit Versionierung auf. Ein Auditor, der in zehn Minuten ein Jahr an Reviews durchblättern kann, stellt weniger Nachfragen.

Vorfallsprozess: vom Alarm zur Meldung

Checkliste für die Einrichtung

• Zeitsynchronisation (NTP) auf Gateway, SIEM und Servern eingerichtet und geprüft.
• Persönliche Administratorkonten mit MFA und minimalen Rechten in Zenconsole.
• Aufbewahrung lokal und in der Cloud bewusst eingestellt, nicht auf dem Standardwert belassen.
• Streaming an SIEM oder Syslog konfiguriert und getestet, mit Manipulationsschutz.
• Geplante Berichte an ein Gruppenpostfach mit eigener Aufbewahrung.
• Regelmäßige Reviews geplant und mit Datum, Name und Ergebnis dokumentiert.
• Alarmregeln auf Ihre Risiken abgestimmt, damit wichtige Signale nicht im Rauschen untergehen.

Zenarmor unterstützt diese Anforderungen; Konformität entsteht aus dem Zusammenspiel von Richtlinie, Prozess und nachweisbarem Betrieb. Protokollierung, die Ihre Netzsegmente abdeckt, stärkt zudem Ihre Netzwerksegmentierung für NIS2 und ISO 27001.

Wie Secrotec unterstützt

Secrotec ist unabhängiger ISO 27001 Lead Auditor und offizieller Zenarmor-Partner in den Niederlanden, gelistet auf der Partnerseite von Zenarmor. Wir liefern Zenarmor-Lizenzen und -Projekte in ganz Europa und richten Zenarmor so ein, dass es genau die Nachweise erzeugt, die Auditor oder Aufsicht verlangen.

• Wir erstellen mit Ihnen die Protokollierungsrichtlinie und Aufbewahrungsfristen, begründet aus Risiko und DSGVO.
• Wir konfigurieren Berichte, Alarmregeln, geplante Berichte und das Streaming an Ihr SIEM oder Syslog.
• Wir bauen das Evidence Pack, abgebildet auf ISO 27001 Anhang A, §§ 30 und 32 BSIG und NIS2.
• Mit Zenconsole als zentraler Verwaltung überwachen Sie mehrere Standorte aus einem Audit-Trail.
• Sie erhalten Partnerrabatt auf die Lizenzen; der Preis ist in Zenarmor-Projekten immer verhandelbar.

Besuchen Sie unsere Seite Zenarmor Partner, lesen Sie, wie ISO 27001 und NIS2 zusammenpassen, oder wechseln Sie zur Übersicht Firewall & Netzwerke.