4.5.3. Aanvullende informatie over de maatregelen (incidentbeheer)

4.5.3.1. Beheer van incidenten als maatregel

4.5.3.1.1. Preventie, detectie en reactie

Maatregelen worden genomen als gevolg van een geïdentificeerd risico. Volgende mogelijkheden doen zich voor:

• Preventie: vermijden dat iets gebeurt of het verlagen van de waarschijnlijkheid dat het gebeurt;

• Detectie: detecteren van de (potentiële) schade zou een bedreiging optreden;

• Reactie: beperken van de schade wanneer een bedreiging optreedt of het effect hiervan gedeeltelijk of geheel corrigeren.

Bij preventieve maatregelen wordt de dreiging verkleint tot het niveau dat ze aanvaardbaar is.
Detectie maatregelen zorgen ervoor dat een dreiging en het gevolg ervan tijdig ontdekt wordt.
Reactieve maatregelen richten zich op de gevolgen indien een dreiging zich toch voordoet, door het inperken of herstellen van de schade.

Incident beheer is een reactieve maatregel.

4.5.3.1.2. De verschillende activiteiten van incident beheer

Een incident is een niet-geplande gebeurtenis in de dienstverlening of bedrijfsvoering waardoor de verwachte dienstverlening niet meer kan worden aangeboden of de bedrijfsvoering negatief beïnvloed wordt. In ITIL wordt een incident steeds behandeld in een helpdesk of servicedesk, maar soms beschikken organisaties enkel over een meldpunt of contact met ICT.
Incident beheer is het geheel van organisatorische en technische maatregelen dat ervoor zorgt dat een incident adequaat gedetecteerd, gemeld en behandeld wordt zodat de gevolgen voor de bedrijfsprocessen of schade ontstaan door het incident beperkt wordt tot een aanvaardbaar niveau. 
Beheer van incidenten omvat:

• Registratie en categorisatie van het incident;

• Bepalen van de prioriteit (op basis van impact en urgentie);

• Behandelen van het incident (eventueel via doorverwijzing naar de nodige specialisten);

• Escalatie van het incident indien nodig;

• Documentatie van het incident;

• Afsluiten van het incident.

Incidenten worden aangereikt door gebruikers of door systeemwaarschuwingen, deze laatste zijn afkomstig uit het proces ‘beheer van gebeurtenissen’ (voor meer informatie zie 4.3. Minimale maatregelen - Beheer gebeurtenissen )

4.5.3.1.3. Behandelen van informatieveiligheidsincidenten

Voor de derde activiteit in incident beheer (behandelen van het incident) wordt in dit document de focus gelegd op het behandelen van informatieveiligheidsincidenten. Behandelen van incidenten op het gebied van informatiebeveiliging omvatten de monitoring en detectie van informatie veiligheidsincidenten, maar ook het waarnemen van verdachte activiteiten door het personeel, en de uitvoering van de juiste acties als antwoord op deze gebeurtenissen. Het proces dat ervoor zorgt dat informatie veiligheidsincidenten netjes worden afgehandeld omvat volgende stappen:

1. Identificatie en documentatie

2. Beperken van de schade

3. Remediatie

4. Herstel

5. Communicatie

6. Rapportering en evaluatie

Hoe groot of hoe klein het informatie veiligheidsincident ook is, deze stappen maken deel uit van het afhandelen van het incident. Voor een incident met beperkte impact worden deze stappen eerder intuïtief uitgevoerd, maar bij grote incidenten, d.w.z. met grote impact, waarbij meerdere personen betrokken zijn in de aanpak, ziet men een duidelijke uitvoering van de verschillende stappen.
Hoe groter het incident, hoe meer personen betrokken zullen zijn bij de aanpak om het incident onder controle te krijgen: een incident zal er dan toe leiden dat een incident team wordt samen geroepen. Ook de grootte van de organisatie speelt hierbij een rol: kleinere organisaties zijn vaak flexibel genoeg om het incident informeel in te dijken, waarbij de belijning van de verschillende stappen minder duidelijk is afgetekend. De verschillende activiteiten worden toegelicht in het hoofdstuk: ‘De bouwstenen van incident beheer'.

