Incident Management

Wat is Incident Management?

Incident Management is het proces waarmee een organisatie verstoringen in IT- en OT-systemen detecteert, registreert, prioriteert, analyseert en oplost, met als doel de normale dienstverlening of productie zo snel mogelijk te herstellen en de schade te beperken. Een incident is daarbij elke onvoorziene onderbreking of kwaliteitsvermindering van een dienst, systeem of proces. Incident Management is een vaste practice in ITIL en komt terug in ISO 27001, IEC 62443 en de Cyberbeveiligingswet. In een fabriek gaat het niet alleen om een vastgelopen server, maar ook om een PLC die de verbinding verliest of een HMI die niet meer reageert.

🧠 Wat is een incident precies?

ITIL 4 definieert een incident als een ongeplande onderbreking van een dienst of een vermindering van de kwaliteit van die dienst. Een storing die nog geen gebruiker merkt, bijvoorbeeld een uitgevallen redundante voeding, telt dus ook mee: de kwaliteit is verminderd, want de reserve is weg.

Niet elke melding is een incident. Het helpt om de begrippen uit elkaar te houden:

Monitoring en logging leveren duizenden events per dag. Incident Management begint op het moment dat een event, via een gebruiker, een SIEM of een alarm, wordt beoordeeld als echte verstoring.

🎯 Wat is het doel van Incident Management?

• Minimale impact - productie, veiligheid en dienstverlening zo min mogelijk laten lijden
• Snelle hersteltijd - een lage MTTR en voorspelbare reactietijden
• Gestandaardiseerde aanpak - elk incident volgt dezelfde route, ongeacht wie dienst heeft
• Registratie - gegevens voor analyse, compliance, audits en verbetering
• Afstemming - IT, OT, security, onderhoud en operatie werken vanuit één beeld

Het herstel staat voorop, niet de oorzaak. Een workaround die de lijn weer laat draaien is een geslaagde incidentafhandeling, ook als de onderliggende fout nog bestaat.

🔁 Welke stappen doorloopt een incident?

1. Detectie - het incident wordt opgemerkt door een gebruiker, operator, monitoring of SIEM
2. Registratie - vastleggen in een ticketsysteem of logboek, met tijdstip, melder en getroffen systemen (bij voorkeur gekoppeld aan de CMDB)
3. Classificatie en prioritering - categorie, impact en urgentie bepalen
4. Diagnose - eerste analyse, kennisbank en bekende fouten raadplegen
5. Escalatie - functioneel naar de tweede of derde lijn, de leverancier of het OT- of securityteam; hiërarchisch naar het management bij een major incident
6. Oplossing of workaround - herstel, eventueel tijdelijk, en controle dat de dienst echt weer werkt
7. Afsluiting - terugkoppeling aan de melder, documentatie en zo nodig doorzetten naar problem management

Bij een vermoedelijk beveiligingsincident gaat de afhandeling na stap 3 over naar Incident Response: indammen, bewijs veiligstellen en uitroeien gaan dan vóór snel herstarten, omdat een herstart sporen kan wissen.

📊 Hoe bepaalt u de prioriteit van een incident?

De gangbare methode is een matrix van impact (hoeveel gebruikers, installaties of productie worden geraakt) en urgentie (hoe snel loopt de schade op). Beide krijgen een waarde van hoog tot laag, en de combinatie levert de prioriteit.

Deze tijden zijn voorbeeldwaarden; de echte normen staan in de SLA met de interne IT-afdeling of de leverancier. In OT weegt de impact op veiligheid en milieu zwaarder dan het aantal getroffen gebruikers: één vastgelopen operatorstation in een continu proces is vaak P1.

🏭 Hoe verschilt Incident Management in OT-omgevingen?

• Veiligheid gaat voor herstel - een incident kan direct productie, veiligheid, milieu of productkwaliteit raken; eerst wordt het proces in een veilige toestand gebracht
• Niet blind herstarten - een PLC of SCADA-server herstarten kan het proces verstoren; dat gebeurt alleen in overleg met operatie
• Andere bronnen - veel OT-incidenten beginnen als procesalarm; goed alarmbeheer volgens ISA-18.2 voorkomt dat een echte storing verdwijnt in een alarmvloed
• Gemengde oorzaken - fysieke defecten, netwerkproblemen en cyberaanvallen, zoals malware of een DDoS-aanval, geven vaak dezelfde symptomen
• Meer partijen - productie, onderhoud, IT, security, leveranciers en soms de systeemintegrator moeten samenwerken, vaak buiten kantoortijd
• Koppeling met veiligheidsstudies - vastgelegde incidenten zijn input voor HAZOP, LOPA en wijzigingsbeheer; raakt een incident een SIS, dan geldt ook functionele veiligheid
• Continuïteit - Incident Management is de eerste schakel van Disaster Recovery en Business Continuity: bij een major incident beslist het team of het continuïteitsplan wordt geactiveerd

IEC 62443-2-1 (tweede editie, 2024) vraagt asset owners om dit in hun securityprogramma vast te leggen: security program element 7 behandelt event- en incidentmanagement, van detectie en rapportage tot afhandeling.

📚 Welke normen en kaders beschrijven Incident Management?

🔄 Wat is het verschil met Problem Management en Incident Response?

