Die NIS-2-Richtlinie ist seit Oktober 2024 in nationales Recht zu überführen – und damit verbindlich für deutlich mehr Organisationen als ihre Vorgängerin. Im Kern verlangt sie nicht „mehr Technik", sondern Nachweisbarkeit: dass Vorfälle erkannt, gemeldet und behandelt werden – und dass die getroffenen technischen und organisatorischen Maßnahmen (TOMs) dokumentiert, getestet und auditierbar sind.
Drei NIS-2-Anforderungen, die direkt am Mail-Gateway hängen
- Detektion und kontinuierliches Monitoring (Art. 21 (2)(b)) – wer nicht weiß, ob seine Filter laufen, kann keinen Vorfall melden.
- Vorfallsmanagement und Reporting (Art. 23) – signifikante Vorfälle binnen 24 h zu melden, setzt Alert-Rules voraus, die signifikant von normal unterscheiden können.
- Audit-Trail für Sicherheitsaktionen – Releases aus Quarantäne, Policy-Änderungen, Zugriffe auf Forensik-Archive müssen lückenlos protokolliert sein.
Health-Monitoring: das vergessene Detail
Die meisten Mail-Gateways monitoren ihre eigenen Komponenten überschaubar: „API antwortet, also läuft sie". SecTepe.Comm ergänzt einen Component-Health-Endpoint, der bei jedem Aufruf parallel prüft:
- PostgreSQL-Verbindung (Latenz und Erreichbarkeit).
- Redis (Pong-Roundtrip).
- Scanner-Sidecar, ClamAV, CAPE-Sandbox.
- Mailcow-API, OpenBao-Vault.
- Externe CTI-Hosts (MISP-Intel, YARA-Service, Ransomware-Intel, Orchestrator).
Status-Codes 401/403 (Auth-Required-Endpoint) zählen ausdrücklich als „healthy" – ein häufiger Fehler in naiven Health-Checks, die jeden Nicht-200 als „down" markieren und das SOC mit False Positives fluten.
Alert-Rules: konfigurierbare Schwellen statt fixer Heuristiken
SecTepe.Comm liefert eine UI, in der Admins Alert-Regeln über Metriken wie „phishing_rate_5min", „dlp_hits_per_hour", „sandbox_failures", „cti_sync_lag_minutes" anlegen. Pro Regel:
- Schwelle, Cooldown (vermeidet Alert-Storms), Severity (info / warn / critical).
- Channel: E-Mail an SOC-Verteiler, Webhook an Slack/Teams, Wazuh-Event.
- Optional: Auto-Reaktion (z. B. Quarantäne-Lock bei Phishing-Spike).
Audit-Log: der Wirtschaftsprüfer-Liebling
Das integrierte Audit-Log protokolliert jede sicherheitsrelevante Aktion: Login (inkl. SSO-Provider), Quarantäne-Release (mit Approver), Policy-Änderung, Forensik-Download, CTI-Override, Domain-Provisionierung. Filterbar nach User, Aktionstyp, Zeitraum; exportierbar als CSV. Die Tabelle ist append-only enforced via DB-Trigger, sodass auch ein DBA mit DELETE-Rechten Spuren in den Trigger-Log hinterlässt.
Was bei einer 24-h-Meldepflicht passiert
Realistische Reaktion auf eine NIS-2-Erstmeldung:
- Alert-Rule „phishing_rate_5min > 30" schlägt aus.
- SOC öffnet das Dashboard, sieht die betroffene Domain und ein Pivot in die Quarantäne.
- Forensik-Archiv liefert die Original-Mails als WORM-PDF mit Hash-Beleg.
- Audit-Log bestätigt, wer wann was sah und entschied – das ist die Anlage 2 zur BSI-Meldung.
Der Unterschied zum „Excel-Tracker"-Ansatz: keine 30-minütige Rekonstruktion, sondern fertige Antwort innerhalb der ersten 60 Minuten – wo NIS-2 ohnehin eine erste Vorab-Meldung erwartet.
Health, Audit, Alerts: keine drei Tools, sondern drei Tabs
Die Versuchung, jede dieser drei Funktionen mit einem separaten Best-of-Breed-Tool zu lösen, kostet vor allem eines: Zeit für Korrelation. Drei UIs, drei Auth-Schichten, drei Daten-Modelle. Dass alle drei in SecTepe.Comm Tabs derselben Web-UI sind, ist im Notfall der Unterschied zwischen „informierte Entscheidung" und „blind reagiert".
Fazit
NIS-2 ist kein „Cybersecurity-Buzzword 2026", sondern eine konkrete operative Anforderung mit Bußgeld-Bewehrung. Die technischen Bausteine, die sie verlangt – Health, Audit, Alerts, Reporting –, sind in einer integrierten Plattform deutlich günstiger und besser auditierbar zu bauen als als Patchwork aus drei Tools. Wer 2026 noch keinen klaren Plan für die NIS-2-Erstmeldung hat, sollte spätestens jetzt aufholen.