De echte uitdaging van NIS2 is niet de rapporteringstermijn, maar het nemen van escalatiebeslissingen onder druk
Wanneer incidentescalatie binnen NIS2 wordt besproken, ligt de focus bijna altijd op de rapporteringstermijnen. Organisaties bereiden zich voor op de vroege waarschuwing binnen 24 uur, de incidentmelding binnen 72 uur en de daaropvolgende formele rapporteringsverplichtingen. Deze vereisten zijn belangrijk, maar tegelijkertijd relatief rechtlijnig. Termijnen kunnen worden geoperationaliseerd, gemeten en geaudit.
De echte uitdaging dient zich veel vroeger aan, meestal al in de eerste uren van een incident, wanneer informatie nog onvolledig is en de druk al toeneemt. Op dat moment is de centrale vraag niet technisch, maar organisatorisch van aard: “Wanneer wordt een cybersecurity-incident voldoende significant om te escaleren en te rapporteren?”
Opvallend genoeg krijgt die beslissing weinig aandacht, terwijl ze net één van de moeilijkste operationele en governance-uitdagingen is die NIS2 met zich meebrengt.
De meeste organisaties beschikken vandaag al over een incident response-proces. Ze hebben impactmatrices, escalatieprocedures, crisisteams en detectiecapaciteiten. Velen hebben bovendien zwaar geïnvesteerd in tooling, automatisering en dreigingsdetectie. Toch hebben zelfs technisch volwassen organisaties het vaak moeilijk wanneer tijdens een actief incident escalatiebeslissingen moeten worden genomen. Niet omdat ze kwaadaardige activiteiten niet kunnen detecteren, maar omdat escalatie gevolgen heeft.
Vanaf het moment dat een incident formeel intern wordt geëscaleerd of extern wordt gemeld, verandert de dynamiek. Juridische teams worden betrokken. Het management wordt ingeschakeld. Communicatievraagstukken komen naar boven. Klanten, leveranciers, toezichthouders en partners moeten mogelijk worden geïnformeerd. Wat begon als een technische analyse, wordt plots een bedrijfsincident met mogelijke reputatie-impact.
De meeste organisaties missen een belangrijk onderdeel van NIS2
Vandaag gaan discussies over NIS2 vooral over compliance: meldingsverplichtingen, governance-structuren, vereiste controles en de toepasselijkheid per sector. Dat zijn belangrijke onderwerpen, maar niet waar de meeste organisaties operationeel tegenaan zullen lopen.
De echte moeilijkheid zit in de interpretatie.
Organisaties worstelen met het beoordelen van onvolledig bewijsmateriaal, onzekere bedrijfsimpact en de praktische betekenis van het begrip “significant”. De NIS2-richtlijn vermijdt bewust technische drempelwaarden omdat incidenten sterk verschillen tussen sectoren en organisaties. Vanuit regulatoir oogpunt is dat logisch, maar operationeel creëert het ambiguïteit.
Eenzelfde technisch incident kan immers volledig verschillende gevolgen hebben afhankelijk van de omgeving waarin het plaatsvindt. Een ransomwarebesmetting in een ontwikkelomgeving is iets totaal anders dan dezelfde besmetting in een productieplanningssysteem of een ziekenhuisapplicatie voor patiëntplanning.
Dat onderscheid is cruciaal, omdat het betekent dat significantie niet uitsluitend via technische analyse kan worden bepaald. Organisaties die NIS2-meldingen proberen te reduceren tot statische severity-scores zullen waarschijnlijk snel tegen beperkingen aanlopen. Traditionele severity-modellen zijn ontworpen om operationele prioriteiten te bepalen, niet om regulatoire beslissingen te ondersteunen.
Waarom traditionele severity-modellen tekortschieten
De meeste organisaties classificeren incidenten vandaag als laag, gemiddeld, hoog of kritiek. Die classificaties zijn nuttig omdat ze responsteams helpen prioriteiten te stellen en operationele urgentie te bepalen.
Maar ze schieten vaak tekort wanneer ze worden gebruikt om regulatoire significantie te bepalen.
Een technisch ernstig incident is immers niet automatisch meldingsplichtig onder NIS2. Omgekeerd kan een incident dat technisch onder controle lijkt, toch significant blijken door klantimpact of een bredere systeemimpact.
Vanuit regulatoir perspectief telt niet alleen wat er technisch is gebeurd, maar ook welke gevolgen het incident kan hebben voor de operationele continuïteit van de organisatie.
Securityteams beoordelen incidenten van nature vanuit een technisch perspectief. Ze kijken naar laterale bewegingen, persistentiemechanismen, privilege-escalatie en mogelijke gegevensdiefstal.
Managementteams en juridische stakeholders bekijken hetzelfde incident vaak anders. Hun aandacht gaat uit naar operationele verstoringen, contractuele verplichtingen, meldingsvereisten, klantvertrouwen en reputatierisico's.
Beide perspectieven zijn correct, maar afzonderlijk onvoldoende voor NIS2. Organisaties hebben escalatiemodellen nodig die beide werelden met elkaar verbinden.
Waarom organisaties aarzelen om te escaleren
In de praktijk wordt terughoudendheid bij escalatie zelden veroorzaakt door een gebrek aan tooling of detectiecapaciteiten.
De aarzeling ontstaat vooral door de gevolgen die aan escalatie verbonden zijn.
Organisaties begrijpen dat zodra een incident formeel wordt geëscaleerd als potentieel significant, de impact groter wordt. Documentatieverplichtingen nemen toe. De zichtbaarheid binnen de organisatie stijgt. Juridische risico's worden groter.
Daardoor stellen veel organisaties escalatie uit in afwachting van meer zekerheid. Alleen bestaat die zekerheid meestal niet tijdens de eerste fase van een incident.
Cybersecurityonderzoek werkt met waarschijnlijkheden. Vroege indicatoren zijn vrijwel altijd onvolledig en gefragmenteerd. Eerste hypotheses blijken later regelmatig onjuist.
Toch handelen veel organisaties nog steeds alsof escalatiebeslissingen pas genomen mogen worden wanneer alle feiten vaststaan.
Onder NIS2 werkt die aanpak niet.
Incident response-processen moeten daarom worden ingericht om besluitvorming mogelijk te maken ondanks onzekerheid, niet pas nadat onzekerheid verdwenen is.
De echte uitdaging: beslissingen nemen in onzekerheid
Het doel van incidentescalatie onder NIS2 is niet om ervoor te zorgen dat elke rapporteringsbeslissing perfect is.
Dat zou onrealistisch zijn tijdens een lopend incident waarbij het onderzoek nog bezig is.
Het werkelijke doel is ervoor te zorgen dat beslissingen redelijk en verdedigbaar zijn op basis van de informatie die op dat moment beschikbaar was.
We moeten begrijpen dat technische ernst alleen niet volstaat en dat eigenaarschap voor escalatie al vóór een incident moet worden vastgelegd.
We moeten erkennen dat wachten op bevestigde impact soms meer risico creëert dan het vroegtijdig beoordelen van een plausibele impact.
En misschien nog belangrijker: we moeten onzekerheid expliciet erkennen in plaats van ze te gebruiken als reden om beslissingen uit te stellen.
Daarom moeten operationele urgentie en regulatoire significantie duidelijk van elkaar worden gescheiden.
Een severity-score van een SOC mag niet automatisch bepalen of een incident meldingsplichtig wordt.
Technische severity meet operationeel risico. Regulatorische significantie vereist een bredere beoordeling die rekening houdt met bedrijfsafhankelijkheden, klantimpact, blootstelling van derden, juridische implicaties en systeemrelevantie.
Die bredere beoordeling kan alleen worden gemaakt wanneer vooraf duidelijk is vastgelegd hoe technische analyse, juridische interpretatie, managementverantwoordelijkheid en regulatorische besluitvorming tijdens crisissituaties samenwerken.
Dat betekent niet dat elk verdacht event meldingsplichtig wordt.
Het betekent wel dat onzekerheid zelf wordt meegenomen als factor binnen de risicobeoordeling.
Praktische richtlijnen voor escalatiebeslissingen
Organisaties hebben gestructureerde beslissingscriteria nodig waarmee incidenten consistent kunnen worden beoordeeld vanuit technisch, operationeel en regulatorisch perspectief.
Bij Cingulum moedigen we klanten aan om tegelijkertijd vier vragen te beantwoorden:
- Kunnen kritieke diensten onbeschikbaar worden?
- Kunnen klanten, leveranciers of partners worden getroffen?
- Valt het incident mogelijk binnen de meldingsplicht van NIS2?
- Hoe betrouwbaar is de beschikbare informatie?
Tijdens deze beoordeling wordt één aspect van incident governance vaak over het hoofd gezien: traceerbaarheid van beslissingen.
Organisaties moeten achteraf kunnen reconstrueren hoe escalatiebeslissingen tot stand kwamen: welke informatie beschikbaar was, welke aannames werden gemaakt, wie betrokken was bij de discussie en waarom de gekozen aanpak onder de gegeven omstandigheden als redelijk werd beschouwd.
Toezichthouders begrijpen dat organisaties tijdens actieve incidenten nooit perfecte zichtbaarheid hebben.
Wat moeilijker te verdedigen is, zijn inconsistente redeneringen, onvoldoende gedocumenteerde beslissingen of onduidelijke verantwoordelijkheden.
In de praktijk leidt zwakke documentatie vaak tot meer regulatoir risico dan een onvolmaakte technische beoordeling.
Conclusie: NIS2 herdefinieert de rol van cybersecurity-leiderschap
Eén van de meest onderschatte gevolgen van NIS2 is dat het de verwachtingen ten aanzien van cybersecurity-leiderschap fundamenteel verandert.
Historisch werd incident response vooral beschouwd als een technische operationele capaciteit. Succes werd gemeten aan de hand van detectiesnelheid, containment en hersteltijd.
Die capaciteiten blijven essentieel, maar zijn niet langer voldoende.
Vandaag wordt van cybersecurity-verantwoordelijken verwacht dat zij ook governance-leiders zijn, die operationele realiteit, regulatorische verplichtingen, reputatierisico's en bedrijfscontinuïteit tegelijkertijd kunnen afwegen.
Voor veel organisaties zal dat uiteindelijk de moeilijkste uitdaging blijken.
Over Cingulum
Als onderdeel van The CRANIUM Group biedt Cingulum cybersecurity-oplossingen op maat. Door diepgaande expertise te combineren met geavanceerde technologieën helpt Cingulum organisaties veilig, compliant en weerbaar te blijven in een steeds veranderend dreigingslandschap.
Dit artikel werd geschreven door Willem Magerman, Expert Consultant & Lead Auditor bij Cingulum.
-
Ontdek meer over Cingulum via https://cingulum.eu
-
Ontdek meer over de partnerships van Easi via https://easi.net/nl/partnerships