Problem management gebruikt root cause analysis om terugkerende incidenten te voorkomen. Incident Response is de gespecialiseerde tak voor cyberincidenten. Ook de CSIR, de richtlijn waarmee Rijkswaterstaat en waterschappen de BIO en IEC 62443 toepassen op objecten zoals gemalen en sluizen, bouwt voort op normen waarin incidentbeheer een vast onderdeel is. De drie processen delen één registratie, zodat een patroon in tickets kan uitgroeien tot een problem of een security-onderzoek.

🛠️ Hoe richt u Incident Management in de praktijk in?

1. Leg definities en prioriteiten vast - wat is een incident, wat is een major incident, en welke matrix geldt voor IT en voor OT
2. Kies één registratiepunt - één ticketsysteem of logboek voor IT én OT, met koppeling aan de CMDB of asset-inventaris
3. Regel bereikbaarheid - consignatiediensten, contactgegevens van leveranciers en een escalatieladder, ook voor de nacht en het weekend
4. Stel een major-incidentprocedure op - wie neemt de leiding, wie communiceert, wanneer wordt het continuïteitsplan geactiveerd
5. Koppel aan meldplichten - onder de Cyberbeveiligingswet, van kracht sinds 15 augustus 2026, meldt een essentiële of belangrijke entiteit een significant incident binnen 24 uur (vroegtijdige waarschuwing), 72 uur (incidentmelding) en een maand (eindrapport), zie Meldplicht Cyberbeveiligingswet; een datalek gaat volgens de AVG zo mogelijk binnen 72 uur naar de Autoriteit Persoonsgegevens
6. Oefen - een tabletopoefening toetst of IT, OT en management de procedure kennen
7. Meet en verbeter - evalueer elk major incident en volg een paar KPI’s

Gangbare meetwaarden zijn MTTA (gemiddelde tijd tot een melding is opgepakt), MTTR (gemiddelde hersteltijd), het percentage incidenten binnen de SLA, het aantal heropende tickets en het aantal incidenten per installatie. In combinatie met MTBF laat dit zien of een installatie vaker of juist korter stilstaat. Kleinere bedrijven besteden de bewaking vaak uit aan een SOC of OT SOC, maar het besluit over het stilleggen of herstarten van een installatie blijft bij de eigen organisatie.

❓ Veelgestelde vragen

Wat is het verschil tussen een incident en een event?

Een event is elke waarneembare gebeurtenis, zoals een logregel, inlogpoging of procesalarm. Een incident is een event dat een dienst of proces ongepland onderbreekt of de kwaliteit ervan vermindert. Incident Management filtert dus de echte verstoringen uit de grote stroom events.

Wat is een major incident?

Een major incident is een incident met zo’n grote impact dat het direct een gecoördineerde aanpak vraagt, met een vaste leider en eigen communicatielijn. Voorbeelden zijn een volledig stilstaande productielijn of een uitgevallen SCADA-systeem in een waterzuivering. Voor een major incident gelden kortere escalatielijnen en vaak een verplichte evaluatie achteraf.

Is Incident Management hetzelfde als Incident Response?

Incident Management is het brede proces voor alle verstoringen, van een kapotte printer tot een stilstaande machine. Incident Response is de gespecialiseerde afhandeling van beveiligingsincidenten, waarbij indammen en bewijs veiligstellen vóór snel herstel gaan. In een volwassen organisatie draagt Incident Management een vermoedelijk cyberincident direct over aan het Incident Response-team.

Wanneer moet een incident gemeld worden bij een toezichthouder?

Een organisatie onder de Cyberbeveiligingswet meldt een significant incident binnen 24 uur met een vroegtijdige waarschuwing, binnen 72 uur met een incidentmelding en binnen een maand met een eindrapport. Gaat het om persoonsgegevens, dan geldt daarnaast de AVG-meldplicht bij de Autoriteit Persoonsgegevens. Gewone storingen zonder significante impact hoeven niet gemeld te worden, maar worden wel intern geregistreerd.

Welke KPI’s horen bij Incident Management?

De belangrijkste KPI’s voor Incident Management zijn MTTA, MTTR, het percentage incidenten dat binnen de afgesproken SLA is opgelost en het aantal heropende incidenten. In OT-omgevingen wordt daarnaast vaak de stilstandtijd per installatie gevolgd. Samen laten deze waarden zien of de afhandeling sneller en betrouwbaarder wordt.

Waarom is Incident Management in OT lastiger dan in IT?

Incident Management in OT is lastiger omdat herstelacties direct invloed hebben op een fysiek proces, de veiligheid van mensen en het milieu. Een server herstarten is in IT meestal onschuldig, maar een PLC herstarten kan een batch of installatie verstoren. Daarom beslissen operatie en techniek samen, en gaat een veilige procestoestand altijd voor snel herstel.

📌 Samengevat

Incident Management zorgt voor een vaste, snelle aanpak bij elke verstoring, zodat systemen en productie met zo min mogelijk schade weer draaien. Het onderscheid tussen events, incidenten, problems en beveiligingsincidenten, een heldere prioriteitsmatrix en goede afspraken tussen IT, OT en leveranciers maken het verschil, zeker nu de Cyberbeveiligingswet strikte meldtermijnen oplegt.