4.5.3.1.4. Link met informatiebeveiliging

100% beveiliging bestaat niet. Incidenten kan men niet 100% voorkomen. (Informatie)veiligheidsincidenten zijn bijgevolg niet uit te sluiten. Het is dan ook zaak om de (informatie)veiligheidsdienst te betrekken bij de afhandeling van (informatie)veiligheidsincidenten.
In de praktijk betekent dit dat volgende functies deel uitmaken van het incident team:

• De CISO ingeval het incident gevolgen heeft voor de beveiliging van informatie en informatie verwerkende systemen;

• De DPO (indien deze functie bestaat in de organisatie) ingeval het incident gevolgen heeft voor de bescherming van persoonsgegevens;

• De safety manager ingeval het incident gevolgen heeft op de fysieke beveiliging en fysieke toegangscontrole. Ook als het incident zelf geen rechtstreekse gevolgen heeft op de beveiliging van informatie en informatie verwerkende systemen, is het mogelijk dat bij de afhandeling van het incident wijzigingen nodig zijn aan de (ICT) infrastructuur. Hierbij moet de impact op de beveiliging steeds in het vizier worden genomen.

4.5.3.1.5. Link met risicoanalyse

Risico beheer om incidenten te voorkomen

Een risicoanalyse heeft als doelstelling inzicht te geven in de risicofactoren en welke impact en risico’s deze met zich meebrengen. Dit inzicht helpt bij het nemen van maatregelen om risico's te beheersen. Deze maatregelen hebben betrekking op het beperken van de kans dat de gebeurtenis plaatsvindt en de impact van de risico’s. Een goed inzicht in de risico’s en de te nemen maatregelen om de risico’s te beperken tot een aanvaardbaar niveau heeft ook een gunstig effect op incidenten: er zullen minderincidenten voorkomen en/of de gevolgen ervan zijn beperkt.

Incidenten als input voor risicoanalyses

Anderzijds kan de informatie uit incidenten gebruikt worden om de risicoanalyse effectiever te maken. Immers, deze incidenten geven reële informatie over de bedreigingen die zich hebben voorgedaan en de gevolgen hiervan op de dienstverlening/bedrijfsvoering. Informatie over incidenten over een langere periode kan aldus gebruikt worden om een juistere kwalificatie van de waarschijnlijkheid van een bedreiging te bekomen.

Risicoanalyse tijdens incident beheer

Tot slot is het ook belangrijk om ervoor te zorgen dat risico’s die verband houden met het incident worden gemitigeerd. Dit kan bijvoorbeeld door gevonden kwetsbaarheden weg te werken, toegangsrechten te herzien of niet toegelaten software te verwijderen.

4.5.3.1.6. Link met logging als maatregel 

Bij het onderzoek naar mogelijke incidenten wordt veelvuldig gebruik gemaakt van de controle op logging uit systemen, netwerkapparatuur en programma’s. Los van de detectie, wordt logging ook achteraf gebruikt bij het reconstrueren van een incident of om te ontdekken welke systemen nog meer geraakt waren. Logs moeten bewaard worden volgens vaste regels en kennen per soort logging een bewaartermijn waarvan afgeweken kan worden (verlenging) als er een vermoeden is van een incident. Als logging op de juiste wijze bewaard en behandeld wordt, kan logging ook dienen als bewijsmateriaal voor de wet. Dan moet wel de integriteit van de logging goed ingericht zijn.

4.5.3.2. Succesfactoren voor een goed incident beheer

Om tot een efficiënt en effectief incident beheer te komen, zijn volgende parameters belangrijk. Zij kunnen meegenomen worden als prestatie-indicatoren of KPI’s (zie hoofdstuk: ‘Prestatie-indicatoren (KPI’s)’) om het succes of falen van het proces te meten en bij te sturen waar nodig:

