The NIS-2 directive had to be turned into national law by October 2024. It binds far more organizations than the rules before it. At its core, it does not ask for "more technology". It asks for proof. You must show that incidents are detected, reported, and handled. And you must show that your technical and organizational measures (TOMs) are documented, tested, and auditable.
Three NIS-2 Requirements That Depend on the Mail Gateway
- Detection and constant monitoring (Art. 21 (2)(b)): if you don't know whether your filters are running, you can't report an incident.
- Incident handling and reporting (Art. 23): you must report major incidents within 24 h. That needs alert rules that can tell a major event from normal noise.
- Audit trail for security actions: releases from quarantine, policy changes, and access to forensic archives must be logged without gaps.
Health Monitoring: The Forgotten Detail
Most mail gateways check their own parts only loosely: "the API responds, so it's running". SecTepe.Comm adds a component health endpoint. On every call, it checks all of these at once:
- 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 (endpoints that need auth) count as "healthy" on purpose. Naive health checks often get this wrong. They mark every non-200 as "down" and flood the SOC with false positives.
Alert Rules: Set Your Own Thresholds Instead of Fixed Heuristics
SecTepe.Comm comes with a UI where admins build alert rules on metrics such as "phishing_rate_5min", "dlp_hits_per_hour", "sandbox_failures", and "cti_sync_lag_minutes". For each rule you set:
- Threshold, cooldown (to avoid alert storms), and severity (info / warn / critical).
- Channel: email to the SOC mailing list, webhook to Slack/Teams, or a Wazuh event.
- Optional: an automatic reaction (for example, a quarantine lock when phishing spikes).
Audit Log: The Auditor's Favorite
The built-in audit log records every action that matters for security:
- logins (including the SSO provider),
- quarantine releases (with the approver),
- policy changes and forensic downloads,
- CTI overrides and domain provisioning.
You can filter by user, action type, and time range, and export to CSV. A DB trigger makes the table append-only. So even a DBA with DELETE rights leaves traces in the trigger log.
What Happens with a 24-Hour Reporting Duty
A realistic response to a NIS-2 initial report looks like this:
- The alert rule "phishing_rate_5min > 30" fires.
- The SOC opens the dashboard. It sees the affected domain and can jump into the quarantine.
- The forensic archive delivers the original mails as WORM PDF with a hash receipt.
- The audit log shows who saw and decided what, and when. That is annex 2 of the BSI report.
Compare this to an "Excel tracker". There is no 30-minute rebuild of events. You have a finished answer within the first 60 minutes, which is when NIS-2 expects an early warning anyway.
Health, Audit, Alerts: Not Three Tools, but Three Tabs
It is tempting to solve each of these three tasks with its own best-of-breed tool. That costs one thing above all: time to connect the dots. You get three UIs, three auth layers, and three data models. In SecTepe.Comm, all three are tabs in the same web UI. In an emergency, that is the difference between an "informed decision" and "reacting blind".
Conclusion
NIS-2 is not a "cybersecurity buzzword 2026". It is a real operational duty, backed by fines. It needs technical building blocks: health, audit, alerts, and reporting. In one integrated platform, these are much cheaper to build and easier to audit than a patchwork of three tools. If you still have no clear plan for the NIS-2 initial report in 2026, now is the time to catch up.