The NIS-2 directive has been due for transposition into national law since October 2024 – binding on significantly more organizations than its predecessor. At its core, it does not demand "more technology" but demonstrability: that incidents are detected, reported, and handled – and that the technical and organizational measures (TOMs) taken are documented, tested, and auditable.
Three NIS-2 Requirements That Hang Directly on the Mail Gateway
- Detection and continuous monitoring (Art. 21 (2)(b)) – those who do not know whether their filters run cannot report an incident.
- Incident management and reporting (Art. 23) – reporting significant incidents within 24 h requires alert rules that can distinguish significantly from normal.
- Audit trail for security actions – releases from quarantine, policy changes, accesses to forensic archives must be logged seamlessly.
Health Monitoring: The Forgotten Detail
Most mail gateways monitor their own components in a manageable way: "API responds, so it's running". SecTepe.Comm adds a component health endpoint that, on every call, checks in parallel:
- PostgreSQL connection (latency and reachability).
- Redis (pong roundtrip).
- Scanner sidecar, ClamAV, CAPE sandbox.
- Mailcow API, OpenBao vault.
- External CTI hosts (MISP intel, YARA service, ransomware intel, orchestrator).
Status codes 401/403 (auth-required endpoint) explicitly count as "healthy" – a common mistake in naive health checks that mark every non-200 as "down" and flood the SOC with false positives.
Alert Rules: Configurable Thresholds Instead of Fixed Heuristics
SecTepe.Comm ships a UI in which admins create alert rules over metrics like "phishing_rate_5min", "dlp_hits_per_hour", "sandbox_failures", "cti_sync_lag_minutes". Per rule:
- Threshold, cooldown (avoids alert storms), severity (info / warn / critical).
- Channel: email to SOC distribution list, webhook to Slack/Teams, Wazuh event.
- Optional: auto-reaction (e.g. quarantine lock on phishing spike).
Audit Log: The Auditor's Favorite
The integrated audit log records every security-relevant action: login (incl. SSO provider), quarantine release (with approver), policy change, forensic download, CTI override, domain provisioning. Filterable by user, action type, time range; exportable as CSV. The table is append-only enforced via a DB trigger so even a DBA with DELETE rights leaves traces in the trigger log.
What Happens with a 24-Hour Reporting Obligation
Realistic response to a NIS-2 initial report:
- Alert rule "phishing_rate_5min > 30" fires.
- SOC opens the dashboard, sees the affected domain and a pivot into the quarantine.
- Forensic archive delivers the original mails as WORM PDF with hash receipt.
- Audit log confirms who saw and decided what when – that is annex 2 to the BSI report.
The difference from the "Excel tracker" approach: no 30-minute reconstruction but a finished answer within the first 60 minutes – where NIS-2 expects an initial advance notification anyway.
Health, Audit, Alerts: Not Three Tools, but Three Tabs
The temptation to solve each of these three functions with a separate best-of-breed tool costs above all one thing: time for correlation. Three UIs, three auth layers, three data models. That all three are tabs of the same SecTepe.Comm web UI is, in an emergency, the difference between "informed decision" and "reacted blind".
Conclusion
NIS-2 is not a "cybersecurity buzzword 2026" but a concrete operational requirement, backed by fines. The technical building blocks it requires – health, audit, alerts, reporting – are significantly cheaper to build and easier to audit in an integrated platform than as a patchwork of three tools. Anyone without a clear plan for the NIS-2 initial report in 2026 should be catching up by now at the latest.