• Tijdigheid: een incident moet tijdig opgemerkt en aangepakt worden.
  Voorbeeld KPI: doorlooptijd vanaf aanname van een incident tot afsluiten van een incident, hoeveelheid afgehandelde incidenten per periode (bvb week, maand) t.o.v. het totaal aantal incidenten.

• Volledigheid: elk incident dat zich voordoet moet juist en volledig gedocumenteerd worden.
  Voorbeeld KPI: aantal niet geregistreerde incidenten, aantal onvolledig geregistreerde incidenten.

• Beschikbaarheid helpdesk/service desk: ondersteuning moet beschikbaar zijn voor gebruikers.
  Voorbeeld KPI: openingstijden helpdesk/service desk, wachttijden.

• Juistheid: een incident moet correct verholpen worden en de betrokkenen moeten correct geïnformeerd worden. Voorbeeld KPI: % de eerste maal correct verholpen incidenten, % van de verstoringen, waarbij de klant juist is geïnformeerd.

• Deskundigheid: er moet voldoende opgeleid personeel aanwezig zijn om incidenten vlot, correct en juist aan te pakken. Voorbeeld KPI: % functioneel geëscaleerde incidenten ten opzichte van het totaal aantal incidenten %, % hiërarchisch geëscaleerde incidenten ten opzichte van het totaal aantal incidenten %.

• Klantvriendelijkheid: dit is vooral belangrijk naar de ondersteuning van gebruikers. Voorbeeld KPI: aantal klachten over het functioneren van de helpdesk/service desk.

4.5.3.3. De bouwstenen van incident beheer

4.5.3.3.1. Registratie en categorisatie van het incident

Deze activiteit omvat de melding door een eindgebruiker aan de helpdesk of service desk, maar kan ook het gevolg zijn van detectie van incidenten door de ICT-beveiliging, doordat bij de controle van de logging iets naar boven komt of detectie door systeem/toepassingsmonitoring. In dit laatste scenario wordt de melding aangereikt vanuit het proces voor beheer van gebeurtenissen (‘event management’).

Het is belangrijk om elk incident zorgvuldig te registreren. Analoge incidenten kunnen later plaatsvinden en vereisen misschien dezelfde of analoge afhandeling. Een incident kan tevens onderdeel zijn van of aanleiding geven tot een ander of groter incident. 

Het toewijzen van een categorie aan een incident laat toe om het incident vlot te documenteren en de informatie op te zoeken. Aan de hand van de categorie kan ook gezien worden of het een terugkerend incident is. Het opstellen van de verschillende categorieën vraagt de nodige aandacht. Vaak worden een aantal categorieën gedefinieerd, waarbij een categorie ‘overige’ wordt voorzien om alle incidenten op te vangen die niet in de gedefinieerde categorieën thuishoren. Het risico bestaat dan dat deze ‘overige’ uit gemakzucht wordt gebruikt waardoor de toegevoegde waarde van het toewijzen aan categorieën verdwijnt.

De categorisatie van een incident is belangrijk om de documentatie, opvolging en toewijzing te vergemakkelijken en om trends vast te stellen die bvb bij probleem beheer, beheer van providers enz. kunnen worden gebruikt

4.5.3.3.2. Prioriteit bepalen van een incident

Het toewijzen van een prioriteit aan een incident geeft weer hoe ernstig en dringend een incident is en bepaalt de verdere afhandeling ervan. De prioriteit van een incident wordt bepaald door twee factoren:

• Impact: de omvang van het incident en de mogelijke schade als gevolg van het incident

• Urgentie: de maat voor hoe snel een incident moet worden afgehandeld Voor de inschatting van de urgentie van een incident worden schalen gehanteerd van laag naar hoog, waarbij de inschatting bepaald wordt door:

• De snelheid waarmee de schade toeneemt,

