proces wijzigingsbeheer - informatiebeveiligingsdienst · de impact van de wijzigingen dient van...
TRANSCRIPT
Handreiking
Proces wijzigingsbeheer
Een operationeel kennisproduct ter ondersteuning van de implementatie van de Baseline Informatiebeveiliging Overheid (BIO)
2
Colofon Naam document
Handreiking proces wijzigingsbeheer
Versienummer
2.0
Versiedatum
Maart 2019
Versiebeheer
Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD).
Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten (IBD) (2018)
Tenzi j anders vermeld, i s dit werk verstrekt onder een Creative Commons Naamsvermelding-Niet Commercieel-Gelijk
Delen 4.0 Internationaal licentie. Dit houdt in dat het materiaal gebruikt en gedeeld mag worden onder de volgende
voorwaarden: Al le rechten voorbehouden. Verveelvoudiging, verspreiding en gebruik van deze uitgave voor het doel
zoals vermeld in deze uitgave is met bronvermelding toegestaan voor alle gemeenten en overheidsorganisaties.
Voor commerciële organisaties wordt hierbij toestemming verleend om dit document te bekijken, af te drukken, te
verspreiden en te gebruiken onder de hiernavolgende voorwaarden:
1. De IBD wordt als bron vermeld;
2. Het document en de inhoud mogen commercieel niet geëxploiteerd worden;
3. Publ icaties of informatie waarvan de intellectuele eigendomsrechten niet bij de verstrekker berusten, blijven
onderworpen aan de beperkingen opgelegd door de IBD en / of de Vereniging van Nederlandse Gemeenten;
4. Iedere kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van d e in deze paragraaf
vermelde mededeling.
Wanneer dit werk wordt gebruikt, hanteer dan de volgende methode van naamsvermelding: “Vereniging van
Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten”, licentie onder: CC BY-NC-SA 4.0.
Bezoek http://creativecommons.org/licenses/by-nc-sa/4.0 voor meer informatie over de licentie.
Rechten en vrijwaring
De IBD is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te verzorgen. Niettemin kan
de IBD geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave voorkomende onjuistheden, onvolledigheden
of na latigheden. De IBD aanvaardt ook geen aansprakelijkheid voor enig gebruik van voorliggende uitgave of schade
ontstaan door de inhoud van de uitgave of door de toepassing ervan.
Met dank aan
De expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit product.
3
Wijzigingshistorie;
Versie Datum Wijziging / Actie
1.0 Apri l 2014 Eerste versie
1.0.1 Augustus 2016 Taskforce BID verwijderd, WBP vervangen door Wbp, GBA vervangen
door BRP
2.0 Maart 2019 BIO update
Over de IBD De IBD is een gezamenlijk initiatief van a lle Nederlandse Gemeenten. De IBD is de sectorale CERT / CSIRT voor a lle
Nederlandse gemeenten en richt zich op (incident)ondersteuning op het gebied van informatiebeveiliging. De IBD is
voor gemeenten het schakelpunt met het Nationaal Cyber Security Centrum (NCSC). De IBD ondersteunt gemeenten bij
hun inspanningen op het gebied van informatiebeveiliging en privacy / gegevensbescherming en geeft regelmatig
kennisproducten uit. Daarnaast faciliteert de IBD kennisdeling tussen gemeenten onderling, met andere
overheidslagen, met vi tale sectoren en met leveranciers. Al le Nederlandse gemeenten kunnen gebruikmaken van de
producten en de generieke dienstverlening van de IBD.
De IBD is ondergebracht bij VNG Realisatie.
Leeswijzer Dit product i s een nadere uitwerking voor gemeenten van de Baseline Informatiebeveiliging Overheid (BIO). De BIO is
eind 2018 bestuurlijk vastgesteld als gezamenlijke norm voor informatiebeveiliging voor a lle Nederlandse overheden.
Doel Het doel van dit document is om handvatten te geven om het wijzigingsbeheer proces goed te laten functioneren.
Doelgroep Dit document is van belang voor systeemeigenaren, applicatiebeheerders en de ICT-afdeling.
Relatie met overige producten • Baseline Informatiebeveiliging Overheid (BIO)
• Informatiebeveiligingsbeleid van de gemeente
• Handreiking configuratiemanagement
• Handreiking patchmanagement voor gemeenten
• Voorbeeld Incident management en response beleid
• Handreiking bedrijfscontinuiteitsbeheer
• Handreiking samenhang beheerprocessen en informatiebeveiliging
Verwi jzingen naar de Baseline Informatiebeveiliging voor de Overheid (BIO)
12.1.2 Wi jzigingsbeheer
12.1.4 Scheiding van ontwikkel-, test- en productieomgeving
14.1.1 Analyse en specificatie van informatiebeveiligingseisen
14.2.3 Technische beoordeling van toepassingen na wijzigingen besturingsplatform
4
Wat is er veranderd ten opzichte van de BIG?
Veranderingen in de organisatie, bedrijfsprocessen, informatieverwerkende faciliteiten en systemen die van invloed zijn
op de informatiebeveiliging behoren te worden beheerst, in de BIG ging het alleen over IT voorzieningen &
informatiesystemen.
5
Managementsamenvatting
Wi jzigingsbeheer draagt er zorg voor dat wijzigingen op de ICT-infrastructuur (ICT-middelen en -diensten) efficiënt en effectief worden doorgevoerd met zo min mogelijk verstoring van de kwaliteit van de dienstverlening, zodat deze dienstverlening blijft voldoen aan de eisen die hieraan zijn gesteld. Andere processen, zoals bijv. incidentmanagement en
patchmanagement, volgen het wijzigingsbeheer proces om alles op een gestructureerde manier te laten verlopen. Indien (een gedeelte van de) IT is uitbesteed dienen er goede afspraken gemaakt te worden over de wi jzigingen. Het wi jzigingsbeheer proces bestaat uit de volgende s tappen:
Indienen: Behoort officieel niet tot de activiteiten van wijzigingsbeheer maar wordt wel door het proces
ondersteund. Wijzigingsbeheer is er verantwoordelijk voor dat wijzigingen naar behoren geregistreerd
worden.
Classificeren: Indelen naar categorie en prioriteit.
Accepteren: De wi jzigingsverzoeken (VTW, Verzoek tot Wijziging) filteren en accepteren voor verdere behandeling.
Plannen: Samenvoegen van wijzigingen, plannen van uitvoering en van benodigde resources.
Coördineren: Coördinatie van de bouw, test en implementatie van de wijziging.
Evalueren: Nagaan of de wijziging een succes was en lering trekken voor de volgende keer.
6
Inhoudsopgave
1. Inleiding .............................................................................................................................. 7 1.1. Doelstellingen wijzigingsbeheer ...............................................................................................7 1.2. De indeling van dit document is als volgt: .................................................................................7 1.3. Aanwijzing voor gebruik ..........................................................................................................8
2. Handreiking proces............................................................................................................. 9 2.1. Opzetten wijzigingsbeheer .................................................................................................... 10 2.2. Indienen............................................................................................................................... 11 2.3. Classificeren ......................................................................................................................... 11 2.4. Accepteren ........................................................................................................................... 12 2.5. Plannen ................................................................................................................................ 12 2.6. Coördineren ......................................................................................................................... 12 2.7. Evalueren ............................................................................................................................. 13
3. Afspraken vastleggen ....................................................................................................... 14
4. Prestatie-indicatoren ....................................................................................................... 15
Bijlage 1: Template verzoek tot wijziging ............................................................................... 16
Bijlage 2: Kwaliteitseisen......................................................................................................... 18
Bijlage 3: bepalen prioriteit en categorie ............................................................................... 26
Bijlage 4: Definities .................................................................................................................. 29
Bijlage 5: Literatuur/bronnen ................................................................................................. 32
7
1. Inleiding Wijzigingsbeheer draagt er zorg voor dat wijzigingen op de ICT-infrastructuur (ICT-middelen en -diensten) efficiënt en
effectief worden doorgevoerd met zo min mogelijk verstoring van de kwaliteit van de dienstverlening, zodat deze
dienstverlening blijft voldoen aan de eisen die hieraan zijn gesteld.
1.1. Doelstellingen wijzigingsbeheer
De volgende beheerdoelstellingen van wijzigingsbeheer dienen met een redelijke mate van zekerheid te worden
gewaarborgd:
• Wijzigingen dienen te worden geautoriseerd met inachtneming van de risico’s voor de ICT -diensten. De impact van de
wi jzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten, evenals
(eind)gebruikersaspecten te worden getoetst.
Indien wijzigingen niet zi jn geautoriseerd na evaluatie van de risico’s, bestaat het risico dat de wijzigingen ongewenste
(neven)effecten hebben op ICT-diensten, die soms niet volledig kunnen worden overzien door de initiator van de
wi jziging. Het is daarom van belang om deze effecten gestructureerd in kaart te brengen en de impact af te stemmen
met a l le belanghebbenden, zoals de eigenaar van de ICT-dienst, beheerders van ICT-middelen en de betrokkenen van
andere ICT-beheerprocessen.
• Wijzigingen dienen tijdig en volledig te worden doorgevoerd. Voor het implementeren van wijzigingen dienen
voldoende resources beschikbaar te zijn en de implementatie van de wijziging dient zodanig te worden gepland dat d e
verstoring van de dienstverlening minimaal is.
Indien wijzigingen niet ti jdig en volledig worden doorgevoerd, bestaat het risico dat noodzakelijke verbeteringen of de
instandhouding van de ICT-diensten in het gedrang komen. Het is van belang dat wijzigingsaanvragen ti jdig in
behandeling worden genomen en, evenals de resulterende wijzigingen, tijdig worden afgehandeld. Daarnaast is het
van belang dat, voorafgaand aan een wijziging, alle aspecten worden geïdentificeerd die eveneens een wijziging dienen
te ondergaan of worden beïnvloed als gevolg van de wijziging.
• Wijzigingen dienen te worden beoordeeld op doeltreffendheid.
Indien de doeltreffendheid van wijzigingen niet wordt geëvalueerd, bestaat het risico dat de wijzigingen niet, of s lechts
gedeeltelijk, bijdragen aan verbetering van de ICT-diensten of zelfs verstorend zijn voor de ICT-diensten. Indien
wi jzigingen niet het beoogde effect blijken te hebben, is het van belang om terug te kunnen keren naar de
oorspronkelijke situatie (ook wel: back-out of terugvalscenario).
1.2. De indeling van dit document is als volgt:
Hoofdstuk twee beschrijft welke stappen in het wijzigingsbeheer proces zitten. Tevens wordt het belang van
wi jzigingsbeheer op de informatiebeveiliging uitgelegd. Hoofdstuk drie beschrijft welke verschillende afspraken gemaakt
dienen te worden. En hoofdstuk vier gaat in op de prestatie-indicatoren.
8
1.3. Aanwijzing voor gebruik
Deze handleiding is geschreven om informatiebeveiligingsmaatregelen met betrekking tot wijzigingsbeheer uit te werken
en daarbij handreikingen te geven voor het proces rondom wi jzigingsbeheer en aanverwante procedures. Deze handleiding
i s geen volledige procesbeschrijving. Het proces wijzigingsbeheer wordt vaak uitgevoerd binnen de ICT-afdeling.
De gemeentelijke beleidsregels met betrekking tot wijzigingsbeheer (systeemplanning en –acceptatie) zi jn:1
• Nieuwe systemen, upgrades en nieuwe versies worden getest op impact en gevolgen, en pas geïmplementeerd na
formele acceptatie en goedkeuring door de opdrachtgever (veelal de proceseigenaar). De test en de testresultaten
worden gedocumenteerd.
• Systemen voor Ontwikkeling, Test en/of Acceptatie (OT(A)) zijn logisch gescheiden van Productie (P).
• Faci liteiten voor Ontwikkeling, Testen, Acceptatie en Productie (OT(A)P) zijn gescheiden om onbevoegde toegang tot,
of wi jzigingen in het productiesysteem te voorkomen.
1 Zie ook het algemene inf ormatiebev eiligingsbeleid
9
2. Handreiking proces Wijzigingsbeheer heeft als doel om alle wijzigingen op een gestructureerde manier te laten verlopen om de kans op
verstoren in het ICT landschap tot een minimum te beperken. De verschillende stappen in het proces worden in bijlage 2
verder toegelicht.
Wijzigingen
Een wi jziging is de toevoeging, verandering of verwijdering van a lles dat een effect kan hebben op ICT-diensten. De scope is
gericht op a lle wijzigingen van alle architecturen, processen, instrumenten, meetwaarden en documentatie, en op
wi jzigingen van ICT-diensten en andere configuratie-items. Wijzigingen kunnen voortkomen uit diverse behoeften, zoals
nieuwe functionele en technische eisen, vanwege bedrijfsoverwegingen of een (nood)wet, en oplossingen voor problemen.
Kwetsbaarheden die verholpen worden door een beveiligingsupdate (patch) zi jn een ander voorbeeld van een wijziging.
Belang van wijzigingsbeheer voor informatiebeveiliging
Het belang van wijzigingsbeheer voor informatiebeveiliging omvat:
• Het gecontroleerd doorvoeren van wijzigingen leidt ertoe dat de kans op het niet beschikbaar zi jn van de ICT-
dienstverlening a ls gevolg van wijzigingen afneemt, en dat eventuele toch opgetreden s toringen korter duren (door de
in het wijzigingsproces ingebouwde voorzieningen voor terugdraaien van wijzigingen).
Het biedt een mogelijkheid om af te dwingen dat wijzigingen eerst op beveiligingsconsequenties worden getoetst
voordat ze worden uitgevoerd. Dit vermindert de kans op het ontstaan van beveiligingsincidenten.
• Het draagt zorg dat uit beveiligingsoogpunt relevante instellingen van de ICT-infrastructuur niet ongecontroleerd en
ongeautoriseerd gewijzigd kunnen worden. De ICT-infrastructuur, die aan de beveiligingsnormen voldoet, blijft aan het
afgesproken niveau voldoen.
Activiteiten wijzigingsbeheerder
De wi jzigingsbeheerder voert onder andere onderstaande activiteiten uit:
• De wi jzigingsbeheerder checkt de volledigheid en juistheid van het wijzigingsvoorstel op basis van een door de
wi jzigingsbeheerder opgestelde checklist.
• De wi jzigingsbeheerder ziet erop toe dat de wijzigingsprocedures worden gehandhaafd, en bewaakt de voortgang van
de afhandeling van wijzigingen.
• De wi jzigingsbeheerder classificeert in overleg met de indiener het wi jzigingsvoorstel op basis van prioriteit en
categorie.
• De wi jzigingsbeheerder laat op een geaccepteerd wijzigingsvoorstel een impactanalyse uitvoeren, en s telt op basis van
de impactanalyse een rapportage op die het volgende bevat:
o Aannames
o Beperkingen
o Omvang
o Consequenties wijzigingsvoorstel
o Oplossingsalternatief en betrokken configuratie-items
o Uit te voeren activi teiten
o Begroting
o Ris icoanalyse
• De wi jzigingsbeheerder is voorzitter van de Wijzigingsadviescommissie (Change Advisory Board)2, waarin alle expertise
i s verzameld zodat de wijzigingsvoorstellen op a lle aspecten beoordeeld kunnen worden en waarvan de leden
samenkomen in het wijzigingsoverleg.
2 De Wijzigingsadv iescommissie is een groep mensen die de beoordeling, de prioriteitsstelling, de autorisatie en de planning v an wijzigingen
ondersteunt. Een Wijzigingsadv iescommissie bestaat v eelal uit v ertegenwoordigers v an alle af delingen binnen de ICT-dienstenaanbieder, het
bedrijf en derden (zoals toelev eranciers).
10
• De wi jzigingsbeheerder verstrekt aan de Wijzigingsadviescommissie de rapportage van de uitgevoerde impactanalyse
en de (op basis van de uitgevoerde impactanalyse) gewijzigde uitgifteplanning.
• De wi jzigingsbeheerder is voorzitter van het wijzigingsoverleg waarin de wijzigingsvoorstellen (al dan niet)
geautoriseerd worden. Impactanalyses worden door de Wijzigingsadviescommissie gebruikt bij het beoordelen van
wi jzigingsvoorstellen. De uitgifteplanning wordt door de Wijzigingsadviescommissie gebruikt om de haalbaarheid van
een wijzigingsvoorstel voor een bepaalde datum te kunnen beoordelen.
• Eventuele urgente wijzigingsvoorstellen worden (afhankelijk van de beschikbare ti jd) wel of niet beoordeeld met
behulp van een impactanalyse, wel of niet voorgelegd aan de Wijzigingsadviescommissie, maar worden altijd getest.
De wi jzigingsbeheerder zorgt er voor dat hij de procesgang rondom urgente wijzigingsvoorstellen bijhoudt en te a llen
ti jde kan verantwoorden aan de Wijzigingsadviescommissie en de ICT-manager3.
2.1. Opzetten wijzigingsbeheer
Beoordelen van kwaliteit wijzigingsbeer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om het huidige proces rondom wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Is het doel van wijzigingsbeheer eenduidig vastgelegd?
• Zi jn verantwoordelijkheid en bevoegdheden voor het indienen en afhandelen van wijzigingsverzoeken eenduidig in de
gemeente belegd.
• Is bepaald welke functies of processen direct te maken hebben met het proces?
• Is wi jzigingsbeheer gescheiden van ontwikkelings- en productietaken?
• Zi jn de verantwoordelijkheden en procedures met betrekking tot wijzigingsbeheer formeel vastgelegd, zodat er
voldoende controle i s op alle wijzigingen aan apparatuur, programmatuur en procedures?
• Is er voldoende capaciteit beschikbaar om wijzigingen ti jdig te kunnen behandelen?
• Is er sprake van een juiste functiescheiding binnen het proces wijzigingsbeheer?
• Zi jn procedurebeschrijvingen beschikbaar waarin de activiteiten van de verschillende betrokkenen zijn vastgelegd?
• Is bij de gerelateerde processen voldoende inzicht en kennis aanwezig met betrekking tot doel,
verantwoordelijkheden en werkwijze van het proces?
• Is bij de procedures met betrekking tot wijzigingen voldoende aandacht besteed aan:
o Autorisatie van het wijzigingsverzoek (inclsief onderbouwing van de wijziging).
o Het vaststellen en noteren van belangrijke wijzigingen.
o Het bepalen van de mogelijke gevolgen van dergelijke wijzigingen.
o Een goedkeuringsprocedure voor voorgestelde wijzigingen voor vertrouwelijkheid, integriteit en
beschikbaarheid.
o Een gedetailleerde mededeling van de wijzigingen aan a lle betrokken personen.
o Procedures en verantwoordelijkheden voor het terugdraaien en herstellen van niet geslaagde wijzigingen.
o Voortgangsbewaking.
o Het genereren van een audit trail.
o Detectie en interne controle van wijzigingen.
• Is een rapportagestructuur vastgelegd ten aanzien van het functioneren van het proces?
• Worden de rapportages gebruikt voor sturing van het proces?
• Worden de rapportages op regelmatige basis opgesteld? Aangevuld met ad hoc rapportages?
3 De ICT-manager is v erantwoordelijk v oor de gehele ICT-gerelateerde dienstv erlening.
11
Processtappen:
Indienen: Behoort officieel niet tot de activiteiten van wijzigingsbeheer maar wordt wel door het proces
ondersteund. Wijzigingsbeheer is er verantwoordelijk voor dat wijzigingen naar behoren geregistreerd
worden.
Accepteren: De wi jzigingsverzoeken (VTW, Verzoek tot Wijziging) filteren en accepteren door de
wi jzigingsadviescommissie voor verdere behandeling.
Classificeren: Indelen naar categorie en prioriteit.
Plannen: Samenvoegen van wijzigingen, plannen van uitvoering en van benodigde resources.
Coördineren: Coördinatie van de bouw, test en implementatie van de wijziging.
Evalueren: Nagaan of de wijziging een succes was en lering trekken voor de volgende keer.
2.2. Indienen
Door wi jzigingsbeheer worden alleen geautoriseerde en geaccepteerde wijzigingsverzoeken in behandeling genomen en
om dit te realiseren dient door de gemeente vastgelegd te zi jn welke gemeenteambtenaren welk type wijzigingsverzoek
mogen indienen.
Al le wijzigingsverzoeken moeten worden geregistreerd. Er zi jn door wijzigingsbeheer eisen gesteld aan de wijze waarop een
wi jzigingsverzoek wordt ingediend en welke informatie daarbij minimaal moet worden verstrekt. Alle wijzigingen worden
bi j voorkeur geregistreerd in een wijzigingsbeheersysteem.
Indeling van de wijzigingen
Hieronder een voorbeeld indeling van wi jzigingen:
• Standaardwijzigingen: Di t zi jn routinematige beheertaken, die procedurematig (gestandaardiseerd) worden
ui tgevoerd. Dit type wijziging is door wijzigingsbeheer of de Wijzigingsadviescommissie eenmalig geautoriseerd en
hoeft niet elke keer opnieuw te worden beoordeeld. Dit type wijziging wordt als beheertaken routinematig uitgevoerd.
• Spoedwijzigingen: Di t type wi jziging is een oplossing voor incidenten bij primaire bedrijfsprocessen van de gemeente,
of het betreft een spoed aanpassing aan de ICT-infrastructuur (bijvoorbeeld een noodwet of een beveiligingsupdate).
Spoedwijzigingen wijken af van de normale procedures, omdat voor dit soort wijzigingen de benodigde middelen
meteen moeten worden vri jgemaakt. Ook kan een spoedvergadering van de Wijzigingsadviescommissie vereist zi jn.
• (Overige) wijzigingen: Di t betreft alle overige wijzigingsverzoeken om aanpassingen aan de beheerde ICT-
infrastructuur aan te brengen. Voor deze wijzigingen gelden de s tandaardwijzigingsprocedures, zoals in dit document
beschreven.
2.3. Classificeren Voor (voorgestelde) wijzigingen geldt dat deze systematisch worden geclassificeerd op impact en dat deze worden geautoriseerd met inachtneming van de impactanalyse. Als het wijzigingsverzoek is geaccepteerd, wordt de prioriteit en de
categorie daarvan aangegeven. Voor standaardwijzigingen4, die een verkorte procedure mogen doorlopen, geldt dat deze vooraf worden geclassificeerd, geautoriseerd en gedocumenteerd.
Urgentie
Een maatstaf die aangeeft hoe lang het duurt tot een incident, probleem of wijziging een significante impact op de
bedri jfsvoering van de gemeente heeft. Zo kan een incident met een hoge impact een lage urgentie hebben, als de impact de bedrijfsvoering pas schaadt aan het eind van het financiële jaar. Impact en urgentie worden gebruikt om een prioriteit toe te kennen.
Impact
De mate waarin een incident, probleem of wi jziging effect heeft op bedrijfsprocessen van de gemeente. Impact is vaak gebaseerd op het effect op dienstenniveaus. Impact en urgentie worden gebruikt om prioriteit aan te geven.
4 Een standaardwijziging is een v ooraf geautoriseerde wijziging met een laag risico, die relatief v eel v oorkomt en een procedure of werkinstructie
v olgt, zoals het resetten v an een wachtwoord of een nieuwe medewerker v oorzien v an standaardapparatuur. Deze s tandaardwijzigingen dienen
wel geregistreerd te worden in het wijzigingsbeheersy steem.
12
Om de impact van de wijziging te kunnen vaststellen dient gebruik gemaakt te worden van een gestandaardiseerde
procedure. De volgende onderdelen dienen hierbij behandeld te worden:
• Impact op de financiële situatie van de gemeente. Denk hierbij aan zowel de kosten a ls de baten.
• Impact op de gebruikersorganisatie van de gemeente.
• Inspanning die de gebruikersorganisatie van de gemeente moet leveren.
• Impact op het gemeentepersoneel.
• Impact op het materieel.
• Impact op de ICT-infrastructuur.
• Impact op het beheer.
• Inspanning die de ICT-organisatie moet leveren.
• Impact op het beveiligingsniveau van de gemeente.
• Impact op de bescherming van persoonsgegevens. Denk hierbij aan zowel de persoonsgegevens van
gemeenteambtenaren als burgers.
2.4. Accepteren Na de registratie voert wijzigingsbeheer een globale controle uit om vast te stellen of een wijzigingsverzoek onlogisch, onwerkbaar of onnodig is. Dergelijke aanvragen worden afgewezen met opgaaf van reden. De aanvrager dient de gelegenheid geboden te worden om de aanvraag te verdedigen als deze is a fgewezen en/of het wijzigingsverzoek opnieuw
in te dienen.
2.5. Plannen
De planning van de wijziging wordt door wijzigingsbeheer opgezet in een wijzigingskalender of wijzigingsplan. Het
wi jzigingsplan bevat details van alle goedgekeurde wijzigingen en hun planning. Leden van de Wijzigingsadviescommissie
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 gebruikersorganisatie van de gemeente. Wijzigingsbeheer heeft een
gedelegeerde autoriteit en handelt namens het ICT-management. Het kan voor wijzigingen met een grote impact
noodzakelijk zijn instemming te verkrijgen van het ICT-management voorafgaand aan de behandeling in de
Wi jzigingsadviescommissie. Het goedkeuren van de wijziging kan worden ondersteund door drie basisprocessen:
• Financiële goedkeuring: kosten-batenanalyse en budgettering.
• Technische goedkeuring: impact, noodzakelijkheid en haalbaarheid.
• Zakelijke goedkeuring: goedkeuring van de gebruikers betreffende functionaliteitbehoefte en impact.
2.6. Coördineren
Goedgekeurde wijzigingen worden doorgegeven aan de betrokken productspecialisten voor de bouw en samenstelling van
de wi jzigingen. Voordat wijzigingen kunnen worden doorgevoerd, moeten de wijzigingen eerst worden getest. Bij het
bouwen, testen en implementeren kan uitgiftebeheer een belangrijke coördinerende rol spelen. Ter ondersteuning van
wi jzigingen dient afdoende aandacht te worden besteed aan communicatie.
Bouwen
Niet a lle wi jzigingen hebben een expliciete bouwfase. Zo worden gestandaardiseerde wijzigingen (bijvoorbeeld het resetten
van een wachtwoord) direct ingepland en uitgevoerd. Deze standaardwijzigingen dienen wel geregistreerd te worden in het
wi jzigingsbeheersysteem. Deze registratie i s nodig om de voortgang te kunnen bewaken en hierover te rapporteren.
Het bouwen kan inhouden dat er een nieuwe softwareversie komt, met nieuwe documentatie, handleidingen,
installatieprocedures, inclusief een back-out-plan en aanpassingen op de hardware. De Changemanager vervult hierbij een
coördinerende rol.
Als onderdeel van de oplevering van een wijziging moet ook een rollback procedure (terugvalscenario) worden geschreven,
om de s ituatie terug te kunnen draaien als de wijziging niet het gewenste resultaat oplevert. Hierin dient te worden
beschreven onder welke condities tot een terugval wordt overgegaan en wie daartoe kan besluiten. Wijzigingsbeheer mag
13
de wi jziging niet goedkeuren als er geen back-out-procedure i s. Als de wijziging impact heeft op de gebruikersomgeving,
dan zal er ook een communicatieplan moeten worden geschreven. Verder wordt in de bouwfase een implementatieplan
opgesteld en bekende fouten van te implementeren wijzigingen worden geregistreerd.
Testen
Zowel de wijziging als de back-out-procedure en de invoermethode van de wijziging dienen grondig te worden getest.
Afwi jkingen van dit principe worden vooraf formeel goedgekeurd, eventueel achteraf in het geval van spoedeisende
wi jzigingen. Daarbij moet worden gelet op de criteria van doeltreffendheid en autorisatie die eerder al door de
Wi jzigingsadviescommissie zijn bepaald. Voor elke wijzigingscategorie zijn regels opgesteld voor de omvang en diepgang
van de tests. De toetsing op doeltreffendheid van wijzigingen is functioneel gescheiden van de uitvoering van wijzigingen.
De toetsingsresultaten worden geaccordeerd door belanghebbenden.
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.
Er dient voor de testwerkzaamheden een aparte testomgeving te zijn. Testen worden uitgevoerd door de bouwers,
degenen die het wijzigingsverzoek hebben ingediend of vertegenwoordigers daarvan (gebruikersorganisatie va n de
gemeente) en ICT-beheer. Er dient een scheiding te zijn tussen de omgeving waar gebouwd is en de omgeving waar getest
wordt. De test moet worden uitgevoerd door een partij die onafhankelijk is van de bouw.
Acceptatietests 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 zi jn duidelijke voorschriften nodig voor het toezicht houden op de kwaliteit van het testen en van de documentatie van
de testresultaten.
Implementeren
Iedereen die vanuit de betrokken afdeling het beheer van de ICT-infrastructuur onder zijn verantwoording heeft, kan
worden belast met het implementeren van een wijziging op de infrastructuur.
Wi jzigingsbeheer ziet erop toe dat de wijziging op schema l igt. Er moet een duidelijk communicatieplan liggen waarin s taat
wie van de wijziging op de hoogte gebracht moeten worden gesteld. Bijvoorbeeld: gebruikers, netwerk-, systeembeheer, et
cetera.
2.7. Evalueren
Doorgevoerde wijzigingen, met uitzondering van de standaardwijzigingen, worden na een bepaalde ti jd geëvalueerd ,
waarbij in elk geval vastgesteld wordt of de wijziging niet tot incidenten heeft geleid en of de juiste classificatie i s
toegepast. Daarna wordt desgewenst in de Wi jzigingsadviescommissievergadering bezien of nog verdere nazorg nodig is.
Daarbij wordt gelet op de volgende zaken:
• Heeft de wijziging het beoogde doel bereikt?
• Zi jn de gebruikers tevreden met het resultaat?
• Zi jn er nevenverschijnselen opgetreden?
• Zi jn de geraamde kosten en inspanningen niet overschreden?
Is de wijziging een succes en zijn a lle activiteiten en registraties voor de wijziging gecontroleerd op afronding, dan kan het
wi jzigingsverzoek worden afgesloten. Is de wijziging geen succes, dan wordt de procesgang hervat op de plaats waar het
misgegaan is, met een aangepaste werkwijze.
14
3. Afspraken vastleggen
In de dienstenniveauovereenkomst(en) (DNO) of Service Level Agreements (SLA) zijn afspraken vastgelegd over:
• Het indienen van wijzigingsverzoeken door de gemeente, de verschillende categorieën wijzigingen die daarbij worden
onderkend, evenals criteria voor indeling van deze categorieën en per onderkende wijzigingscategorie de tijd die geldt
voor het doorvoeren van de betreffende wijziging.
• De wi jze waarop (belangrijke) wijzigingen binnen de ICT-organisatie impact kunnen hebben voor de
gebruikersorganisatie van de gemeente, of waarbij inbreng van de gebruikersorganisatie van de gemeente nodig is,
dienen met de gebruikersorganisatie van de gemeente worden afgestemd.
• De wi jze waarop over wijzigingen wordt gerapporteerd.
Afspraken met leveranciers
• In het contract met leveranciers wordt vastgelegd dat de leverancier een wijzigingsbeheerproces uitvoert dat aan de
hiervoor genoemde normen voldoet.
• Het wi jzigingsbeheerproces bij de leverancier en bij de exploitatieorganisatie van de gemeente worden op elkaar
afgestemd, dit geldt in het bijzonder voor de wederzijdse wijzigingskalenders.
• In het contract met leveranciers wordt vastgelegd welke categorieën wijzigingen de leverancier autonoom binnen zijn
eigen wijzigingsbeheerproces mag doorvoeren, en over welke wijzigingen afstemming met het wijzigingsbeheerproces
van de gemeente plaatsvindt.
• In het contract met leveranciers wordt vastgelegd welke eisen door de gemeente worden gesteld aan de
informatievoorziening over de wijzigingen bij de leverancier.
15
4. Prestatie-indicatoren
Prestatie-indicatoren dienen aan te geven in welke mate het proces wijzigingsbeheer s laagt in haar doelstelling: het
efficiënt en effectief doorvoeren van wijzigingen met zo min mogelijk verstoring van de kwaliteit van de dienstverlening,
zodat deze dienstverlening blijft voldoen aan de eisen die hieraan zijn gesteld. Prestatie-indicatoren die door de
dienstenorganisatie kunnen worden gemeten, zijn onder andere:
• Het aantal wijzigingen dat per ti jdseenheid wordt doorgevoerd, verdeeld over de verschillende categorieën.
• Het aantal of het percentage afgewezen wijzigingen, verdeeld over de verschillende categorieën.
• Het aantal of het percentage van wijzigingen dat per periode wordt gesignaleerd zonder registratie en autorisatie.
• Het aantal of het percentage (beveiligings)incidenten per impactcategorie dat uit wijzigingen voortkomt.
• Het aantal of het percentage verstoringen dat uit wijzigingen voorkomt.
• Het aantal of het percentage back-outs dat in wijzigingen aan de orde was.
• Het aantal of het percentage wijzigingen dat binnen de geplande doorlooptijd, resources en het budget i s uitgevoerd.
• Het gerealiseerde budget of het aantal bestede uren aan wijzigingen per periode.
• Kosten van uitgevoerde wijzigingen.
16
Bijlage 1: Template verzoek tot wijziging In deze bijlage wordt een template verzoek tot wijziging weergegeven, die gemeenten kunnen gebruiken om hun eigen
wi jzigingsformulier te ontwerpen.5 Bij het invullen van het wijzigingsformulier kan ondersteuning noodzakelijk zi jn van de
CISO6) applicatie-, functioneel- en technisch beheer, gebruikersorganisatie van de gemeente et cetera.
Verzoek tot Wi jziging (VTW) Vers ie 1.0, de dato 14-02-2014 Document voor het indienen van wijzigingsverzoeken.
Ingediend door: Vermeld hier de voor- en achternaam van de indiener van het wijzigingsverzoek.
Team/afdeling: Vermeld hier het team/afdeling van de indiener van het wijzigingsverzoek.
E-mail: Vermeld hier het e-mailadres van de indiener van het wijzigingsverzoek.
Telefoonnummer: Vermeld hier het telefoonnummer van de indiener van het wijzigingsverzoek.
Datum: Vermeld hier de datum waarop het wijzigingsverzoek is opgesteld.
Referentie: Vermeld hier, indien van toepassing, de referentie in dat door uw afdeling aan dit wijzigingsverzoek is toegekend.
Onderwerp: Geef kort en bondig de context in waar het verzoek om draait en geef hierbij aan waarop het wijzigingsverzoek betrekking heeft. Denk hierbij aan bedrijfsproces(sen), informatiesyste(e)m(en), locatie(s), proble(e)m(en).
Gewenste wijziging: Geef een korte inhoudelijke omschrijving van de gewenste functionaliteit (resultaat),
eventuele alternatieven en het beoogde resultaat (de oplossing). Geef hier ook een overzicht van de configuratie-items die betrokken zijn bij deze voorgestelde wijziging.
Aanleiding (motivatie): Geef een omschrijving van de aanleiding voor het indienen van het wijzigingsverzoek. Denk aan verandering in de omgeving, bedrijfsvoering of een incident/probleem. Eventueel de
referentie naar het incident/probleem (mits deze ICT-beheerprocessen zijn geïmplementeerd). Doelstelling: Geef een omschrijving van de doelstelling die gerealiseerd moet worden met het
wijzigingsverzoek.
Impact financieel: Geef een omschrijving, indien mogelijk, van de verwachte financiële consequenties bij de wijziging. Denk aan de verwachte baten, is er al budget (en hoeveel) gereserveerd.
Impact gebruikersorganisatie: Geef een omschrijving, indien mogelijk, van de verwachte organisatorische consequenties en bedrijfsvoering van de gemeente bij de wijziging.
De impact op de gebruikersorganisatie wordt bepaald door antwoorden op onderstaande vragen: • Voor hoeveel diensten en producten heeft de wijziging gevolgen?
• Hoeveel mensen maken gebruik van deze diensten? • Hoe bedrijfskritisch zijn deze diensten en/of producten?
Inspanning gebruikersorganisatie: Geef het aantal uur, indien mogelijk, wat de gebruikersorganisatie van de gemeente aan inspanning moet besteden met betrekking tot de wijziging. Denk aan testactiviteiten. Geef hierbij een onderbouwing/ toelichting.
Impact personeel: Geef een omschrijving, indien mogelijk, van de verwachte personele consequenties bij de wijziging. Denk aan opleiding, herplaatsing en ontslagen.
Impact materieel: Geef een omschrijving, indien mogelijk, van de verwachte materiële consequenties bij de wijziging. Denk aan het afvoeren van materieel.
Impact infrastructuur: Geef een omschrijving, indien mogelijk, van de verwachte consequenties voor ICT-middelen in de huidige infrastructuur. De impact op de infrastructuur wordt bepaald door antwoorden op onderstaande vragen:
• Welke configuratie-items zijn afhankelijk van, of gerelateerd aan het configuratie-item dat gewijzigd gaat worden?
• Wat is de invloed en wat moet er aan het gerelateerde configuratie-item aangepast
worden?
• Welke andere configuratie-items komen voor dezelfde wijziging in aanmerking?
5 Hierbij zijn de BiSL Best Practices v oorbeeld wijzigingsf ormulieren als uitgangspunt gebruikt (http://www.aslbislf oundation.org/nl/bisl/best-
practices)
6 Chief Inf ormation Security Officer
17
Impact beheer: Geef een schatting, indien mogelijk, hoeveel uur aan regulier beheer per week erbij zou komen door de wijziging. Geef hierbij een onderbouwing/ toelichting.
Inspanning ICT: Geef het aantal uur, indien mogelijk, wat de ICT-afdeling aan inspanning moet besteden met
betrekking tot de wijziging. Geef hierbij een onderbouwing/ toelichting.
Impact beveiligingsniveau: Geef aan, indien mogelijk, of er speciale beveiligingseisen moeten worden genomen. Vooral
als de eisen afwijken van de BIG. De impact op het beveiligingsniveau kan onder andere worden vastgesteld door antwoorden op onderstaande vragen:
• Veroorzaakt de wijziging veranderingen in de bestaande beveiligingsmaatregelen (bevoegdhedenregeling, controles in de applicatie et cetera)?
• Moeten voor de wijziging nieuwe en/of specifieke beveiligingsmaatregelen, bovenop de
BIO, worden geïmplementeerd? • Veroorzaakt de wijziging veranderingen in de bestaande continuïteitsmaatregelen
(back-up, redundantie, uitwijk)? • Moeten voor de wijziging nieuwe en/of specifieke continuïteitsmaatregelen worden
geïmplementeerd?
Impact bescherming
persoonsgegevens:
Geef aan, indien mogelijk, of er speciale beveiligingseisen moeten worden genomen om persoonsgegevens te beschermen. Vooral als de eisen afwijken van de BIG. De impact op het beschermingsniveau van persoonsgegevens kan onder andere worden vastgesteld door antwoorden op onderstaande vragen: • Worden in het systeem persoonsgegevens vastgelegd? Zo ja, welke?
• Worden persoonsgegevens uit andere systemen gebruikt of verwerkt? Zo ja, welke?
• Indien een van bovenstaande vragen met ja beantwoord is, is het systeem gemeld bij de
Functionaris Gegevensbescherming (FG) Afhankelijkheden: Geef een omschrijving van de relaties of afhankelijkheden met andere (deel)processen. Denk
hierbij ook aan relaties met andere wijzigingsverzoeken.
Consequenties van het niet doorvoeren van de wijziging:
Geef een omschrijving van het niet, of niet tijdig, doorvoeren van de wijziging.
Gewenste datum gereed: Geef de datum waarop de wijziging gereed dient te zijn.
Prioriteit voorstel7: Doe een voorstel voor de prioriteit van het wi jzigingsverzoek.
Normaal (0) O Verzoek i s gewenst.
Hoog (1) O Verzoek mag niet worden uitgesteld, de bedrijfsvoering komt in
gevaar.
Hoogste (2) O Operationeel belang.
Motivatie prioriteit: Geef een motivatie van de prioriteit. Bij prioriteit hoog en hoogst is dit verplicht.
Gewenste realisatiedatum: Vermeld hier de gewenste realisatiedatum.
Motivatie realisatiedatum: Geef een motivatie van de gewenste realisatiedatum.
Bijlage(n): Geef aan welke bijlagen zijn meegestuurd.
Geautoriseerd door: Vermeld hier de voor- en achternaam van degene die het wijzigingsverzoek heeft
geautoriseerd. Datum: Vermeld hier de datum waarop het wijzigingsverzoek is geautoriseerd.
Handtekening Plaats hier de handtekening van degene die het wijzigingsverzoek heeft geautoriseerd.
Tabel 1: Template verzoek tot wijziging
7 Aankruisen wat v an toepassing is.
18
Bijlage 2: Kwaliteitseisen
Registratie wijzigingen
Eisen die aan dit wijzigingsbeheersysteem dienen te worden gesteld zijn bijvoorbeeld:
• Unieke identificatie van wijzigingen (wijzigingsnummer).
• Mogel ijkheden om de verschillende stappen in het wijzigingsproces vast te leggen.
• Mogel ijkheden om te registreren welke configuratie-items (CI’s) bij de wijziging betrokken zijn (bevat relatie met de
configuratiebeheerdatabase (CBDB)).
• De mogelijkheid om te registreren voor welke problemen en bekende fouten de wijziging een oplossing biedt (bevat
relatie met de probleemregistratie).
• Voorzieningen voor de rapportage over de s tatus van wijzigingen en het verloop van het wijzigingsbeheerproces
(aantallen wijzigingen wachtend op goedkeuring, aantal teruggedraaide wijzigingen et cetera).
Waar komen wijzigingsverzoeken vandaan?
Wijzigingsverzoeken kunnen worden ingediend door of een gevolg zijn van bijvoorbeeld:
• Probleembeheer - Het indienen van een wijzigingsverzoek bij wijzigingsbeheer ten behoeve van de oplossing van een
bekende/structurele fout met als doel de dienstverlening te stabiliseren.
• Gebruikersorganisatie van de gemeente - Deze vragen om meer, of andere functionaliteiten van de diensten. Deze
verzoeken worden vaak ingediend door functioneel beheer of via d ienstenniveaubeheer.
• Leveranciers - Leveranciers komen met nieuwe releases en upgrades van hun producten en moeten daarbij aangeven
welke structurele fouten daarin zijn weggenomen en welke nieuwe functionaliteiten zi jn geïmplementeerd. Ook
kunnen zij aangeven dat bepaalde versies niet langer worden ondersteund, of dat voor een versie geen garanties
kunnen worden afgeven.
• Projecten - Een project kan meerdere wijzigingen tot gevolg hebben.
• Wetgeving - Als aan de dienstverlening nieuwe of veranderde wettelijke eisen worden gesteld, of als er nieuwe eisen
voor de ICT komen ten aanzien van beveiliging, bedrijfscontinuïteit en licentiebeheer.
Welke informatie moet worden verstrekt?
Hieronder een voorbeeld van informatie die minimaal bij een wijzigingsverzoek moet worden aangeleverd:
• Informatie met betrekking tot de indiener van het wijzigingsverzoek.
• Informatie met betrekking tot de degene die het wi jzigingsverzoek heeft geautoriseerd.
• Datum waarop het wijzigingsverzoek is ingediend.
• Een omschrijving van de voorgestelde wijziging.
o Indien van toepassing de referentie naar het achterliggende incident/pro bleem.
o De configuratie-items die betrokken zijn bij deze voorgestelde wijziging.
o Relaties of afhankelijkheden met andere (deel)processen.
• Een omschrijving wat de motivatie/aanleiding/reden van de voorgestelde wijziging is.
• De doelstelling van de voorgestelde wijziging.
• De consequenties van de voorgestelde wijziging, inclusief de consequenties als de voorgestelde wijziging niet wordt
doorgevoerd.
• Een voorstel van de prioriteit, inclusief motivatie, van de voorgestelde wijziging.
• De gewenste realisatiedatum, inclusief een motivatie.
• Het aantal gebruikers dat gebruik maakt van het proces / de dienst / de functie die gerelateerd is aan de voorgestelde
wi jziging.
• De impact op de bedrijfsprocessen van de gemeente.
• De impact van de voorgestelde wijziging op het beveiligingsniveau. Dit kan onder andere worden vastgesteld door het
beantwoorden van onderstaande vragen:
19
o Veroorzaakt de wijziging veranderingen in de bestaande beveiligingsmaatregelen (autorisaties, controles in
de applicatie et cetera)?
o Moeten voor de wijziging nieuwe en/of specifieke beveiligingsmaatregelen, bovenop de BIG, worden
geïmplementeerd?
o Veroorzaakt de wijziging veranderingen in de bestaande continuïteitsmaatregelen (back -up, redundantie,
ui twijk)? Zo ja, moeten nieuwe en/of specifieke continuïteitsmaatregelen worden geïmplementeerd?
Om dit vast te kunnen stellen moet er mogelijk ook een baselinetoets/verkorte risicoanalyse op de BIG uitgevoerd
worden.8 Wat zijn de beveiligingseisen, vooral als deze afwijken van de BIG.
• De impact van de voorgestelde wijziging op het beschermingsniveau van persoonsgegevens. Dit kan onder andere
worden vastgesteld door het beantwoorden van onderstaande vragen:
o Worden in het systeem persoonsgegevens vastgelegd? Zo ja, welke?
o Worden persoonsgegevens uit andere systemen gebruikt of verwerkt? Zo ja , welke?
o Indien een van bovenstaande vragen met ja beantwoord is, is het systeem gemeld bij de Functionaris
Gegevensbescherming (FG)
o Ook heeft de IBD documentatie rond PIA’s op de website.
• De impact van de voorgestelde wijziging op de infrastructuur.
• De impact van de voorgestelde wijziging.
• De urgentie van de voorgestelde wijziging.
• De prioriteit, gebaseerd op impact en urgentie, van de voorgestelde wijziging.
In bi jlage 1 wordt een voorbeeld van een wi jzigingsformulier weergegeven.
Indien bovenstaande gegevens niet voorhanden zijn wordt het wijzigingsverzoek geweigerd. Bij een geaccepteerde wi jziging wordt het wijzigingsnummer (referentie) doorgegeven aan de indiener.
De medewerker die de wijziging registreert noteert ook de oplosgroep (het expertiseteam) dat de wijziging zal behandelen. De wi jzigingsbeheerder is eindverantwoordelijk voor de juiste toewijzing.
8 Zie hierv oor ook het operationele product ‘Basis risicoanaly semethode gemeenten’
20
Hieronder wordt een overzicht gegeve n van de activiteiten die binnen registreren kunnen worden onderkend. Hierbij wordt
tevens aangegeven wie verantwoordelijk is voor de uitvoering en wie een coördinerende taak heeft.
Activiteit Uitvoering (U) / Coördinatie (C)
Indienen van wijzigingsverzoek Voordat een wijzigingsverzoek kan worden ingediend en geregistreerd dienen de volgende activiteiten uitgevoerd te zijn:
• Vaststellen welke gemeenteambtenaren welk type wijzigingsverzoek mogen
indienen.
• Vaststellen welke informatie minimaal moet worden ingevuld op het
wi jzigingsformulier.
• Cri teria vaststellen met betrekking tot impact, urgentie en prioriteit.
• Invul len van wijzigingsformulier.
Wi jzigingsbeheer (U) Wi jzigingsbeheer (U)
Indiener (U) / Wi jzigingsbeheer (U) Indiener (U) / Wi jzigingsbeheer (C)
Tabel 2: Activiteiten indienen wijzigingsverzoek
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activi teit binnen wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Is er een eenduidige definitie vastgesteld van het begrip ‘wijziging’? Dekt deze definitie alle wijzigingen ten aanzien
van de s tatus van een configuratie-item, zoals vastgelegd bij configuratiebeheer?9
• Bestaat er een formele procedure voor het indienen van wijzigingsverzoeken?
• Is bepaald wie een wijzigingsverzoek kan indienen en langs welke weg?
• Is een template wijzigingsformulier beschikbaar met toelichting?
• Is bepaald welke informatie minimaal dient te worden verstrekt bij het indienen van een wijzigingsverzoek?
• Zi jn cri teria met betrekking tot impact, urgentie en prioriteit vastgesteld?
De impact met betrekking tot het beveiligingsniveau en de bescherming van de persoonsgegevens worden hieronder
verder toegelicht.
Impact beveiligingsniveau
De impact op het beveiligingsniveau kan onder andere worden vastgesteld door antwoorden op onderstaande vragen:
• Veroorzaakt de wijziging veranderingen in de bestaande beveiligingsmaatregelen (bevoegdhedenregeling, controles in
de applicatie et cetera)?
• Moeten voor de wijziging nieuwe en/of specifieke beveiligingsmaatregelen, bovenop de BIG, worden
geïmplementeerd?
• Veroorzaakt de wijziging veranderingen in de bestaande continuïteitsmaatregelen (back -up, redundantie, uitwijk)?
• Moeten voor de wijziging nieuwe en/of specifieke continuïteitsmaatregelen worden geïmplementeerd?
Impact bescherming persoonsgegevens
De impact op het beschermingsniveau van persoonsgegevens kan onder andere worden vastgesteld door antwoorden op onderstaande vragen:
• Worden in het systeem persoonsgegevens vastgelegd? Zo ja, welke?
• Worden persoonsgegevens uit andere systemen gebruikt of verwerkt? Zo ja , welke?
• Indien een van bovenstaande vragen met ja beantwoord is, is het systeem gemeld bij de Functionaris
Gegevensbescherming (FG)
9 Zie hierv oor ook het operationele produc t ‘Handreiking proces conf iguratiebeheer’.
21
Prioriteit
De prioriteit wordt gebruikt om het relatieve belang te bepalen van een wi jziging. Prioriteit is een afgeleide van urgentie en
impact, en wordt gebruikt om te bepalen hoeveel tijd nodig is voor de acties die moeten worden ondernomen.
Bi jvoorbeeld: de Dienstenniveau overeenkomst (DNO) kan aangeven dat incidenten met prioriteit 2, binnen 12 uur moeten
zi jn opgelost. Van elke wijziging wordt de prioriteit bepaald en voor het indelen in prioriteitsklassen zijn cri teria vastges teld.
Categorie
De categorie geeft aan hoe de aanvraag verder zal worden afgehandeld en wordt bepaald op basis van de impact en belasting van de resources van de ICT-organisatie.
Naast de hiervoor genoemde classificatie kan ook worden aangegeven welke expertiseteams (bijvoorbeeld systeembeheer, netwerkbeheer en telecommunicatie) en welke diensten in de wijziging betrokken zijn.
Activiteit Uitvoering (U) / Coördinatie (C)
Toekennen van urgentie
De urgentie wordt, in overleg met de indiener, toegekend.
Wi jzigingsbeheer (U) Toekennen van impact De impact wordt toegekend. De impact wordt op verschillende disciplines door verschillende gemeentefunctionarissen vastgesteld.
Appl icatiebeheer (U), Functioneel beheer (U), Beveiligingsfunctionaris (U) / Wi jzigingsbeheer (C)
Toekennen van prioriteit De prioriteit geeft het belang aan en is een afgeleide van urgentie en impact.
Wi jzigingsbeheer (U)
Toekennen van categorie De categorie wordt, eventueel in overleg met de Wi jzigingsadviescommissie,
toegekend. Categorieën worden toegekend door wijzigingsbeheer, zo nodig in overleg met de
Wi jzigingsadviescommissie, die een indicatie geeft van de impact van de wijziging en de belasting op de ICT-organisatie.
Wi jzigingsbeheer (U)
Tabel 3: Activiteiten prioriteren van wijzigingen
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activi teit binnen wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Worden alle wijzigingsaanvragen geclassificeerd ten aanzien van de volgende aspecten:
o Priori teit (spoed van de wijziging)
o Complexiteit (impact op de organisatie)
o Doorlooptijd
o Soort ICT-middel (hardware, besturingsprogrammatuur, applicaties, procedures)
• Zi jn er objectieve cri teria vastgelegd op basis waarvan bepaald kan worden in welke categorie een wijziging
thuishoort? Ziet de wijzigingsbeheerder erop toe dat deze criteria juist worden toegepast?
• Zi jn er categorieën voor wijzigingen met grote (spoedeisende of urgente wijziging), substantiële (major wijziging) en
geringe gevolgen (standaardwijziging) beschikbaar?
• Zi jn aan de verschillende categorieën specifieke afhandelingsprocedures gekoppeld? Bijvoorbeeld s tandaard
procedure, een hoge prioriteit procedure en een nood procedure (zie ook bijlage 2).
• Is in deze afhandelingsprocedures vastgelegd dat alle wijzigingen geautoriseerd dienen te worden door de
budgethouder, applicatie, functioneel en technisch beheerder?
• Zi jn voor routinematige wijzigingen standaardprocedures en checklists beschikbaar?
• Is voor een spoedeisende/urgente wijziging een aparte procedure beschikbaar, waarbij eventueel het wi jzigingsproces
achteraf alsnog wordt doorlopen?
22
Voorgestelde wijzigingen worden geprioriteerd en gepland in overleg met alle belanghebbenden. Er dient hierbij veel
aandacht te worden besteed aan informatieverstrekking over deze planning van wijzigingen. Bi jvoorbeeld: in de vorm van
een wijzigingsplan of de wijzigingskalender.
Wijzigingsbeleid formuleren
Wijzigingsverzoeken kunnen worden gebundeld in een enkele ‘uitgifte’, zodat ook een enkele back -out kan worden
uitgevoerd (voor ‘terugrol’) a ls het misgaat. Een dergelijke gebundelde uitgifte moet worden gezien a ls een e nkele
wi jziging, zelfs als deze uit meerdere aparte wijzigingen is opgebouwd. Uitgiftes kunnen met een functioneel doel voor de
bus iness gepland worden. Hiervoor dient beleid geformuleerd te worden en dat dient gecommuniceerd te worden met de
ICT-organisatie en met de gemeenten. Dit beleid moet voorkomen dat bij de gebruiker voortdurend ‘de s traat wordt
opengebroken’.
Er i s vastgelegd wie de prioriteit van wijzigingen bepaalt en wie toestemming verleent voor realisatie en implementatie. Dit
bes lissingsforum (de Wijzigingsadviescommissie) voldoet aan de volgende eisen en de wijzigingsadviescommissie is
hiervoor verantwoordelijk:
• De leden zi jn beslissingsbevoegd.
• De Wi jzigingsadviescommissie is zodanig samengesteld dat er een evenwicht bestaat tussen de belangen van de
beheer- en exploitatieorganisatie (continuïteit en s tabiliteit) en de gebruikersorganisatie van de gemeente (nieuwe
functionaliteit).
• De leden van de Wijzigingsadviescommissie beschikken gezamenlijk over voldoende beheer-, exploitatie- en
materiekennis om verantwoorde besluiten over de wijzigingen te kunnen nemen.
• De verantwoordelijke voor bijvoorbeeld informatiebeveiliging en bedrijfscontinuïteitsbeheer kunnen via de
wi jzigingsbeheerder hun standpunten over wijzigingen in de Wijzigingsadviescommissie inbrengen, of zijn zelf (al dan
niet op ad hoc basis) lid van de Wijzigingsadviescommissie.
De Wi jzigingsadviescommissie kan, in overleg met de ICT-afdelingen, vaste periode instellen voor het doorvoeren van
wi jzigingen 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 geijkte werktijden (kantooruren). Ook kunnen
periodes worden vastgesteld waarin juist weinig of geen wijzigen worden gepland, zoals binnen de kantooruren of rond de
jaarwisseling.
Activiteit Uitvoering (U) /
Coördinatie (C)
Accepteren van wijzigingsverzoek Controleren of het ingediende wijzigingsverzoek aan vooraf gedefinieerde criteria voldoet.
Wi jzigingsbeheer (U)
Tabel 4: Activiteiten accepteren wijzigingsverzoek
Als het wijzigingsverzoek is geaccepteerd, wordt de informatie voor het verdere verloop van de wijziging vastgelegd in een wi jzigingsregistratie. In het verdere verloop van de wijziging wordt hier s teeds meer informatie aan toegevoegd, zoals:
• De toegekende prioriteit
• De toegekende categorie
• Beoordeling van de impact en benodigde resources, denk hierbij ook aan de kosten
• Testresultaten
• Implementatieplan inclusief een back-out-plan (terugvalscenario)
• Actuele datum en tijd van de wijziging
• De reden van een eventuele afkeuring van het wijzigingsverzoek
23
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activi teit binnen wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Bestaat er een formele procedure voor de besluitvorming betreffende wijzigingsverzoeken?
• Zi jn de discretionaire bevoegdheden10 van de wijzigingsbeheerder eenduidig vastgelegd? Zijn de
bes luitvormingsbevoegdheden van de andere betrokkenen (management) eenduidig vastgelegd?
• Is er een formele indeling naar soorten wijzigingen? (bijvoorbeeld standaard, kleine, middelgrote, grote en
spoedeisende (urgente) wijzigingen)
• Worden wijzigingsverzoeken formeel goedgekeurd? Geldt dit voor a lle soorten wijzigingen?
• Wordt er gebruik gemaakt van een 'systeem' bij de registratie en acceptatie van wijzigingsverzoeken? Is dit een
centra le registratie? Is dit systeem geautomatiseerd? Is dit systeem gerelateerd aan configuratiebeheer?
• Zi jn de kenmerken van een wijzigingsverzoek vastgesteld? Is bepaald aan welke eisen een wi jzigingsverzoek moet
voldoen, voor het in behandeling genomen wordt?
• Is er bepaald op welke wijze de communicatie met de indiener van het wijzigingsverzoek plaats vindt gedurende het
wi jzigingstraject?
• Bestaan er formele cri teria bij de beoordeling van een wijzigingsverzoek?
• Bestaat er een vastgestelde werkwijze voor het beoordelen van wijzigingsverzoeken?
• Is er vastgesteld welke cri teria een rol spelen bij het beoordelen van wijzigingsverzoeken (business impact, technische
impact, a fhankelijkheden, urgentie, benodigde inspanningen, et cetera)
• Zi jn er voorwaarde vastgesteld waaraan een wijzigingsverzoek moet voldoen (invoerscenario’s, back-out / fall back,
testmethoden, et cetera)
Inschatten van impact en resources
Bi j het inschatten van de benodigde resources en de impact van de wi jziging moet de Wijzigingsadviescommissie, de
wi jzigingsbeheerder en alle andere betrokkenen rekening houden met de volgende aspecten:
• Capaciteit en performance van de betrokken dienst(en)
• Betrouwbaarheid, veerkracht en herstelbaarheid
• Back-out-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 urgente wijzigingen, die niet volledig volgens de reguliere procedure kunnen worden afgehandeld, is een bijzondere
procedure van toepassing die vereist dat overgeslagen controlestappen achteraf worden doorlopen.
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activi teit binnen wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Zi jn cri teria vastgelegd waarmee rekening dient te worden gehouden bij het inschatten van de impact en resources?
• Is vastgelegd wie de prioriteit van wijzigingen bepaalt en wie toestemming verleent voor realisatie en implementatie
van deze wijzigingen?
10 Een discretionaire bev oegdheid is in het Nederlands bestuursrecht een bev oegdheid die een bestuursorgaan in meer of mindere m ate de
v rijheid toekent om in concrete gev allen naar eigen inzicht een besluit te nemen. (http://nl.wikipedia.org/wiki/Discretionaire_bev oegdheid)
24
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activi teit binnen wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten o m een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Is bij elke wijziging een back-out-procedure beschikbaar? Zo nee, waarom niet?
• Is bij elke wijziging een testplan beschikbaar? Zo nee, waarom niet?
• Is bij elke wijziging een communicatieplan beschikbaar? Zo nee, waarom niet?
• Zi jn de toetsingsresultaten geaccordeerd door belanghebbenden?
Verder wordt voldaan aan onderstaande cri teria:
• In verband met controle op kwaadaardige programmatuur vindt installatie en regelmatige actualisering van
antivirusprogramma’s en reparatieprogrammatuur als standaardwijziging plaats.
• Bi j wi jzigingen in besturingsprogrammatuur worden de eigenaren van toepassingssystemen er ti jdig van op de hoogte
gesteld dat de toepassingssystemen opnieuw beoordeeld moeten worden, om zeker te stellen dat er geen nadelige
gevolgen zijn voor de controle- en integriteitprocedures.
• Realisatie en implementatie van wijzigingen wordt gepland. Deze planningsgegevens worden gepubliceerd in een
a lgemeen bekendgemaakte wijzigingskalender. Afwijkingen van de planning worden gesignaleerd en geregistreerd.
• Bi j de planning wordt rekening gehouden met de beschikbaarheid van resources (ook van een gebruikersorganisatie
van de gemeente als deze bijvoorbeeld bij het testen een rol vervult), de afgesproken onderhoudswindows en de
relaties met andere wijzigingen.
• Gebruikers en beheerders worden ti jdig geïnformeerd over de implementatie, zodat zij eventueel rekening kunnen
houden met risicoverhogende momenten.
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activi teit binnen wijzigingsbeheer te
beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de
s tatus met betrekking tot wijzigingsbeheer te maken.
• Zi jn cri teria vastgesteld om wijzigingen te evalueren?
• Vindt deze evaluatie volgens een gestandaardiseerde procedure plaats?
25
Indienen en registeren VTW
VTW urgent?
Plannen:
Impact & Resources
Coördineren:
Evalueren en afsluiten
Urg
en
te p
roce
du
re
Ja
Nee
Ja
Accepteren;
filteren van VTW
Afgekeurd
Classificeren;
Categorie & Prioriteit
Co
nfig
ura
tie
be
he
er
ve
rwe
rkt d
e g
eg
eve
ns e
n b
ew
aa
kt d
e s
tatu
s v
an
de
CI’s
Bouwen
Testen
Implementeren
Werkt het?
Sta
rt b
acko
ut-
pla
n
Nee
Evt.
opnieuw
Figuur 1 Activiteiten in wijzigingsbeheer
26
Bijlage 3: bepalen prioriteit en categorie Hieronder worden de cri teria van risico en impact beschreven op basis waarvan bepaald kan worden in welke categorie een
wi jziging wordt geplaatst.
Bepaal de impact
Bepaal de mogelijke impact van de wijziging en registreer deze op het wijzigingsformulier. Hieronder volgt een voorbeeld van impactcodes.
Impact Omschrijving
5 • Als blijkt dat een dienst die een primair proces ondersteund niet beschikbaar i s en er meer dan 10
gebruikers bij betrokken zijn.
4 • Als blijkt dat een dienst die een primair proces ondersteund niet beschikbaar i s en er minder dan 10
gebruikers bij betrokken zijn.
• Als blijkt dat een dienst die een secundair proces ondersteund niet beschikbaar i s en er meer dan 5
gebruikers bij betrokken zijn.
3 • Als blijkt dat een dienst die een secundair proces ondersteund niet beschikbaar i s en er 5 gebruikers bij
betrokken zijn.
• Als blijkt dat een gehele functionaliteit voor 5 gebruikers niet beschikbaar is.
• Als blijkt dat een gedeelte van de functionaliteit voor meer dan 5 gebruikers niet beschikbaar i s.
2 • Als blijkt dat een gedeelte van de functionaliteit voor minder dan 5 gebruikers niet beschikbaar is. 1 • Als blijkt dat er sprake is van geen directe gevolgen voor de gebruikers.
Tabel 5: Impact categories
Bepaal de urgentie
Bepaal in overleg met de indiener van het wijzigingsverzoek de urgentie en registreer de bepaalde urgentiecode op het wi jzigingsformulier. Hieronder volgt een voorbeeld van urgentiecodes.
Urgentiecode Omschrijving
5 de wi jziging kan geen uitstel verdragen.
4 de wi jziging kan een maand uitstel verdragen. 3 de wi jziging kan drie maanden uitstel kan verdragen.
2 de wi jziging kan meegenomen worden in een volgende te plannen release.
1 de wi jziging kan gerealiseerd worden wanneer daar ti jd en geld voor beschikbaar zi jn.
Tabel 6: Urgentie categories
Bepaal de prioriteit
Bepaal de prioriteit met behulp van onderstaande tabel en registreer deze op het wijzigingsformulier. Hieronder volgt een
voorbeeld van prioriteitscodes.
Prioriteit Omschrijving 2 Hoogste prioriteit: De wi jziging betreft een probleem dat bij de gebruiker aanzienlijke hinder veroorzaakt in het
gebruik van essentiële diensten, of het betreft een dringend gewenste aanpassing van de ICT (bijvoorbeeld nieuwe f
unctionaliteiten vanwege bedrijfsoverwegingen of een noodwet). Het wi jzigingsverzoek moet direct worden
ui tgevoerd, het gaat hier om het operationeel belang. Wijzigingen met deze prioriteit va llen onder de categorie
‘Urgente wijziging’. Urgente wijzigingen wijken af van de normale procedures omdat voor dit type de benodigde
resources meteen moeten worden vri jgemaakt. Een spoedvergadering van de Wijzigingscommissie kan vereist zijn.
1 Hoge prioriteit: het betreft een ernstige verstoring voor een aantal gebruikers, is een vervelende storing voor een grote groep gebruikers, of het is gerelateerd aan andere dringende zaken. Het wijzigingsverzoek mag niet worden
ui tgesteld, de bedrijfsvoering komt in gevaar. 0 Normale/standaard prioriteit: geen grote urgentie of hoge impact, maar een wijziging mag worden uitgesteld tot
een later ti jdstip. Het wijzigingsverzoek is gewenst.
27
Bepaal de categorie
Bepaal met behulp van de bepaalde prioriteit de categorie en registreer deze op het wijzigingsformulier. Hieronder een
voorbeeld van de indeling van categorieën:
Urgentiecode Omschrijving 3 Grote gevolgen/Groot: Een wi jziging waarbij een aanzienlijke inspanning nodig is, acuut de voortgang
belemmeren en waarmee aanzienlijke ingrepen in de ICT-infrastructuur worden gepleegd. Wanneer bijvoorbeeld
een belangrijke investeringsbeslissing noodzakelijk is of wanneer de wijziging afwijkt van het b estaande beleid,
dient het wijzigingsvoorstel goedgekeurd (geautoriseerd) te worden door het management team van de ICT-
afdeling. Na goedkeuring zal de wijziging alsnog aan de Wi jzigingscommissie worden voorgelegd. De
noodprocedure wordt gevold. 2 Substantiële gevolgen/Middelgroot: Wi jzigingen waarbij flinke inspanningen nodig zi jn, gevaar voor de
voortgang opleveren en die een behoorlijke impact hebben op de dienstverlening. Deze wijzigingen worden
voorgelegd aan de Wijzigingsadviescommissie. Deze is samengesteld uit vertegenwoordigers van die delen van
de organisatie die direct bij de wijziging betrokken zijn. Op deze manier kunnen de gevolgen van de wijziging en
de noodzakelijke inspanning om de wijziging te realiseren voldoende in kaart gebracht worden. De hoge prioriteit
procedure wordt gevold.
1 Geringe gevolgen/Klein: Deze wijzigingen kunnen veelal relatief eenvoudig afgehandeld worden en geen direct
gevaar voor de voortgang opleveren. Er i s weinig werk mee gemoeid en er wordt weinig veranderd. De
wi jzigingsbeheerder kan dit soort wijzigingen goedkeuren zonder deze voor te leggen aan de
Wi jzigingsadviescommissie. De s tandaardprocedure wordt gevold.
Tabel 7: Urgentiecodes omschrijving
Afhandelingsprocedures
Aan de verschillende categorieën zijn bij voorkeur specifieke afhandelingsprocedures gekoppeld. Hieronder zi jn
voorbeelden van afhandelingsprocedures:
• De standaard procedure i s bestemd voor wijzigingsvoorstellen die een beperkte impact hebben en geen direct gevaar
voor de voortgang opleveren. Bij de s tandaard procedure wordt de levenscyclus van een wijzigingsverzoek normaal
doorlopen. Er worden geen aparte vergaderingen van de Wijzigingsadviescommissie belegd.
Hieronder volgt een opsomming van de afwijkingen voor de verschillende afhandelingsprocedures.
o Wijzigingsbeheer registreert, beoordeelt en classificeert het wijzigingsvoorstel normaal binnen het kader van
de s tandaardwerkzaamheden.
o Wijzigingsbeheer meldt het wijzigingsvoorstel aan voor de agenda van de eerstkomende vergadering van de
Wi jzigingsadviescommissie.
o De Wi jzigingsadviescommissie beslist ti jdens de vergadering over het wijzigingsvoorstel.
• De hoge prioriteit procedure i s bestemd voor wijzigingsvoorstellen die een belangrijke impact hebben en gevaar voor
de voortgang opleveren. Bij de hoge prioriteit procedure wordt de levenscyclus van een wijzigingsverzoek normaal,
maar in verhoogd tempo doorlopen. Er wordt een aparte vergadering van de Wi jzigingsadviescommissie belegd.
Hieronder volgt een opsomming van de afwijkingen voor de verschillende afhandelingsprocedures.
o Wijzigingsbeheer registreert en beoordeelt het voorstel met voorrang vóór de s tandaardwerkzaamheden.
o Wijzigingsbeheer verzoekt om een spoedige vergadering van de Wijzigingsadviescommissie.
o De Wi jzigingsadviescommissie beslist ti jdens de vergadering over het wijzigingsvoorstel.
• De nood procedure i s bestemd voor wijzigingsverzoeken die een belangrijke impact hebben en acuut de voortgang
belemmeren. Bij de nood procedure wordt de levenscyclus van een wijzigingsverzoek doorbroken.
Hieronder volgt een opsomming van de afwijkingen voor de verschillende afhandelingsprocedures.
o Wijzigingsbeheer registreert en beoordeelt het voorstel met voorrang vóór de s tandaardwerkzaamheden.
o 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 Wijzigingsadviescommissie en
roept zo snel mogelijk de Wijzigingsadviescommissie bijeen.
28
o De Wi jzigingsadviescommissie 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.
29
Bijlage 4: Definities Rollback (terugvalscenario):
Een activi teit die een dienst of een ander configuratie-item terugzet op een eerder uitgangspunt. Back-out wordt gebruikt a ls een vorm van herstel wanneer een wijziging of uitgifte niet lukt.
Bekende fout:
Een probleem dat een gedocumenteerde onderliggende oorzaak en een workaround heeft. Bekende fouten worden ti jdens hun levenscyclus gecreëerd en beheerd door probleembeheer. Bekende fouten kunnen ook worden geïdentificeerd door ontwikkeling en leveranciers.
Categorie:
Een bepaalde groep van zaken die iets gemeen hebben. Categorieën worden gebruikt om gelijke zaken te groeperen. Bi jvoorbeeld: kostentypen worden gebruikt om gelijke typen kosten te groeperen, incidentcategorieën worden gebruikt om
gel ijke typen incidenten te groeperen, CI-typen worden gebruikt om gelijke typen configuratie-items te groeperen.
Configuratiebeheer:
Het proces dat verantwoordelijk i s om te garanderen dat de bedrijfsmiddelen, die nodig zijn om diensten te leveren op een adequate wijze, worden beheerd en dat accurate en betrouwbare informatie over die bedrijfsmiddelen beschikbaar i s, wanneer en waar dat nodig is. Die informatie omvat details over hoe de bedrijfsmiddelen zijn samengesteld en details over relaties tussen bedrijfsmiddelen.
Configuratiebeheerdatabase (CBDB):
Een gegevensbestand dat wordt gebruikt om de configuratieregistraties op te slaan ti jdens hun levenscyclus. Het
configuratiebeheersysteem onderhoudt een of meer CBDB's, en elke CBDB s laat attributen van configuratie-items op. Evenals relaties met andere configuratie-items.
Configuratie-item (CI):
Elk component of ander dienstenbedrijfsmiddel dat beheerd moet worden voor de levering van een ICT-dienst. Informatie over elk configuratie-item is geregistreerd in een configuratieregistratie binnen het configuratiebeheersysteem, en wordt onderhouden tijdens zi jn levenscyclus door dienstenbedrijfsmiddelen - en configuratiebeheer. Wi jzigingsbeheer is verantwoordelijk voor wijzigingen aan configuratie-items. Kenmerkende configuratie-items zijn bijvoorbeeld: ICT-diensten, hardware, software, gebouwen, mensen, en formele documentatie, zoals procesdocumentatie en dienstenniveauovereenkomsten.
Dienstenniveaubeheer:
Het proces dat verantwoordelijk i s om realiseerbare dienstenniveauovereenkomsten af te spreken en garandeert dat daaraan wordt voldaan. Dienstenniveaubeheer is verantwoordelijk voor de garantie dat alle ICT-dienstenbeheerprocessen,
operationele overeenkomsten en onderliggende contracten zijn afgestemd op de overeengekomen dienstenniveaudoelen. Dienstenniveaubeheer bewaakt dienstenniveaus, rapporteert erover, evalueert de dienstverlening regelmatig met de gebruikersorganisatie van de gemeente en identificeert vereiste verbeteringen.
Dienstenniveauovereenkomst (DNO)/Service Level Agreements (SLA):
Een overeenkomst tussen een ICT-dienstenaanbieder en een gemeente. De Dienstenniveau overeenkomst beschrijft de ICT-dienst, legt dienstenniveaudoelen vast en definieert de verantwoordelijkheid van de ICT-dienstenaanbieder en de gemeente. Een afzonderlijke overeenkomst kan verschillende ICT-diensten of verscheidene gemeenten bevatten.
Expertiseteam:
zie oplosgroep
Impact:
De mate waarin een incident, probleem of wi jziging effect heeft op bedrijfsprocessen. Impact is vaak gebaseerd op het
effect op dienstenniveaus. Impact en urgentie worden gebruikt op prioriteit aan te geven.
30
Urgente wijziging / noodwijziging / emergency change:
Een wi jziging die zo snel mogelijk moet worden geïntroduceerd. Bijvoorbeeld: om e en ernstig incident op te lossen of een
beveiligingspatch te implementeren. Het wijzigingsbeheerproces heeft gewoonlijk specifieke procedures voor het omgaan met noodwijzigingen.
Noodwijzigingsadviescommissie / Emergency Change Advisory Board (ECAB):
Een subgroep van de wijzigingsadviescommissie die besluiten neemt over noodwijzigingen. Tot lidmaatschap kan worden bes loten op het moment dat een vergadering plaatsvindt en is afhankelijk van de aard van de noodwijziging.
Normale wijziging / normal change:
Een wi jziging die geen noodwijziging of standaardwijziging is. Normale wijzigingen volgen de gedefinieerde stappen van het
wi jzigingsbeheerproces.
Oplosgroep:
Een groep mensen met technische vaardigheden. Oplosgroepen leveren technische ondersteuning die nodig i s voor a lle ICT-dienstenbeheerprocessen.
Prioriteit:
Een categorie die wordt gebruikt om het relatieve belang te bepalen van een incident, probleem of wijziging. Prioriteit is gebaseerd op impact en urgentie, en wordt gebruikt om te bepalen hoeveel tijd nodig i s voor de acties die moeten worden ondernomen. Bijvoorbeeld: de Dienstenniveauovereenkomst kan aangeven dat incidenten met prioriteit 2 binnen 12 uur moeten zijn opgelost.
Standaardwijziging / standaardchange:
Een vooraf geautoriseerde wijziging met een laag risico, die relatief veel voorkomt en een procedure of werkinstructie
volgt, zoals het resetten van een wachtwoord of een nieuwe medewerker voorzien van standaardapparatuur. Voor het implementeren van een standaardwijziging zijn wijzigingsverzoeken niet vereist. Standaardwijzigingen worden geregistreerd en gevolgd met een ander mechanisme zoals een dienstverleningsverzoek. Deze s tandaardwijzigingen dienen
wel geregistreerd te worden in het wi jzigingsbeheersysteem.
Terugval / terugrol:
Ondernomen acties voor herstel na een mislukte wijziging of uitgifte. Terugval kan back-out, activering van dienstcontinuïteitsplannen bevatten of andere acties om het bedrijfsproces te continueren
Uitgifte / release:
Een of meer wijzigingen aan een ICT-dienst die samen worden gebouwd, getest en uitgerold. Een enkele uitgifte kan wi jzigingen omvatten aan hardware, software, documentatie, processen en andere componenten.
Releasebeheer / uitgiftemanagement:
Uitgifte- en uitrolbeheer / release- en deployment management:
Het proces dat verantwoordelijk i s voor planning en controle van de samenstelling, het testen en de uitrol van uitgiftes, en voor het leveren van de nieuwe functionaliteit die vereist i s door de bedrijfsvoering. Terw ijl het de integriteit van de
bestaande diensten beschermt.
Urgentie:
Een maatstaf die aangeeft hoe lang het duurt tot een incident, probleem of wijziging een significante impact op de
bedri jfsvoering heeft. Zo kan een incident met een hoge impact een lage urgentie hebben, als de impact de bedrijfsvoering pas schaadt aan het eind van het financiële jaar. Impact en urgentie worden gebruikt om een prioriteit toe te kennen.
Veerkracht / resilience:
Het vermogen van een ICT-dienst of configuratie-item om weerstand te bieden tegen storingen of snel te herstellen na een
s toring. Bijvoorbeeld: een beschermde kabel biedt weerstand op het moment dat er druk op wordt uitgeoefend.
31
Wijziging:
De toevoeging, verandering of verwijdering van alles dat een effect kan hebben op ICT-diensten. De scope is gericht op alle
wi jzigingen van alle architecturen, processen, instrumenten, meetwaarden en documentatie, en op wijzigingen van ICT -diensten en andere configuratie-items.
Wijzigingsadviescommissie / Change Advisory Board (CAB):
Een groep mensen die de beoordeling, de prioriteitsstelling, de autorisatie en de planning van wijzigingen ondersteunt. Een Wi jzigingsadviescommissie bestaat veelal uit vertegenwoordigers van alle afdelingen binnen de ICT-dienstenaanbieder, het bedri jf en derden (zoals toeleveranciers).
Wijzigingsbeheer:
Het proces dat verantwoordelijk i s voor het beheersen van de levenscyclus van alle wijzigingen, om verbeteringen met minimale verstoring van de ICT-diensten uit te voeren.
Wijzigingsplan / changeplan:
Een document dat alle geautoriseerde wijzigingen en geplande implementatiegegevens met de geschatte datums van
wi jzigingen op langere termijn beschrijft. Een wijzigingsschema wordt soms een voorlopig wijzigingsschema (forward schedule of change) genoemd, terwijl het ook informatie over al geïmplementeerde wijzigingen bevat.
Wijzigingsregistratie:
Een registratie van de details van een wijziging. Elke wijzigingsregistratie documenteert de levenscyclus van een afzonderlijke wijziging. Een wijzigingsregistratie wordt gecreëerd voor elk wijzigingsverzoek dat binnenkomt, ook voor die verzoeken die later afgewezen worden. Wijzigingsregistraties verwijzen naar de configuratie-items die door de wijziging
worden beïnvloed. Wijzigingsregistraties worden opgeslagen in het configuratiebeheersysteem of ergens anders in het diensten kennisbeheersysteem.
Wijzigingsverzoek / Verzoek tot Wijziging (VTW):
Formeel verzoek voor een wijziging. Een wijzigingsverzoek bevat details van de voorgestelde wijzigi ng, en kan op papier
worden geregistreerd of elektronisch. De term wijzigingsverzoek wordt vaak verkeerd gebruikt als wijzigingsregistratie of de wi jziging zelf.
32
Bijlage 5: Literatuur/bronnen Voor deze publicatie is gebruik gemaakt van onderstaande bronnen:
Titel: Basisnormen Beveiliging en Beheer ICT-infrastructuur Wie: Platform Informatiebeveiliging (opgegaan in Platform voor Informatiebeveiliging (PvIB)) Uitgeverij: LEMMA BV Datum: 2003 ISBN-10: 90-5931-228-7 (niet meer leverbaar) Titel: Studierapport Normen voor de beheersing van uitbestede ICT-beheerprocessen Wie: gezamenlijk initiatief van de NOREA en het Platform voor Informatiebeveiliging (PvIB) Datum: 12 december 2007
Titel: Foundations of IT Service Management, op basis van ITIL
Datum: september 2009
Uitgever: van Haren Publishing
ISBN-13: 978-9077212714
Titel: Security Management
Datum: 2004
Uitgever: TSO (The Stationery Office)
ISBN-10: 0-11-330014-X
ISBN-13: 978-0113300143
33
Kijk voor meer informatie op:
www.informatiebeveiligingsdienst.nl
Nassaulaan 12
2514 JS Den Haag
CERT: 070 373 80 11 (9:00 – 17:00 ma – vr)
CERT 24x7: Piketnummer (instructies via voicemail)