Page Comparison

4.4.3.1. Beheer van wijzigingen als maatregel

...

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.

...

4.4.3.1.2. De verschillende activiteiten van wijzigingsbeheer

Beheer van wijzigingen omvat (zie paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEVICR3/pages/64234805167097287622/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.

...

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.

...

• 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:

...

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.

...

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:

...

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.

...

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.

...

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.

...

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.

...

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.

...