• Het type gebruikers of systemen dat getroffen is,

• Het aantal gebruikers of systemen dat getroffen is,

• De hoeveelheid werk om de schade te herstellen,

• De mogelijkheid om een groter incident als gevolg van het incident te voorkomen.

Voor de inschatting van de impact worden eveneens schalen gehanteerd van laag naar hoog, bepaald door:

1. Schade of impact voor de organisatie:

• Het aantal mensen dat geïmpacteerd is (hoeveel gebruikers, hoeveel afdelingen zijn getroffen),

• Het aantal betrokkenen dat geïmpacteerd is,

• Grootte van de financiële impact,

• Grootte van de lichamelijke schade,

• Mogelijke reputatieschade.

1. Wanneer het incident persoonsgegevens betreft, wordt de impact bovendien gerelateerd aan:

• De aard en de omvang van de inbreuk,

• De aard van de getroffen persoonsgegevens,

• De mate waarin technische maatregelen getroffen zijn ter bescherming van de getroffen persoonsgegevens,

• De gevolgen voor de persoonlijke levenssfeer van de betrokkenen.

Impact en urgentie worden tegen mekaar afgezet om de prioriteit te bepalen, wat wordt weergegeven in een prioriteiten matrix: 

Indicatoren de prioriteit van een incident kunnen beïnvloeden, zijn:

• Bedrijfskritische toepassingen of processen zijn betrokken bij het incident,

• Bedrijfskritische personen zijn getroffen.

De verwachte doorlooptijd voor de afhandeling van een incident hangt af van de prioriteit die aan het incident werd toegekend:

Reactietijd: tijd tussen aanmelden en eerste reactie;

Oplossingtijd: tijd tussen aanmelden en oplossen of inperken van het incident. Het vaststellen van de prioriteit van een incident is geen statisch of eenmalig gegeven: het is mogelijk dat gedurende de levensloop van een incident de prioriteit wijzigt, bvb omdat meer informatie ter beschikking komt of omdat de gevolgen van een incident veranderen. Een op zich staand klein incident kan bovendien de voorbode zijn van een groter of complexer incident. Zo zal een incident gemeld door één gebruiker waarschijnlijk geen hoge prioriteit krijgen, maar dat verandert snel zodra meerdere gebruikers een gelijkaardige melding plegen.
Wanneer beroep gedaan wordt op externe dienstverlening, is een prioriteiten matrix vaak al vastgelegd door de dienstverlener. Het volstaat dan om eenvoudig bovenstaande matrix te mappen op de matrix van de dienstverlener.

4.5.3.3.3. Behandelen van het incident

We beperken ons tot de bouwstenen nodig voor het afhandelen van informatie veiligheidsincidenten.

Beperken van de schade

In deze stap wordt verdere schade als gevolg van het incident zoveel mogelijk ingeperkt. Een verdere, grondige beoordeling van de aard en omvang van het incident dringt zich op. Er moet vastgesteld worden wat de schade is en eventueel bewijsmateriaal moet veiliggesteld worden. Indien het een verwerking van persoonsgegevens betreft, moet bepaald worden of er een inbreuk heeft plaats gevonden dat onder de meldplicht AVG valt. Er worden tevens maatregelen genomen om de oorzaak van het incident te blokkeren of te verwijderen, de impact te verminderen door verdere blootstelling aan de oorzaak van het incident te voorkomen.

Vaak wordt een team toegewezen aan het incident – het incident team. Dit team is belast met het vaststellen van de schade en een grondige beoordeling van de aard en omvang van het incident. Ook hier speelt de grootte van de organisatie een rol: kleine(re) organisaties hebben vaak geen ‘echt’ incident team, maar leunt op de verschillende medewerkers om het incident aan te pakken en de schade te beperken. Een belangrijke actie is tevens het veiligstellen van bewijsmateriaal dat kan dienen ingeval het incident het gevolg is van een inbraak poging. Voorbeelden van zo’n bewijsmateriaal zijn:

