4.4.3. Aanvullende informatie over de maatregelen (wijzigingsbeheer)

4.4.3.1. Beheer van wijzigingen als maatregel

4.4.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.

Wijzigingsbeheer is een reactieve maatregel.

4.4.3.1.2. De verschillende activiteiten van wijzigingsbeheer

Beheer van wijzigingen omvat (zie paragraaf 4.4.3. Aanvullende informatie over de maatregelen (wijzigingsbeheer) | 4.4.3.3. De bouwstenen van wijzigingsbeheer ):

• Registratie van een wijzigingsaanvraag;

• Goedkeuren van een wijzigingsaanvraag;

• Bepalen van de prioriteit van een wijzigingsaanvraag;

• Inplannen van de wijziging;

• Uitvoeren en validatie van de wijziging;

• Afsluiten van de wijziging.

Het proces wijzigingsbeheer kent 3 grote stappen:

• Ten eerste: de voorbereiding: registreren van de wijzigingsaanvraag tot en met het inplannen;

• Ten tweede: de uitvoering: in deze stap wordt de gevraagde én goedgekeurde wijziging ontwikkeld, getest en in productie gebracht;

• Ten derde: evaluatie en afsluiten: focust op het resultaat van de wijziging.

4.4.3.1.3. Link met PAM

Priviliged Access Management (PAM) is het proces voor het beheer van speciale toegangsrechten tot informatie verwerkende systemen of – in ITIL termen – de configuratie-items. Deze speciale toegangsrechten laten veel meer activiteiten op deze systemen toe dan de geijkte gebruikersrechten. Het is dan ook niet verwonderlijk dat het toekennen en gebruiken van deze rechten aan strenge regels moet voldoen teneinde fouten en misbruik te voorkomen.

Wijzigingen aan een configuratie-item in deze context van wijzigingsbeheer vereist in de meeste gevallen speciale toegangsrechten. Daarom is het belangrijk dat de wijzigingsaanvraag goed gemotiveerd wordt, goedgekeurd door een geautoriseerd persoon en dat enkel de uitvoerder(s) mag/mogen beschikken over deze speciale rechten in het tijdsbestek nodig om de wijziging tot een goed einde te brengen.

Pagina5.4. Minimale maatregelen - Priviliged Access Management (PAM) beschrijft de interacties tussen beide processen en de vereisten voor speciale rechten voor uitvoering van wijzigingen per informatieklasse. 

4.4.3.2. Succesfactoren voor een goed wijzigingsbeheer

Om tot een efficiënt en effectief wijzigingsbeheer 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:

• Kwaliteit van de voorbereiding: een goede voorbereiding en documentatie versnelt het autorisatie proces en vermindert het aantal iteraties om tot een wijziging te komen.

• Test en acceptatie van de wijziging: onvoldoende of ontbreken van testen kan leiden tot een implementatie met negatieve impact op de kwaliteit van de dienstverlening of de stabiliteit van de omgeving waardoor terugdraaien van de wijziging nodig kan zijn.

• Allocatie van middelen: bij de beoordeling van de wijzigingsaanvraag is het niet alleen belangrijk om de impact op de dienstverlening in te schatten maar ook de benodigde middelen (personeel, materie experten, tooling, …).

• Implementatie van wijzigingsbeheer: een goede inbedding van het proces in de ICT en zakelijke processen is nodig om niet-geautoriseerde wijzigingen te vermijden.

4.4.3.3. De bouwstenen van wijzigingsbeheer

4.4.3.3.1. De wijzigingsaanvraag

Strikt genomen hoort de aanmaak en het indienen van de wijzigingsaanvraag niet bij het proces wijzigingsbeheer, maar het is wel een noodzakelijke input.

Een wijzigingsaanvraag betreft een functionele wijziging of een technische wijziging (m.i. een wijziging i.h.k.v. beveiliging) of beiden.
Wijzigingen kunnen aangevraagd worden vanuit verschillende kanalen:

