De NIS2-richtlijn stelt hogere eisen aan cyberrisicobeheer en incidentafhandeling. In Nederland wordt NIS2 omgezet in de Cyberbeveiligingswet (Cbw). Een Security Operations Center (SOC) kan de operationele basis leveren voor snelle detectie, onderzoek, escalatie en technische rapportage. Een SOC maakt een organisatie echter niet automatisch compliant: bestuur, juridische beoordeling, risicobeheer en de formele meldplicht blijven bij de organisatie.
Wat vragen de NIS2-richtlijnen van incident response?
NIS2 verlangt dat organisaties passende en evenredige maatregelen nemen om cyberrisico’s te beheersen en de gevolgen van incidenten te beperken. Incident response is daar een belangrijk onderdeel van. De organisatie moet niet alleen een plan hebben, maar ook kunnen aantonen dat incidenten tijdig worden herkend, beoordeeld, beheerst en geëvalueerd.
In de praktijk vraagt dat om:
- continue zichtbaarheid op kritieke IT-, cloud- en waar relevant OT-systemen;
- duidelijke criteria voor de classificatie van incidenten;
- vastgelegde rollen, bevoegdheden en escalatiepaden;
- beschikbare logs en technisch bewijs;
- geoefende procedures voor containment, herstel en communicatie;
- een proces voor wettelijke meldingen en tussentijdse updates;
- evaluatie en verbetering na ieder relevant incident.
De exacte drempels voor een significant incident kunnen per sector verschillen. Leg daarom vooraf met security, management, legal en compliance vast wanneer een technische gebeurtenis mogelijk meldingsplichtig wordt.
Let op: de Nederlandse wetgeving is nog in ontwikkeling
NIS2 wordt in Nederland geïmplementeerd via de Cyberbeveiligingswet. Volgens de actuele informatie van het NCSC is die wet op het moment van schrijven nog niet in werking getreden. Tot de inwerkingtreding kunnen organisaties incidenten in het kader van de Cbw vrijwillig melden. Bereid de processen en techniek wel alvast voor, zodat de organisatie bij het ingaan van de wet niet vanaf nul hoeft te beginnen.
Controleer altijd welke regels op de organisatie van toepassing zijn. Voor bepaalde financiële organisaties kan bijvoorbeeld DORA leidend zijn en sectorspecifieke regelgeving kan aanvullende eisen stellen.
De meldtermijnen: 24 uur, 72 uur en één maand
Zodra de Cyberbeveiligingswet van toepassing is, kent de meldprocedure voor een significant incident meerdere fasen. De termijnen starten wanneer de organisatie zich bewust is geworden van het incident.
| Moment | Melding | Benodigde informatie |
|---|---|---|
| Binnen 24 uur | Vroege waarschuwing | Een eerste indicatie van het incident, inclusief of sprake lijkt van kwaadwillig handelen of mogelijke grensoverschrijdende impact. |
| Binnen 72 uur | Incidentmelding | Een eerste beoordeling van ernst en impact, aangevuld met beschikbare indicatoren van compromittering. |
| Binnen één maand | Eindverslag | Een uitgebreidere beschrijving, waarschijnlijke oorzaak, genomen en lopende maatregelen en eventuele grensoverschrijdende gevolgen. |
Een bevoegde instantie of CSIRT kan daarnaast om een tussentijdse rapportage vragen. Is het incident na één maand nog niet opgelost, dan kan eerst een voortgangsrapport nodig zijn en volgt de definitieve rapportage later.
Wanneer is een incident significant?
Niet iedere securityalert is een meldingsplichtig incident. Een SIEM kan duizenden gebeurtenissen verzamelen, terwijl slechts een klein deel onderzoek vereist. Een SOC brengt structuur aan in de keten van event naar alert, bevestigd incident en mogelijk significant incident.
Bij de eerste beoordeling zijn onder meer relevant:
- de duur en technische omvang van de verstoring;
- welke kritieke diensten, processen en locaties zijn geraakt;
- het aantal getroffen gebruikers of afnemers;
- financiële, operationele en maatschappelijke impact;
- verlies van vertrouwelijkheid, integriteit of beschikbaarheid;
- mogelijke impact in andere EU-lidstaten;
- betrokken leveranciers en ketenafhankelijkheden.
Een SOC levert feiten en een technische impactanalyse. De formele beslissing of een incident aan de wettelijke meldcriteria voldoet, hoort bij de daarvoor aangewezen verantwoordelijke binnen de organisatie.
Hoe ondersteunt een SOC NIS2-incidentrespons?
1. Continue detectie
Een SOC bewaakt relevante bronnen zoals identityplatformen, endpoints, firewalls, e-mail, cloudomgevingen, kwetsbaarheden en netwerkverkeer. Voor industriële organisaties horen daar ook passende OT-databronnen en veilige, vaak passieve monitoring bij. Door signalen te correleren, kan een analist een aanvalspad herkennen dat in één systeem onzichtbaar blijft.
2. Triage en prioritering
Analisten onderzoeken of een alert vals positief, verdacht of een bevestigd incident is. Zij voegen bedrijfscontext toe: is het account bevoegd, is het systeem bedrijfskritisch en raakt de activiteit een essentiële dienst? Een gezamenlijk severitymodel zorgt dat SOC, IT, OT en management dezelfde taal spreken.
3. Technisch onderzoek en bewijs
Voor een melding zijn betrouwbare tijdlijnen en feiten nodig. Het SOC bewaart onder andere wanneer de activiteit begon, wanneer de organisatie zich ervan bewust werd, welke assets en accounts betrokken zijn, welke indicatoren zijn gevonden en welke maatregelen zijn genomen. Dat onderscheid tussen detectietijd en bewustwordingsmoment is belangrijk voor het bewaken van termijnen.
4. Escalatie en containment
Een vooraf afgestemd playbook bepaalt wie wordt gewaarschuwd en welke acties zijn toegestaan. Denk aan het blokkeren van een account, isoleren van een endpoint of beperken van netwerkverkeer. In een OT-omgeving kan een standaardactie productie of veiligheid beïnvloeden; containment moet daar altijd met de bevoegde operationele verantwoordelijke worden afgestemd.
5. Input voor meldingen
Het SOC kan de technische input voor de vroege waarschuwing, incidentmelding en eindrapportage samenstellen. Dat omvat de omvang, ernst, vermoedelijke oorzaak, indicatoren van compromittering en actuele herstelmaatregelen. Legal, compliance of het aangewezen crisisteam controleert de rapportage en verzorgt de formele melding.
6. Leren en verbeteren
Na het incident volgt een evaluatie. Welke detectie werkte, welke logs ontbraken en verliep de escalatie snel genoeg? De uitkomst wordt vertaald naar betere detectieregels, extra databronnen, aangepaste bevoegdheden en een bijgewerkt playbook.
Welke informatie moet direct beschikbaar zijn?
Een NIS2-proof incidentproces begint vóór het incident. Zorg dat het SOC en crisisteam snel toegang hebben tot:
- een actuele inventaris van kritieke assets, diensten en eigenaren;
- contactgegevens van management, legal, privacy, communicatie en leveranciers;
- sectorale meldcriteria en relevante toezichthouders of CSIRT’s;
- logbronnen met gesynchroniseerde tijdregistratie en passende bewaartermijnen;
- netwerk-, identity- en endpointgegevens voor reconstructie van het incident;
- een beslisboom voor significantie en meldingsplicht;
- goedgekeurde containmentacties per type systeem;
- templates voor de 24-uurs-, 72-uurs- en eindrapportage.
Een technisch sterk SOC zonder actuele assetcontext kan de bedrijfsimpact moeilijk bepalen. Koppel daarom technische monitoring aan informatie over proceseigenaren, leveranciers, kritikaliteit en herstelprioriteiten.
Leveranciersincidenten en de keten
NIS2 legt nadruk op beveiliging van de toeleveringsketen. Een incident bij een IT-provider, cloudplatform of onderhoudspartner kan de eigen dienstverlening raken. Leg vast welke leverancier incidenten moet melden, binnen welke termijn en welke technische informatie beschikbaar komt.
Neem leveranciersverbindingen en beheerdersaccounts op in monitoring. Denk aan afwijkend remote access, nieuwe authenticatiemethoden, onverwachte datastromen en activiteit buiten onderhoudsvensters. Maak ook duidelijk wie bij een leveranciersincident de impact voor de eigen organisatie beoordeelt en de eventuele NIS2-melding coördineert.
Wat een SOC niet voor u oplost
Een SOC ondersteunt aantoonbare detectie en respons, maar vervangt geen compleet NIS2-programma. De volgende verantwoordelijkheden blijven bij de organisatie:
- bestuurlijke verantwoordelijkheid en toezicht;
- organisatiebrede risicoanalyses en beveiligingsbeleid;
- juridische interpretatie van de meldplicht;
- businesscontinuïteit en crisiscommunicatie;
- leveranciers- en contractmanagement;
- privacybeoordeling en communicatie met betrokkenen;
- het formeel indienen van meldingen.
Beschouw een SOC daarom als de operationele uitvoeringslaag binnen een breder governance- en risicobeheersingsprogramma.
Praktisch stappenplan voor NIS2-ready incident response
- Bepaal de scope: breng essentiële diensten, kritieke processen, IT-, cloud- en OT-assets en ketenpartners in kaart.
- Maak meldcriteria concreet: vertaal wet- en sectorregels naar een beslisboom die tijdens een incident bruikbaar is.
- Controleer de dekking: bepaal welke kritieke databronnen nog niet worden gemonitord en waar logging onvoldoende is.
- Verdeel verantwoordelijkheden: leg RACI, bereikbaarheid, beslissingsbevoegdheid en vervanging vast.
- Bouw playbooks: beschrijf detectie, onderzoek, containment, bewijsverzameling, herstel en rapportage per scenario.
- Richt een incidentdossier in: werk vanuit één tijdlijn met besluiten, bewijs, acties, eigenaren en deadlines.
- Oefen onder tijdsdruk: simuleer ransomware, cloudaccountmisbruik, datalekken en leveranciersincidenten.
- Meet en verbeter: volg detectie- en reactietijden, ontbrekende logbronnen, false positives en opvolging van verbeterpunten.
Een SOC-provider kiezen voor NIS2
Vraag een SOC-provider niet alleen of er 24/7-monitoring is. Onderzoek welke bronnen worden aangesloten, hoe incidenten worden geclassificeerd, wie bewijs veiligstelt en hoe snel de technische rapportage beschikbaar is. Leg vast welke containmentacties de provider zelfstandig mag uitvoeren en welke toestemming vereisen.
Controleer verder ervaring met uw sector, IT- en OT-omgevingen, rapportage, dataopslag, escalaties en samenwerking met interne crisisrollen. Een goede provider maakt verantwoordelijkheden expliciet en belooft niet dat een SOC op zichzelf compliance oplevert.
Wilt u detectie en incident response praktisch inrichten? Bekijk het Security Operations Center van Aumatics. Lees ook meer over een SOC voor OT-omgevingen en de afweging tussen een intern SOC en een SOC uitbesteden.