• Images van disks,

• Netwerkverkeergegevens van en naar de gecompromitteerde apparatuur,

• Log bestanden van toepassingen, systemen en toegangslogs.

Een incident onder controle krijgen betekent dus het beperken van de schade, het verhinderen dat andere systemen hinder ondervinden van het incident en het eventuele stoppen van een aanval. Zo kan een toepassing van het internet afgeschakeld worden om te voorkomen dat een cyberaanval zich voortzet. Er moet verhinderd worden dat het incident zich uitbreidt, zowel binnen de organisatie als buiten de organisatie (derde partijen waarmee de ICT-systemen geconnecteerd zijn). In sommige gevallen is het zelfs niet mogelijk om de normale activiteiten van de organisatie onmiddellijk te hernemen. In dit geval zal getracht worden om zo snel mogelijk de basisfunctionaliteiten te laten functioneren en ervoor te zorgen dat (een deel van) de bevoegde gebruikers hun toegang behouden. 

Remediatie

Remediatie is een belangrijke stap in het beheersen van een incident. Remediatie houdt in dat de oorzaak van het incident geblokkeerd of weggenomen wordt. Voorbeelden van remediatie zijn: services of processen stoppen, corrupte toepassingen verwijderen, computers opnieuw opstarten, gebruikersaccounts uitschakelen, netwerkverbindingen sluiten, caches flushen. Het wegnemen van de oorzaak van een incident kan vele vormen aannemen, bvb:

• Een virus- of spywarescanner gebruiken om de kwaadaardige bestanden en services te verwijderen;

• Handtekeningen bijwerken;

• Malware verwijderen;

• Aangetaste gebruikersaccounts uitschakelen;

• Wachtwoorden van aangetaste gebruikersaccounts wijzigen;

• Alle uitgebuite kwetsbaarheden identificeren en verhelpen;

• Gaten in de veiligheid identificeren en herstellen.

Herstel

In deze fase wordt het systeem/de systemen hersteld zodat de bedrijfsprocessen en -functies terugkeren naar de normale werking. Vaak zijn er verschillende opties om te herstellen na een incident en moet er bekeken worden welke de beste keuze is op gebied van hersteltijd, kostprijs en herstel of beperking van potentieel gegevensverlies.

Wanneer een systeem of systemen opnieuw moeten worden heropgebouwd, is het aspect beveiliging belangrijk: vooraleer het systeem opnieuw in gebruik wordt genomen, moet het worden goedgekeurd op niveau beveiliging. 

Communicatie

Communicatie is een belangrijke stap in het incident beheersproces: dit betekent controle houden over de informatiestroom en ervoor zorgen dat geautoriseerde personen de juiste informatie op het juiste moment bij de juiste belanghebbenden bezorgen. Het gaat zowel over interne als over externe communicatie. 

Als er een inbreuk is waarbij melding aan de GBA (Gegevensbeschermingsautoriteit) verplicht is, dan is de eerste melding al gebeurd. Op basis van het detailonderzoek kan nu de volledige melding voorbereid en uitgevoerd worden. Als nu pas blijkt dat er een meldplicht is voor een inbreuk, dan moet de volledige melding gedaan worden (als de wettelijke termijn van 72 uur overschreden is, dan moet dat worden gemotiveerd). Indien noodzakelijk moeten andere overheidsinstanties op de hoogte worden gebracht. 

Communicatie naar eindgebruikers, en eventueel externe communicatie naar vb. pers en media kan ook een noodzakelijke stap zijn.
Het type incident en de (mogelijke) gevolgen ervan bepalen het type communicatie en het tijdsstip van communiceren dat nodig is. Daarom is het belangrijk om vooraf de verschillende belanghebbenden te identificeren:

Bij het opzetten van een communicatieplan voor het incident moet er rekening worden gehouden met het verstrekken van regelmatige updates over het incident. Afhankelijk van de gevolgen van het incident moet het communicatieplan verschillende doelstellingen
dienen:

