There are two ways to answer a compliance question. The first: “Yes, we monitor our systems.” The second: “Yes, here’s last month’s report, with our availability figures, detected incidents and response times.” The difference between those two sentences is the difference between a promise and proof. And auditors, insurers and NIS2 clients are only interested in the second.
The good news for anyone already considering taking monitoring seriously: one solid setup covers a whole series of requirements at once. This article shows which ones, without framework jargon, with what it means in practice.
One system, four answers
“Do you know what’s running in your environment?” A monitoring platform starts by discovering what exists: servers, network devices, services, certificates. That inventory isn’t a snapshot in a spreadsheet, but a living overview that keeps itself up to date. A system gets added? It appears. One disappears? You see that too, and sometimes that is the most interesting signal.
“Do you detect outages and anomalies?” This is the core of monitoring: measuring continuously, comparing against what’s normal, and alerting on deviation. A disk filling up, a service no longer responding, a certificate expiring in two weeks, a server suddenly seeing ten times its usual traffic. Properly configured, that means: detection within the minute, instead of discovery via an angry client.
“Do you keep track of what happens?” Every measurement, every status change, every alert is recorded with a timestamp. If something happens, you can reconstruct afterwards: when it started, what preceded it, how quickly it was noticed and resolved. That reconstruction is worth gold during an incident, and it is exactly what an auditor means by “event logging”.
“How available are your systems?” Availability only becomes a number when someone measures it. A monitoring platform does that as a by-product: uptime per system, per month, in black and white. That number is usable in client contracts, insurance files and every supplier assessment.
What “evidence” concretely looks like
In practice it comes down to three things you can put on the table.
The first is a monthly report: availability per system, the number of detected incidents, and the time between detection and resolution. Two pages suffice; it’s about the numbers, not the volume.
The second is an alert history: the demonstrable trail that anomalies were actually detected and followed up. Not just “we have monitoring”, but “on March 3rd at 02:14 this alert fired, by 02:31 it was resolved”.
The third is the current inventory: the list of what’s being watched, straight out of the system. Whoever can produce those three documents answers the detection section of a supplier questionnaire in ten minutes instead of ten days.
Build it yourself, or have it done?
Can an SME set this up itself? Technically yes: the software exists, including open source. Practice is harsher: a poorly tuned monitoring platform produces either silence (and misses incidents) or noise (a hundred alerts a day, which everyone ignores after a week). The value isn’t in the installation but in the tuning: what is normal for your environment, what deserves an alert at three in the morning, and what can wait until morning.
That tuning is what I’ve been doing for over fifteen years in enterprise environments, and what I bring within reach of SMEs through Althona, including the monthly reports you can pass straight to your NIS2 clients.
Curious what that would look like for your environment? Book a no-obligation call. Within the hour you’ll know what would be monitored, and what that delivers on paper every month.