• Andere beheersprocessen zoals incident beheer, probleembeheer: indienen van een technische wijzigingsaanvraag naar aanleiding van een incident of probleem;

• Zakelijke processen: functionele wijzigingsaanvragen;

• Leveranciers: nieuwe releases en upgrades waarbij structurele fouten worden gemitigeerd of weggenomen nieuwe functionaliteiten zijn geïmplementeerd (zowel functionele als technische wijzigingen zijn mogelijk). Ook kunnen bepaalde versies niet langer worden ondersteund;

• Projecten: een project kan meerdere functionele en/of technische wijzigingen tot gevolg hebben;

• Wet- en regelgeving: nieuwe of veranderde wet- en regelgeving kan aanleiding geven tot nieuwe vereisten die vertaald worden in wijzigingsaanvragen.

Merk op dat gebruikers geen wijzigingen aanvragen; gebruikers mogen enkel vooraf goedgekeurde wijzigingen vragen via het proces ‘beheer van service aanvragen’ (voor meer informatie zie pagina 4.2. Minimale maatregelen - Beheer aanvragen.

Alle wijzigingsaanvragen moeten worden geregistreerd en uitvoerig gedocumenteerd. Er worden door wijzigingsbeheer eisen gesteld aan de wijze waarop een wijzigingsaanvraag wordt ingediend en welke informatie daarbij minimaal moet worden verstrekt.
De wijzigingsaanvraag moet minstens volgende informatie bevatten:

• Informatie met betrekking tot de indiener van de wijzigingsaanvraag;

• Informatie met betrekking tot de goedkeuring van de wijzigingsaanvraag;

• Datum en tijd waarop de wijzigingsaanvraag is ingediend;

• Een omschrijving van de voorgestelde wijziging:

• Indien van toepassing de referentie naar het achterliggende incident/probleem;

• De configuratie-items die betrokken zijn bij deze voorgestelde wijziging;

• Relaties of afhankelijkheden met andere (deel)processen;

• Een omschrijving wat de motivatie van de voorgestelde wijziging is;

• De resultaten van de voorgestelde wijziging, inclusief de consequenties als de voorgestelde wijziging niet wordt doorgevoerd;

• Een voorstel van de urgentie, inclusief motivatie, van de voorgestelde wijziging;

• De gewenste realisatiedatum, inclusief een motivatie;

• De impact op de zakelijke processen;

• De impact van de voorgestelde wijziging op het beveiligingsniveau;

• De impact van de voorgestelde wijziging op het beschermingsniveau van persoonsgegevens;

• De impact van de voorgestelde wijziging op de ICT-infrastructuur en ICT-dienstverlening.

Soorten wijzigingen

ITIL definieert twee verschillende soorten wijzigingen. Voor het inrichten van een effectief proces voor beheer van wijzigingen is het belangrijk een goed onderscheid tussen deze wijzigingen te maken.

• Gewone wijziging: Een gewone wijziging is een wijziging die binnen het vooropgestelde tijdsbesteken binnen de volledige workflow van het proces wijzigingsbeheer kan worden uitgevoerd zonder de zakelijke processen significant te benadelen.

• Noodwijziging: De noodwijziging is bedoeld voor wijzigingen, die fouten van een ICT-service herstellen, met in hoge mate een negatieve impact op de zakelijke processen en/of de ondersteunende infrastructuur. Noodwijzigingen wijken af van de normale procedures, omdat voor dit soort wijzigingen de benodigde middelen meteen moeten worden vrijgemaakt. Omdat noodwijzigingen afwijken van de normale workflow in het wijzigingsbeheer, moeten zij zoveel mogelijk vermeden worden, maar zeker na uitvoering goed opgevolgd en gedocumenteerd.

4.4.3.3.2. Goedkeuring van de wijzigingsaanvraag

De goedkeuring van de wijzigingsaanvraag geldt in eerste instantie de aanvraag zelf: is alle noodzakelijke informatie aanwezig? Is de aanvraag voldoende gedocumenteerd en gemotiveerd? 
Indien nodig moet de wijzigingsaanvraag door de aanvrager verder aangevuld worden.
Vervolgens moet de aanvraag geautoriseerd worden. Het goedkeuren van de wijziging gebeurt op 3 vlakken:

• Financiële goedkeuring: kosten-batenanalyse en budgettering;

• Zakelijke goedkeuring: goedkeuring van de gebruikers betreffende functionaliteitbehoefte en impact

Strikt genomen horen beide uitgevoerd te zijn vooraleer de wijzigingsvraag in het proces wijzigingsbeheer wordt opgenomen.

• Technische goedkeuring: technische impact, veiligheid en haalbaarheid;

Als de wijzigingsaanvraag is geaccepteerd, wordt de informatie voor het verdere verloop van de wijziging vastgelegd in een wijzigingsregistratie. In het verdere verloop van de wijziging wordt hier steeds meer informatie aan toegevoegd, zoals:

• De toegekende prioriteit;

• De toegekende categorie;

• Beoordeling van de impact en benodigde middelen, denk hierbij ook aan de kosten;

• Testresultaten;

• Implementatieplan inclusief een fall back plan;

• Actuele datum en tijd van de wijziging;

• De reden van een eventuele afkeuring van de wijzigingsaanvraag.

De CAB

De Change Advisory Board (CAB) is een beslissingsforum waarbij:

• De leden beslissingsbevoegdheid hebben;

• De CAB zodanig samengesteld is dat er een evenwicht bestaat tussen de belangen van de beheersorganisatie (continuïteit en stabiliteit) en de zakelijke omgeving (nieuwe functionaliteit);

• De leden van de CAB gezamenlijk over voldoende beheer-, exploitatie- en materiekennis beschikken om verantwoorde besluiten over de wijzigingen te kunnen nemen.

• De verantwoordelijke voor bijvoorbeeld informatiebeveiliging en bedrijfscontinuïteitsbeheer via de wijzigingsbeheerder hun standpunten over wijzigingen in de CAB kunnen inbrengen, of zijn zelf (al dan niet op ad hoc basis) lid van de CAB.

Niet alle organisaties richten een formele CAB in: kleinere organisaties waar de beslissingslijnen kort zijn en er minder partijen betrokken zijn, hebben vaak geen baat bij een CAB maar in grotere organisaties met veel wijzigingen kan een CAB een toegevoegde waarde hebben.
Voor een grote wijziging vindt de eindbeslissing vaak plaats op basis van raadpleging van de CAB. In de CAB zitten verschillende partijen, in sommige gevallen neemt een vertegenwoordiger voor de informatiebeveiliging (bvb CISO) of beveiliging van persoonsgegevens (bvb DPO) plaats. Het is echter niet de bedoeling deze voor iedere wijziging in te schakelen. Beveiliging dient immers zoveel mogelijk een geïntegreerd onderdeel te zijn van de normale taken. De wijzigingsbeheerder moet in staat zijn te beoordelen of hij, of de CAB, de input van de vertegenwoordiger voor informatiebeveiliging/ beveiliging persoonsgegevens nodig heeft.

Wanneer het gaat over noodwijzigingen is het mogelijk dat de volledige CAB niet kan deelnemen. Een nood-CAB moet dan oordelen. In geval van noodwijzigingen met onvoldoende autorisatie moet dit steeds gedocumenteerd én achteraf geverifieerd worden.

Goedkeuring van wijzigingsaanvragen

Een wijzigingsaanvraag moet steeds goedgekeurd worden, maar de mate van goedkeuring (wie erbij betrokken moet zijn) hangt af van de wijziging en van de betrokken informatie verwerkende componenten.
Voor de Vlaamse Overheid onderscheiden we 2 soorten goedkeuring:

• Goedkeuring door de toepassingseigenaar: deze bepaalt zelf wie er binnen de eigen organisatie goedkeuringsbevoegdheid heeft en hoeveel autorisaties nodig zijn om een wijzigingsaanvraag te kunnen indienen. Deze autorisaties gebeuren dus voor het indienen van de wijzigingsaanvraag.
  Het gaat hier vooral om de goedkeuring van de functionele wijzigingen, maar het is mogelijk dat ook de technische wijzigingen opduiken.

• Goedkeuring door de wijzigingsbeheerder (dienstenleverancier): afhankelijk van de wijziging en de betrokken informatie verwerkende systemen is één of zijn meerdere autorisaties nodig.

4.4.3.3.3. Bepalen van de prioriteit van de wijzigingsaanvraag

Voor wijzigingen geldt dat deze systematisch worden geëvalueerd op impact en dat deze worden geautoriseerd met inachtneming van de impactanalyse. Als de wijzigingsaanvraag is geaccepteerd, wordt de prioriteit en de categorie daarvan aangegeven. De prioriteit wordt bepaald door de urgentie en de impact:

• Urgentie: geeft aan hoe lang het duurt tot het niet uitvoeren van de wijziging een significante impact heeft op de zakelijke processen, dit wordt aangegeven door de aanvrager op de wijzigingsaanvraag.

• Impact: de mate waarin een wijziging effect heeft op de zakelijke processen. Voor de bepaling van urgentie en impact worden dezelfde categorieën als voor incidenten en  problemen gehanteerd met een aangepaste definitie voor wijzigingen.

Urgentie

De urgentie wordt als volgt bepaald: 

Impact

Prioriteit

De prioriteit wordt bepaald door impact en urgentie:

Open

Waarbij de wijziging moet worden uitgevoerd binnen volgend tijdsbestek (de aangegeven tijden zijn het verschil tussen tijdsstip van aanvraag en van uitvoering):

Open

De hoogste prioriteit voor wijzigingen is alleen van toepassing voor P1 incidenten en noodwijzigingen.

4.4.3.3.4. Planning van de wijziging

Zodra de wijziging is goedgekeurd kan zij ingepland worden. Afhankelijk van de prioriteit van de wijziging, de identificatie en toewijzing van de taken aan de noodzakelijke uitvoerders en de complexiteit van de wijziging, wordt de wijziging op de planning gezet.
De planning van de wijziging wordt door wijzigingsbeheer opgezet in een wijzigingskalender of wijzigingsplan. Het wijzigingsplan bevat details van alle goedgekeurde wijzigingen en hun planning. 
Leden van de CAB adviseren over de planning van een wijziging, want er moet rekening worden gehouden met de beschikbaarheid van het personeel, de middelen, de te maken kosten en de zakelijke omgeving.

De CAB kan, in overleg met de betrokken partijen, vaste periode instellen voor het doorvoeren van wijzigingen op momenten dat de dienstverlening daar geen, of zo min mogelijk, last van heeft. Geschikte momenten kunnen bijvoorbeeld worden gevonden in de weekenden of buiten de normale werktijden (kantooruren). Ook kunnen periodes worden vastgesteld waarin juist weinig of geen
wijzigen worden gepland, zoals binnen de kantooruren of rond de jaarwisseling.

4.4.3.3.5. Uitvoering van de wijziging

Een wijziging moet uitgewerkt worden, getest en kan dan pas in productie genomen worden. Het is mogelijk dat een ontwikkelingstraject moet worden opgestart. Alle stappen – van ontwikkeling over test/ acceptatie tot in productie stelling – zijn onderling gescheiden en kennen verschillende GO/NO GO momenten. De verschillende stappen moeten dus expliciet vrijgegeven worden om te vermijden
dat ontwerpfouten in productie terecht komen. Goedgekeurde wijzigingen worden doorgegeven aan de betrokken specialisten voor de ontwikkeling en samenstelling van de wijzigingen.
Bij het inschatten van de benodigde middelen van de wijziging moet men rekening houden met de volgende aspecten:

• Capaciteit en performantie van de betrokken dienst(en);

• Betrouwbaarheid, veerkracht en herstelbaarheid;

• Fall back-plannen;

• Beveiliging;

• De impact van de wijziging op andere diensten;

• De gewenste doorlooptijd van de wijziging;

• De benodigde middelen en de kosten, niet alleen voor de uitvoering van de wijziging maar ook voor support en onderhoud van de benodigde specialisten;

• Eventuele conflicten met andere wijzigingen.

Op noodwijzigingen, die niet volledig volgens de reguliere procedure kunnen worden afgehandeld, is een bijzondere procedure van toepassing die vereist dat overgeslagen controlestappen achteraf worden doorlopen.

Voordat wijzigingen kunnen worden doorgevoerd, moeten de wijzigingen eerst worden getest. Ter ondersteuning van wijzigingen dient afdoende aandacht te worden besteed aan communicatie.

Ontwikkeling

Niet alle wijzigingen hebben een expliciete ontwikkelfase. Zo worden eenvoudige wijzigingen (bijvoorbeeld het wijzigen van een parameter) ingepland en uitgevoerd. 

Het ontwikkelen kan inhouden dat er een nieuwe softwareversie komt, met nieuwe documentatie, handleidingen, installatieprocedures, inclusief een fall back plan en aanpassingen op de hardware. De wijzigingsbeheerder vervult hierbij een coördinerende rol.

Als onderdeel van de oplevering van een wijziging moet ook een fall back-procedure worden geschreven, om de situatie terug te kunnen draaien als de wijziging niet het gewenste resultaat oplevert. Hierin dient te worden beschreven onder welke voorwaarden tot een fall back wordt overgegaan en wie daartoe kan besluiten. Wijzigingsbeheer mag de wijziging niet goedkeuren als er geen fall back-procedure is.

Als de wijziging impact heeft op de gebruikersomgeving, dan zal er ook een communicatieplan moeten worden geschreven. Verder wordt in de ontwikkelfase een implementatieplan opgesteld en bekende fouten van te implementeren wijzigingen worden geregistreerd.

Validatie

Zowel de wijziging als de fall back-procedure en de invoermethode van de wijziging dienen grondig te worden getest. Afwijkingen van dit principe worden vooraf formeel goedgekeurd, eventueel achteraf in het geval van noodwijzigingen. De evaluatie op doeltreffendheid van wijzigingen is functioneel gescheiden van de uitvoering van wijzigingen.

Als het een wijziging betreft met impact op de informatiebeveiliging, wordt in overleg met de beveiligingsbeheerder bepaald of er specifieke informatiebeveiligingstesten uitgevoerd moeten worden (penetratietesten, code reviews et cetera). Waar nodig wordt apparatuur en programmatuur gecontroleerd op compatibiliteit met andere systeemcomponenten.

Testen worden uitgevoerd door de ontwikkelaars, degenen die de wijzigingsaanvraag hebben ingediend of vertegenwoordigers daarvan en beheerders van de betrokken informatie verwerkende systemen. Er dient een scheiding te zijn tussen de omgeving waar ontwikkeld is, de omgeving waar getest wordt en de operationele omgeving. Er moeten testen worden uitgevoerd door een partij die
niet de ontwikkelaar is.

Acceptatietesten worden uitgevoerd door zowel gebruikers (gebruiksacceptatie) als de beheerders (productie-acceptatietest). De acceptatietest maakt deel uit van het geheel aan testen die in het kader van de wijziging plaatsvinden. Ook zijn duidelijke voorschriften nodig voor het toezicht houden op de kwaliteit van het testen en van de documentatie van de testresultaten.

Post validatie zorgt ervoor dat na de implementatie van de wijziging geverifieerd wordt dat het resultaat van de wijziging het verwacht is en dat er geen negatieve of ongewenste effecten zijn opgetreden na de wijziging. Daarbij wordt gelet op de volgende zaken:

• Heeft de wijziging het beoogde doel bereikt?

• Zijn de gebruikers tevreden met het resultaat?

• Zijn er nevenverschijnselen opgetreden?

• Zijn de geraamde kosten en inspanningen niet overschreden?

Implementeren

Iedereen die vanuit de betrokken afdeling het beheer van de ICT-infrastructuur of ICT-dienstverlening onder zijn verantwoording heeft, kan worden belast met het implementeren van een wijziging. Wijzigingsbeheer ziet erop toe dat de wijziging op schema ligt. Er moet een duidelijk communicatieplan liggen waarin staat wie van de wijziging op de hoogte gebracht moeten worden gesteld. Bijvoorbeeld: gebruikers, netwerk-, systeembeheer, et cetera.

De wijzigingslog

Het is belangrijk om de historiek van de wijzigingen bij te houden in een wijzigingslog of ‘change log’.  Deze log laat toe om na te gaan welke wijzigingen wanneer werden uitgevoerd en door wie.

De log bevat informatie over:

• De configuratie-items betrokken bij de wijziging;

• Beschrijving van de doelstelling van de wijziging;

• Verwijzing naar de configuratie en/of release documenten;

• De goedkeuringen voor de wijziging: tijdsstip (datum en tijd) van aanvraag en goedkeuring, de aanvrager(s) en geconsulteerde partij(en), de persoon of personen die de validatie en/of goedkeuring hebben gegeven;

• De operationele afspraken;

• Informatie over de uitvoering van de wijziging: tijdsstip (datum en tijd), uitvoerder.

4.4.3.3.6. Evaluatie en afsluiting van de wijziging

Doorgevoerde wijzigingen worden na implementatie geëvalueerd in een lessons learned, waarbij in elk geval vastgesteld wordt of de wijziging niet tot incidenten heeft geleid en of de juiste classificatie is toegepast. Daarna wordt desgewenst in de CAB besproken of nog verdere nazorg nodig is. Is de wijziging een succes en zijn alle activiteiten en registraties voor de wijziging gecontroleerd op afronding, dan kan de wijzigingsaanvraag worden afgesloten. Is de wijziging geen succes, dan wordt de procesgang hervat op de plaats waar het misgegaan is, met een aangepaste werkwijze. Een wijziging mag niet worden afgesloten vooraleer alle bijhorende documentatie is opgeleverd; uitzonderingen op deze regel moeten goedgekeurd worden door de CAB.

4.4.3.3.7. Noodwijzigingen

De noodprocedure is bestemd voor wijzigingsaanvragen die een probleem met belangrijke impact en die acuut de voortgang van een proces belemmert, oplossen. Bij de noodprocedure wordt de levenscyclus van een wijzigingsaanvraag doorbroken. Volgende afwijkingen zijn mogelijk voor de verschillende afhandelingsprocedures:

• Wijzigingsbeheer registreert en beoordeelt het voorstel met voorrang vóór de standaardwerkzaamheden.

• Wijzigingsbeheer meldt het wijzigingsvoorstel ter voorbereidende besluitvorming aan bij de verantwoordelijke met betrekking tot de wijziging (bijvoorbeeld de projectleider). De verantwoordelijke neemt een voorlopig besluit ter voorbereiding van de besluitvorming in de CAB en roept zo snel mogelijk de CAB bijeen.

• Indien niet alle leden van de CAB bereikbaar zijn, zal een beperkte CAB gevormd worden.

•  De CAB komt op verzoek van de verantwoordelijke bijeen en beslist onmiddellijk over het voorstel. De verantwoordelijke stelt samen met de eindverantwoordelijken voor de uitvoering de planning vast.

4.4.3.3.8. Het proces wijzigingsbeheer

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