• Communicatie om het incident aan te pakken en op te lossen;

• Communicatie gericht op compliance, dit omvat communicatie naar getroffen gebruikers en aan toezichthouders;

• Communicatie om imagoschade te beperken, dit omvat communicatie met getroffen gebruikers, partners, media en werknemers.
  Meestal worden verschillende communicatiekanalen gebruikt:

• E-mail,

• Website (intern en publiek),

• Sociale media,

• Telefonisch,

• Tijdens overlegmomenten,

• Op papier (mededelingen op borden en deuren, overhandigd bij toegangspunten, …).

Rapportering en evaluatie

Het is nodig om relevante informatie te rapporteren aan belanghebbenden zoals o.a. (top)management (directie, raad van bestuur) en de informatieveiligheidsdienst (CISO, DPO, …). De doelgroep voor de rapportage is afhankelijk van organisatie tot organisatie en wordt best vooraf vastgelegd.

Grote veiligheidsincidenten moeten onmiddellijk aan het management worden gerapporteerd. Het is ook raadzaam periodiek de veiligheidsincidenten toe te lichten aan de mensen binnen de organisatie belast met het in kaart brengen van de risico’s voor de organisatie. Het kan noodzakelijk zijn om na een incident een evaluatie te maken van het incident, de ondernomen stappen en hoe dit incident in de toekomst kan worden vermeden, deze stap wordt ook lessons learned genoemd. Het resultaat van dergelijke analyse kan aanleiding geven tot een verbetervoorstel met volgende kenmerken:

• Een geplande wijziging: er kan geoordeeld worden dat een specifieke actie nodig is binnen een aanvaardbare termijn, deze wordt opgenomen via het proces wijzigingsbeheer;

• Een niet-geplande wijziging: het betreft een verbetervoorstel waarvan de implementatie datum niet onmiddellijk kan worden opgesteld, deze wordt opgenomen via het proces beheer van releases

4.5.3.3.4. Escalatie

Incidenten komen meestal op een min of meer centrale plaats terecht: vaak is dit een service desk, maar in organisaties waar deze functionaliteit ontbreekt, zijn er vaak één of meerdere personen aangeduid waar gebruikers terecht kunnen met hun ICT-problemen en/of is er een ICT-team dat zich buigt over door systemen gegenereerde waarschuwingen.

In eerste instantie zal de (servicedesk) medewerker controleren of een vergelijkbaar incident eerder is voorgekomen en of er een oplossing of work around voorhanden is. Sommige incidenten hebben echter geen voor de hand liggende oplossing of vragen meer expertise. Deze incidenten worden dan doorverwezen naar iemand met meer kennis of meer beslissingsbevoegdheid: het incident wordt dan geëscaleerd. Bij escalatie maakt men onderscheid tussen functionele en hiërarchische escalatie:

• Functionele escalatie: doorverwijzing naar iemand met meer kennis, ook wel horizontale escalatie genoemd;

• Hiërarchische escalatie: doorverwijzing naar iemand met meer bevoegdheden, ook wel verticale escalatie genoemd.

Voor functionele escalatie gelden criteria zoals kennis en ervaring. Er wordt vaak ook gesproken over eerstelijnssupport (service desk), tweedelijnssupport en (gespecialiseerde teams) en zelfs derdelijns support (leveranciers).
Gedurende het traject wordt het incident record voortdurend bijgewerkt door de medewerkers die aan het incident werken.
Wanneer er geen oplossing voor het incident voorhanden is, wordt het doorverwezen naar het proces probleem beheer (voor meer informatie zie 4.6. Minimale maatregelen - Probleembeheer )

4.5.3.3.5. Documentatie van het incident

