Er zijn twee manieren om een compliance-vraag te beantwoorden. De eerste: “Ja, wij monitoren onze systemen.” De tweede: “Ja, hier is het rapport van vorige maand, met onze beschikbaarheidscijfers, gedetecteerde incidenten en reactietijden.” Het verschil tussen die twee zinnen is het verschil tussen een belofte en bewijs. En auditors, verzekeraars en NIS2-klanten zijn alleen in de tweede geïnteresseerd.

Het goede nieuws voor wie toch al overweegt om monitoring deftig aan te pakken: één degelijke opzet dekt meteen een hele reeks vereisten af. Dit artikel toont welke, zonder framework-jargon, met wat het in de praktijk betekent.

Eén systeem, vier antwoorden

“Weet u wat er in uw omgeving draait?” Een monitoringplatform begint met ontdekken wat er is: servers, netwerktoestellen, services, certificaten. Die inventaris is geen momentopname in een spreadsheet, maar een levend overzicht dat zichzelf bijwerkt. Komt er een systeem bij, dan verschijnt het. Verdwijnt er een, dan ziet u dat ook, en soms is dát het interessantste signaal.

“Detecteert u storingen en afwijkingen?” Dit is de kern van monitoring: continu meten, vergelijken met wat normaal is, en alarmeren bij afwijking. Een volgelopen schijf, een dienst die niet meer antwoordt, een certificaat dat over twee weken vervalt, een server die plots tien keer meer verkeer ziet dan anders. Goed geconfigureerd betekent dat: detectie binnen de minuut, in plaats van ontdekking via een boze klant.

“Houdt u bij wat er gebeurt?” Elke meting, elke statuswijziging, elk alarm wordt vastgelegd met tijdstip. Valt er iets voor, dan kunt u achteraf reconstrueren: wanneer begon het, wat ging eraan vooraf, hoe snel werd het opgemerkt en opgelost. Die reconstructie is goud waard bij een incident, en ze is exact wat een auditor bedoelt met “event logging”.

“Hoe beschikbaar zijn uw systemen?” Beschikbaarheid wordt pas een cijfer als iemand ze meet. Een monitoringplatform doet dat als bijproduct: uptime per systeem, per maand, zwart op wit. Dat cijfer is bruikbaar in klantencontracten, in verzekeringdossiers en in elke leveranciersbeoordeling.

Wat “bewijs” er concreet uitziet

In de praktijk komt het neer op drie dingen die u op tafel kunt leggen.

Het eerste is een maandrapport: beschikbaarheid per systeem, het aantal gedetecteerde incidenten, en de tijd tussen detectie en oplossing. Twee pagina’s volstaan; het gaat om de cijfers, niet om het volume.

Het tweede is een alarmhistoriek: het aantoonbare spoor dat afwijkingen effectief gedetecteerd én opgevolgd werden. Niet alleen “we hebben monitoring”, maar “op 3 maart om 02:14 ging dit alarm af, om 02:31 was het opgelost”.

Het derde is de actuele inventaris: de lijst van wat er bewaakt wordt, rechtstreeks uit het systeem. Wie die drie documenten kan voorleggen, beantwoordt het detectie-luik van een leveranciersvragenlijst in tien minuten in plaats van tien dagen.

Zelf bouwen of laten doen?

Kan een KMO dit zelf opzetten? Technisch wel: de software bestaat, ook in open source. De praktijk is weerbarstiger: een monitoringplatform dat slecht is afgesteld, produceert ofwel stilte (en mist incidenten) ofwel lawaai (honderd alarmen per dag, die iedereen na een week negeert). De waarde zit niet in de installatie maar in de afstelling: wat is normaal voor úw omgeving, wat verdient een alarm om drie uur ‘s nachts, en wat kan wachten tot de ochtend.

Dat afstellen is wat ik al ruim vijftien jaar doe in enterprise-omgevingen, en wat ik via Althona binnen bereik van KMO’s breng, inclusief de maandrapporten die u rechtstreeks aan uw NIS2-klanten kunt bezorgen.

Benieuwd hoe dat er voor uw omgeving uitziet? Plan een vrijblijvend gesprek. Binnen het uur weet u wat er bewaakt zou worden, en wat dat maandelijks op papier oplevert.