Het is belangrijk om elk incident en de ondernomen acties te documenteren en al deze informatie bij te houden. Hoe incidenten worden gedocumenteerd, hangt af van de grootte van de organisatie: voor grote organisaties, (ICT) providers en dienstenleveranciers met een professionele helpdesk/ servicedesk is een geautomatiseerde opvolgingstool onontbeerlijk. Voor kleine organisaties kan het volstaan om de incidenten te registreren in een eenvoudig logboek.

Er is ook de wettelijke verplichting tot het bijhouden van een register van incidenten rond persoonsgegevens wanneer de organisatie persoonsgegevens verwerkt (noteer dat elke organisatie minstens de gegevens van haar werknemers verwerkt – een organisatie vinden die geen persoonsgegevens verwerkt, is dus een moeilijke opgave).
Het documenteren van informatie over incidenten moet op een gestandaardiseerde manier verlopen, om te verzekeren dat het efficiënt en effectief gebeurt. Voor niet geautomatiseerde meldingen van gebeurtenissen moeten minstens volgende elementen bijgehouden worden:

• Wat was de gebeurtenis?

• Wie heeft de feiten vastgesteld?

• Wanneer heeft de gebeurtenis plaatsgevonden?

• Wanneer werden de feiten vastgesteld?

• Hoe werd de gebeurtenis veroorzaakt?

• Hoe werden de feiten vastgesteld?

• Wat heeft de gebeurtenis beïnvloed?

• De (potentiële) impact van de gebeurtenis op de activiteiten van de organisatie. Deze impact kan verband houden met de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en hun rol in het bedrijfsproces

Incidenten worden best gedocumenteerd, inclusief datum en tijd, in incident records, waarbij elk record slaat op één enkel incident. Dit geldt zowel voor incidenten die zijn gemeld door personen, als voor incidenten die automatisch zijn opgespoord via systeem event waarschuwingen. Documenteer alle relevante informatie over de aard van het incident zodat een volledig en historisch record ontstaat. Als het incident dan moet worden overgedragen naar andere (support) groepen, hebben ze alle nodige informatie ter beschikking. Een incident record omvat:

• Een uniek referentienummer;

• Incident categorie;

• Incident prioriteit (op basis van urgentie en impact);

• Naam van de persoon of afdeling die het incident heeft geregistreerd;

• Beschrijving van het incident;

• Ondernomen activiteiten;

• Status van het incident;

• Aan wie het incident werd overgedragen.

Software kan de registratie van incidenten helpen en gedeeltelijk automatiseren. Dit gebeurt in (incident) ticketing systemen. Essentiële functies van zo’n ticketing systeem zijn:

• Workflow beheer;

• Alerts beheren en escaleren;

• Automatische routing;

• Contract en SLA beheer.

Merk op dat niet alleen incidenten in zo’n ticketing systeem worden geregistreerd, maar ook service aanvragen en aanvragen voor informatie. Het is ook belangrijk om de laatst bekende informatie van het incident goed bij te houden en te registreren: de prioriteit kan bvb in de loop van de afhandeling wijzigen, het incident kan toegewezen worden aan een andere supportgroep, de status van het incident wijzigt in de loop van de afhandeling enz. Deze nieuwe informatie moet toegevoegd worden aan het incident record zodat het record op elk moment de laatste bekende informatie over het incident bevat.

4.5.3.3.6. Helpdesk/service desk

Een helpdesk is bedoeld om de klant of interne gebruiker van informatie en ondersteuning te voorzien met betrekking tot bedrijfsprocessen, producten en diensten. Het doel van een helpdesk is om een centrale bron van antwoorden te zijn, problemen op te lossen en bekende problemen te helpen oplossen. Helpdesk support kan langs verschillende kanalen aangeboden worden, waaronder fysieke locaties, gratis telefoonnummers, websites, instant messaging of e-mail. Een helpdesk kan deel uitmaken van een service desk.
De primaire rol van de helpdesk bestaat uit:

• Optreden als SPOC (Single Point of Contact) voor gebruikers;

• Registratie, documentatie en opvolging van incidenten;

• Routeren van incidenten (functionele en hiërarchische escalatie);

• Eerstelijnssupport voor oplossen van incidenten.

De primaire rol van een IT-service desk is om als centraal contactpunt te dienen voor het controleren/beheren van incidenten, het behandelen van de (aan)vragen van gebruikers en als communicatiekanaal tussen verscheidene service managementfuncties en de gebruikers. Daarnaast speelt de service desk vaak een actieve rol bij het ontdekken van veranderingsverzoeken, contact met ondersteuningscontracten van derden, het management van software licenties en assistentie bij probleemmanagement.

De primaire rol van een service desk is:

• Optreden als SPOC (Single Point of Contact) voor alle bedrijfsprocessen;

• Integratie met andere processen zoals wijzigingsbeheer, configuratiebeheer, release management en probleembeheer;

• Ondersteunt conformiteit met Service Level Management contracten;

• Ondersteunt de service cataloog.

Het grote verschil tussen een service desk en een helpdesk, is dus dat de helpdesk een probleem meestal alleen registreert, oplost (aan de hand van gekende oplossing of work around) of doorstuurt naar een tweede lijn. Bij een service desk ligt de dienstverlening hoger. Op een service desk worden bijvoorbeeld ook autorisaties verleend en ICT-gerelateerde bestellingen aangenomen. Zowel helpdesk als service desk kunnen intern opgenomen worden of uitbesteed aan dienstenleverancier.

4.5.3.3.7. Het incident team

Wanneer een incident van enige omvang de organisatie teistert, is vaak een team van specialisten nodig om het incident aan te pakken. Er moeten immer activiteiten vanuit verschillende invalshoeken opgestart worden om een antwoord te bieden op een aantal vragen zoals:

• Wie beantwoordt de interne vragen rondom incidenten?

• Welke taken moeten opgestart worden? Wie is verantwoordelijk voor deze taken?

• Wie beheert het incident aan de technische kant?

• Wie heeft beslissingsbevoegdheid?

• Wie onderhoudt het contact met de directie/raad van bestuur?

• Wie kan de externe partners contacteren?

• Wie kan de betrokken leveranciers en dienstenleveranciers contacteren?

• Wie kan een klacht indienen bij de autoriteiten en toezichthouders?

• Wie is belast met de communicatie met externen zoals pers, hulpdiensten, gebruikers?

Aangezien het hier om een diverse samenstelling van profielen gaat, is het logisch dat een team van personen samen het incident aanpakken. Voor een kleine organisatie zal het team eerder beperkt zijn en de communicatielijnen kort.
Om een incident van enige omvang aan te pakken, zijn er dus verschillende vaardigheden nodig om de verschillende verantwoordelijkheden en activiteiten op te nemen om op efficiënte wijze op het incident te reageren:

De grootte van de organisatie bepaalt of en hoeveel functies er nodig zijn. Kleinere organisaties hebben vaak de flexibiliteit om zich voor de aanpak van het incident snel tot het management te wenden. Dit is niet het geval voor grotere organisaties. Daar zal het incident team de meeste incidenten op een meer autonome wijze behandelen, zodat de bedrijfstop alleen in geval van een bijzonder ernstig incident wordt betrokken. Hoe groter de organisatie, hoe gedifferentieerder de samenstelling van het incident team moet zijn. In grotere organisaties kan er naast een incident team ook een crisisteam worden samengesteld uit vertegenwoordigers van het ondernemingsbestuur die bij ernstige incidenten de verantwoordelijkheid opnemen voor de strategische en bedrijfsbeslissingen en de communicatie hierover. Op deze manier kan de incident manager zich meer richten op de technische kwesties van het incident. Kleinere organisaties zullen ook vaker beroep doen op externe experts, bvb voor forensisch onderzoek of juridische ondersteuning

4.5.3.3.8. Het proces

Alle bouwstenen samen maken deel uit van het proces voor het beheer van incidenten. Algemeen ziet dat er als volgt uit: