Upload
donhu
View
267
Download
4
Embed Size (px)
Citation preview
HANDREIKING PROCES WIJZIGINGSBEHEER
Een van de producten van de operationele variant van de Baseline
Informatiebeveiliging Nederlandse Gemeenten (BIG)
2
Colofon
Naam document
Handreiking proces wijzigingsbeheer
Versienummer
1.0
Versiedatum
April 2014
Versiebeheer
Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD).
Copyright © 2014 Kwaliteitsinstituut Nederlandse Gemeenten (KING).
Alle 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. KING wordt als bron vermeld;
2. het document en de inhoud mogen commercieel niet geëxploiteerd worden;
3. publicaties of informatie waarvan de intellectuele eigendomsrechten niet bij de verstrekker
berusten, blijven onderworpen aan de beperkingen opgelegd door KING;
4. ieder kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van de in deze
paragraaf vermelde mededeling.
Rechten en vrijwaring
KING is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te
verzorgen. Niettemin kan KING geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave
voorkomende onjuistheden, onvolledigheden of nalatigheden. KING 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.
In samenwerking met
De producten van de operationele variant van de Baseline Informatiebeveiliging Nederlandse
Gemeenten (BIG) worden vervaardigd in samenwerking met:
3
Voorwoord De IBD is een gezamenlijk initiatief van de Vereniging van Nederlandse Gemeenten (VNG) en het
Kwaliteitsinstituut Nederlandse Gemeenten (KING) en actief sinds 1 januari 2013. Aanleiding voor de
oprichting van de IBD vormen enerzijds de leerpunten uit een aantal grote incidenten op
informatiebeveiligingsvlak en anderzijds de visie Digitale Overheid 2017.
De IBD is er voor alle gemeenten en richt zich op bewustwording en concrete ondersteuning om
gemeenten te helpen hun informatiebeveiliging naar een hoger plan te tillen.
De IBD heeft drie doelen:
1. het preventief en structureel ondersteunen van gemeenten bij het opbouwen en onderhouden van
bewustzijn als het gaat om informatiebeveiliging.
2. het leveren van integrale coördinatie en concrete ondersteuning op gemeente specifieke aspecten
in geval van incidenten en crisissituaties op het vlak van informatiebeveiliging.
3. het bieden van gerichte projectmatige ondersteuning op deelgebieden om informatiebeveiliging in
de praktijk van alle dag naar een hoger plan te tillen. De ondersteuning die de IBD biedt bij het
ICT-Beveiligingsassessment DigiD is een voorbeeld van een dergelijk project.
Hoe realiseert de IBD haar doelen?
Om invulling te kunnen geven aan haar doelen is door de IBD op basis van de Baseline
Informatiebeveiliging Rijksdienst (BIR) een vertaalslag gemaakt naar een baseline voor de
gemeentelijke markt. Deze Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) betreft twee
varianten, een Strategische- én een Tactische Baseline. Beide varianten van de BIG zijn beschikbaar
voor alle gemeenten op de website en community van de IBD, zodat door iedere gemeente tot
implementatie van de BIG kan worden overgegaan. Bestuur en management hebben met deze
baseline een instrument in handen waarmee zij in staat zijn om te meten of de organisatie ‘in control’
is op het gebied van informatiebeveiliging. Om de implementatie van de Strategische en Tactische
Baseline te ondersteunen, zijn door de IBD in samenwerking met de Taskforce Bestuur en
Informatieveiligheid Dienstverlening producten ontwikkeld op operationeel niveau. Dit heeft een
productenportfolio opgeleverd, genaamd de Operationele Baseline Nederlandse Gemeenten.
Onderhavig product is onderdeel van het productenportfolio.
Naast een productenportfolio, heeft de IBD voor gemeenten ook een dienstenportfolio ontwikkeld. Voor
een volledig overzicht van het producten- en dienstenportfolio, kunt u terecht op de website van de
IBD.
De gemeente is zelf verantwoordelijk voor het opstellen en/of uitvoeren en/of handhaven van de
regels. Hierbij geldt:
- Er is wetgeving waar altijd aan voldaan moet worden, zoals niet uitputtend: GBA, SUWI, BAG, PUN
en WBP, maar ook de archiefwet.
- Er is een gemeenschappelijk normenkader als basis: de Baseline Informatiebeveiliging Nederlandse
Gemeenten (BIG).
- De gemeente stelt dit normenkader vast, waarbij er ruimte is in de naleving van dat kader voor
afweging en prioritering op basis van het ‘pas toe of leg uit’ principe.
4
Leeswijzer
Dit product maakt onderdeel uit van de operationele variant van de Baseline Informatiebeveiliging
Nederlandse Gemeenten (BIG).
Doel
Dit product bevat aanwijzingen voor het omgaan met het doorvoeren van wijzigingen in de ICT-
middelen en -diensten, en aanwijzingen voor gebruik en inrichting van het proces wijzigingsbeheer.
Doelgroep
Dit document is van belang voor de systeemeigenaren, applicatiebeheerders en de ICT-afdeling.
Relatie met overige producten
Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)
o Strategische variant van de Baseline Informatiebeveiliging voor Gemeenten
o Tactische variant van de Baseline Informatiebeveiliging voor Gemeenten
Informatiebeveiligingsbeleid van de gemeente
Basis procedure configuratiebeheer
Incident Management en responsebeleid
Basis continuïteitsplannen in verband met stroomuitval / Disaster Recovery Plan (DRP)
Business Continuity Management (BCM)
Basis beveiligingsparagraaf Service Level Agreement (SLA)
Uitbesteding ICT-diensten
Patchmanagement
Maatregelen tactische variant Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)
Maatregel 6.1.4 Goedkeuringsproces voor ICT-voorzieningen
Maatregel 6.2.3 Beveiliging behandelen in overeenkomsten met een derde partij
Maatregel 10.1.2 Wijzigingsbeheer
Maatregel 10.1.4 Scheiding van faciliteiten voor ontwikkeling, testen en productie
Maatregel 10.2.3 Beheer van wijzigingen in dienstverlening door een derde partij
Maatregel 10.10.2 Controle van systeemgebruik
Maatregel 12.1.1 Analyse en specificatie van beveiligingseisen
Maatregel 12.5.1 Procedures voor wijzigingsbeheer
Maatregel 12.5.2 Technische beoordeling van toepassingen na wijzigingen in het
besturingssysteem
Maatregel 12.5.3 Restricties op wijzigingen in programmatuurpakketten
5
Inhoudsopgave
Colofon 2
Voorwoord 3
Leeswijzer 4
Inhoudsopgave 5
1 Inleiding 6 1.1 De indeling van dit document is als volgt: 8
1.2 Aanwijzing voor gebruik 8
2 Handreiking proces 9 2.1 Registreren 10
2.2 Accepteren 14
2.3 Classificeren 15
2.4 Plannen 17
2.5 Coördineren 19
2.6 Evalueren 21
2.7 Uitvoeren van urgente wijzigingen 21
3 Afspraken vastleggen 23
4 Prestatie-indicatoren 24
Bijlage 1: template verzoek tot wijziging 25
Bijlage 2: bepalen prioriteit en categorie 27
Bijlage 3: definities 30
Bijlage 4: literatuur/bronnen 33
6
1 Inleiding
De Baseline Informatiebeveiliging voor Gemeenten (BIG) heeft maatregelen beschreven die te
maken hebben met wijzigingsbeheer, zie hiervoor ook het voorbeeld gemeentelijk
informatiebeveiligingsbeleid.
Doelstelling van procedure wijzigingsbeheer
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.
Beheerdoelstellingen van 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 wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-,
continuïteits- en beveiligingsaspecten, evenals (eind)gebruikersaspecten te worden getoetst.
Indien wijzigingen niet zijn 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 wijziging. Het is daarom van belang om deze
effecten gestructureerd in kaart te brengen en de impact af te stemmen met alle
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 de verstoring van de dienstverlening minimaal
is.
Indien wijzigingen niet tijdig 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 tijdig 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 slechts gedeeltelijk, bijdragen aan verbetering van de ICT-diensten of zelfs
verstorend zijn voor de ICT-diensten. Indien wijzigingen 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).
Wijzigingen
Een wijziging is de toevoeging, verandering of verwijdering van alles dat een effect kan hebben op
ICT-diensten. De scope is gericht op alle wijzigingen van alle architecturen, processen,
instrumenten, meetwaarden en documentatie, en op wijzigingen 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
7
problemen. Kwetsbaarheden die verholpen worden door een beveiligingsupdate (patch) zijn 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
zijn van de ICT-dienstverlening als gevolg van wijzigingen afneemt, en dat eventuele toch
opgetreden storingen 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 wijzigingsbeheerder voert onder andere onderstaande activiteiten uit:
De wijzigingsbeheerder checkt de volledigheid en juistheid van het wijzigingsvoorstel op basis
van een door de wijzigingsbeheerder opgestelde checklist.
De wijzigingsbeheerder ziet erop toe dat de wijzigingsprocedures worden gehandhaafd, en
bewaakt de voortgang van de afhandeling van wijzigingen.
De wijzigingsbeheerder classificeert in overleg met de indiener het wijzigingsvoorstel op basis
van prioriteit en categorie.
De wijzigingsbeheerder laat op een geaccepteerd wijzigingsvoorstel een impactanalyse
uitvoeren, en stelt 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 activiteiten
o Begroting
o Risicoanalyse
De wijzigingsbeheerder is voorzitter van de Wijzigingsadviescommissie1, waarin alle expertise
is verzameld zodat de wijzigingsvoorstellen op alle aspecten beoordeeld kunnen worden en
waarvan de leden samenkomen in het wijzigingsoverleg.
De wijzigingsbeheerder verstrekt aan de Wijzigingsadviescommissie de rapportage van de
uitgevoerde impactanalyse en de (op basis van de uitgevoerde impactanalyse) gewijzigde
uitgifteplanning.
De wijzigingsbeheerder is voorzitter van het wijzigingsoverleg waarin de wijzigingsvoorstellen
(al dan niet) geautoriseerd worden. Impactanalyses worden door de Wijzigingsadviescommissie
gebruikt bij het beoordelen van wijzigingsvoorstellen. De uitgifteplanning wordt door de
Wijzigingsadviescommissie gebruikt om de haalbaarheid van een wijzigingsvoorstel voor een
bepaalde datum te kunnen beoordelen.
1 De Wijzigingscommissie is een groep mensen die de beoordeling, de prioriteitsstelling, de autorisatie en de planning van wijzigingen ondersteunt. Een Wijzigingsadviescommissie bestaat veelal uit vertegenwoordigers van alle afdelingen binnen de ICT-dienstenaanbieder, het bedrijf en derden (zoals toeleveranciers).
8
Eventuele urgente wijzigingsvoorstellen worden (afhankelijk van de beschikbare tijd) wel of
niet beoordeeld met behulp van een impactanalyse, wel of niet voorgelegd aan de
Wijzigingsadviescommissie, maar worden altijd getest. De wijzigingsbeheerder zorgt er voor
dat hij de procesgang rondom urgente wijzigingsvoorstellen bijhoudt en te allen tijde kan
verantwoorden aan de Wijzigingsadviescommissie en de ICT-manager2.
1.1 De indeling van dit document is als volgt:
Hoofdstuk 2 : Handreiking proces
Hoofdstuk 3 : Afspraken vastleggen
Hoofdstuk 4 : Prestatie indicatoren
1.2 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
wijzigingsbeheer en aanverwante procedures. Deze handleiding is geen volledige
procesbeschrijving. Het proces wijzigingsbeheer wordt vaak uitgevoerd binnen de ICT-afdeling.
De gemeentelijke beleidsregels met betrekking tot wijzigingsbeheer (systeemplanning en –
acceptatie) zijn:3
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).
Faciliteiten voor Ontwikkeling, Testen, Acceptatie en Productie (OT(A)P) zijn gescheiden om
onbevoegde toegang tot, of wijzigingen in het productiesysteem te voorkomen.
2 De ICT-manager is verantwoordelijk voor de gehele ICT-gerelateerde dienstverlening. 3 Zie ook het algemene informatiebeveiligingsbeleid
9
2 Handreiking proces
Wijzigingsbeheer kent voor het verwerken van wijzigingen de volgende activiteiten:
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 wijzigingsverzoeken (VTW, Verzoek tot Wijziging) filteren en accepteren 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.
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
10
Tevens worden in dit hoofdstuk de in Figuur 1 benoemde processtappen verder uitgewerkt.
Beoordelen van kwaliteit wijzigingsbeer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om wijzigingsbeheer te
beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende handvatten om een
eerste inschatting van de status met betrekking tot wijzigingsbeheer te maken.
Is het doel van wijzigingsbeheer eenduidig vastgelegd?
Zijn 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 wijzigingsbeheer gescheiden van ontwikkelings- en productietaken?
Zijn de verantwoordelijkheden en procedures met betrekking tot wijzigingsbeheer formeel
vastgelegd, zodat er voldoende controle is op alle wijzigingen aan apparatuur, programmatuur
en procedures?
Is er voldoende capaciteit beschikbaar om wijzigingen tijdig te kunnen behandelen?
Is er sprake van een juiste functiescheiding binnen het proces wijzigingsbeheer?
Zijn 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 (inclusief 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 alle 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?
2.1 Registreren
Door wijzigingsbeheer worden alleen geautoriseerde wijzigingsverzoeken in behandeling genomen
en om dit te realiseren dient door de gemeente vastgelegd te zijn welke gemeenteambtenaren
welk type wijzigingsverzoek mogen indienen.
Alle wijzigingsverzoeken moeten worden geregistreerd. Er zijn door wijzigingsbeheer eisen gesteld
aan de wijze waarop een wijzigingsverzoek wordt ingediend en welke informatie daarbij minimaal
moet worden verstrekt. Alle wijzigingen worden bij voorkeur geregistreerd in een
wijzigingsbeheersysteem. Eisen die aan dit wijzigingsbeheersysteem dienen te worden gesteld zijn
bijvoorbeeld:
Unieke identificatie van wijzigingen (wijzigingsnummer).
11
Mogelijkheden om de verschillende stappen in het wijzigingsproces vast te leggen.
Mogelijkheden 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 status 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 dienstenniveaubeheer.
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 zijn geïmplementeerd. Ook kunnen zij aangeven dat bepaalde versies niet
langer worden ondersteund, of dat voor een versie geen garanties kunnen worden afgeven.
Zoals het stoppen van Microsoft met het uitbrengen van updates voor Windows XP. Het
besturingssysteem Windows XP krijgt de status 'end-of-life'.4
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.
Indeling van de wijzigingen
Hieronder een voorbeeld indeling van wijzigingen:
Standaardwijzigingen: Dit zijn routinematige beheertaken, die procedurematig
(gestandaardiseerd) worden uitgevoerd. 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: Dit type wijziging 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 vrijgemaakt. Ook kan een spoedvergadering van de Wijzigingsadviescommissie
vereist zijn.
(Overige) wijzigingen: Dit betreft alle overige wijzigingsverzoeken om aanpassingen aan de
beheerde ICT-infrastructuur aan te brengen. Voor deze wijzigingen gelden de
standaardwijzigingsprocedures, zoals in dit document beschreven.
Welke informatie moet worden verstrekt?
4 Zie voor meer informatie https://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/factsheets/factsheet-stop-met-gebruik-windows-xp.html
12
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 wijzigingsverzoek heeft geautoriseerd.
Datum waarop het wijzigingsverzoek is ingediend.
Een omschrijving van de voorgestelde wijziging.
o Indien van toepassing de referentie naar het achterliggende incident/probleem.
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 wijziging.
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:
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, uitwijk)? 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.5 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) of het College Bescherming
Persoonsgegevens (CBP)6?
Ook kunnen de volgende hulpmiddelen ondersteuning bieden om de impact van de
voorgestelde wijziging op het beschermingsniveau vast te stellen:
o Toetsmodel Privacy Impact Assessment (PIA) Rijksdienst.7
o Methodische handreiking voor de uitvoering van Privacy Impact Assessments (PIA).8
o Privacy Impact Assessment bij de Belastingdienst.9
5 Zie hiervoor ook het operationele product ‘Basis risicoanalysemethode gemeenten’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 6 http://www.cbpweb.nl/ 7 http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/publicaties/2013/06/24/toetsmodel-privacy-impact-assessment-pia-rijksdienst/toetsmodel-privacy-impact-assessment-pia-rijksdienst.pdf 8 http://www.norea.nl/readfile.aspx?ContentID=76469&ObjectID=1101339&Type=1&File=0000040117_NOREA%20A4%20Privacy%20Impact%20Assessment%2003%20WEB.pdf 9 http://www.cip-overheid.nl/wp-content/uploads/2013/10/Privacy-impact-assessment-bij-de-Belastingdienst.pdf
13
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 bijlage 1 wordt een voorbeeld van een wijzigingsformulier weergegeven.
Indien bovenstaande gegevens niet voorhanden zijn wordt het wijzigingsverzoek geweigerd. Bij
een geaccepteerde wijziging 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 wijzigingsbeheerder is eindverantwoordelijk voor de juiste toewijzing.
Hieronder wordt een overzicht gegeven 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 wijzigingsformulier.
Criteria vaststellen met betrekking tot impact, urgentie en
prioriteit.
Invullen van wijzigingsformulier.
Wijzigingsbeheer (U)
Wijzigingsbeheer (U)
Wijzigingsbeheer (U)
Indiener (U) /
Wijzigingsbeheer (C)
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activiteit binnen
wijzigingsbeheer te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende
handvatten om een eerste inschatting van de status 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 status van een configuratie-item, zoals vastgelegd bij
configuratiebeheer?10
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?
Zijn criteria met betrekking tot impact, urgentie en prioriteit vastgesteld?
10 Zie hiervoor ook het operationele product ‘Handreiking proces configuratiebeheer’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG).
14
2.2 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 afgewezen en/of het wijzigingsverzoek opnieuw in te dienen.
Activiteit Uitvoering (U) /
Coördinatie (C)
Accepteren van wijzigingsverzoek
Controleren of het ingediende wijzigingsverzoek aan vooraf
gedefinieerde criteria voldoet.
Wijzigingsbeheer (U)
Als het wijzigingsverzoek 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 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
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activiteit binnen
wijzigingsbeheer te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende
handvatten om een eerste inschatting van de status met betrekking tot wijzigingsbeheer te maken.
Bestaat er een formele procedure voor de besluitvorming betreffende wijzigingsverzoeken?
Zijn de discretionaire bevoegdheden11 van de wijzigingsbeheerder eenduidig vastgelegd? Zijn
de besluitvormingsbevoegdheden 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 alle soorten wijzigingen?
Wordt er gebruik gemaakt van een 'systeem' bij de registratie en acceptatie van
wijzigingsverzoeken? Is dit een centrale registratie? Is dit systeem geautomatiseerd? Is dit
systeem gerelateerd aan configuratiebeheer?
Zijn de kenmerken van een wijzigingsverzoek vastgesteld? Is bepaald aan welke eisen een
wijzigingsverzoek 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 wijzigingstraject?
Bestaan er formele criteria bij de beoordeling van een wijzigingsverzoek?
Bestaat er een vastgestelde werkwijze voor het beoordelen van wijzigingsverzoeken?
11 Een discretionaire bevoegdheid is in het Nederlands bestuursrecht een bevoegdheid die een bestuursorgaan in meer of mindere mate de vrijheid toekent om in concrete gevallen naar eigen inzicht een besluit te nemen. (http://nl.wikipedia.org/wiki/Discretionaire_bevoegdheid)
15
Is er vastgesteld welke criteria een rol spelen bij het beoordelen van wijzigingsverzoeken
(business impact, technische impact, afhankelijkheden, urgentie, benodigde inspanningen, et
cetera)
Zijn er voorwaarde vastgesteld waaraan een wijzigingsverzoek moet voldoen (invoerscenario’s,
back-out, testmethoden, et cetera)
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
standaardwijzigingen12, 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 bedrijfsvoering 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 wijziging 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.
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 als 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.
De impact met betrekking tot het beveiligingsniveau en de bescherming van de persoonsgegevens
worden hieronder verder toegelicht.
Impact beveiligingsniveau
12 Een standaardwijziging is 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. Deze standaardwijzigingen dienen wel geregistreerd te worden in het wijzigingsbeheersysteem.
16
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) of het College Bescherming Persoonsgegevens
(CBP)13?
Prioriteit
De prioriteit wordt gebruikt om het relatieve belang te bepalen van een wijziging. 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. Bijvoorbeeld: de Dienstenniveau overeenkomst (DNO) kan
aangeven dat incidenten met prioriteit 2, binnen 12 uur moeten zijn opgelost.
Van elke wijziging wordt de prioriteit bepaald en voor het indelen in prioriteitsklassen zijn criteria
vastgesteld.
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.
In bijlage 2 worden voorbeelden gegeven van impact-, urgentie-, en prioriteitscodes en een
indeling van categorieën.
Activiteit Uitvoering (U) /
Coördinatie (C)
Toekennen van urgentie
De urgentie wordt, in overleg met de indiener, toegekend.
Wijzigingsbeheer (U)
Toekennen van impact
De impact wordt toegekend. De impact wordt op verschillende
disciplines door verschillende gemeentefunctionarissen vastgesteld.
Applicatiebeheer (U),
Functioneel beheer (U),
Beveiligingsfunctionaris
13 http://www.cbpweb.nl/
17
(U) / Wijzigingsbeheer
(C)
Toekennen van prioriteit
De prioriteit geeft het belang aan en is een afgeleide van urgentie
en impact.
Wijzigingsbeheer (U)
Toekennen van categorie
De categorie wordt, eventueel in overleg met de
Wijzigingsadviescommissie, toegekend.
Categorieën worden toegekend door wijzigingsbeheer, zo nodig in
overleg met de Wijzigingsadviescommissie, die een indicatie geeft
van de impact van de wijziging en de belasting op de ICT-
organisatie.
Wijzigingsbeheer (U)
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activiteit binnen
wijzigingsbeheer te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende
handvatten om een eerste inschatting van de status met betrekking tot wijzigingsbeheer te maken.
Worden alle wijzigingsaanvragen geclassificeerd ten aanzien van de volgende aspecten:
o Prioriteit (spoed van de wijziging)
o Complexiteit (impact op de organisatie)
o Doorlooptijd
o Soort ICT-middel (hardware, besturingsprogrammatuur, applicaties, procedures)
Zijn er objectieve criteria vastgelegd op basis waarvan bepaald kan worden in welke categorie
een wijziging thuishoort? Ziet de wijzigingsbeheerder erop toe dat deze criteria juist worden
toegepast?
Zijn er categorieën voor wijzigingen met grote (spoedeisende of urgente wijziging),
substantiële (major wijziging) en geringe gevolgen (standaardwijziging) beschikbaar?
Zijn aan de verschillende categorieën specifieke afhandelingsprocedures gekoppeld?
Bijvoorbeeld standaard 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?
Zijn voor routinematige wijzigingen standaardprocedures en checklists beschikbaar?
Is voor een spoedeisende/urgente wijziging een aparte procedure beschikbaar, waarbij
eventueel het wijzigingsproces achteraf alsnog wordt doorlopen?
2.4 Plannen
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 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 Wijzigingsadviescommissie. Het goedkeuren van de wijziging kan worden
ondersteund door drie basisprocessen:
Financiële goedkeuring: kosten-batenanalyse en budgettering.
Technische goedkeuring: impact, noodzakelijkheid en haalbaarheid.
18
Zakelijke goedkeuring: goedkeuring van de gebruikers betreffende functionaliteitbehoefte en
impact.
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. Bijvoorbeeld: 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’) als het misgaat. Een dergelijke gebundelde uitgifte
moet worden gezien als een enkele wijziging, zelfs als deze uit meerdere aparte wijzigingen is
opgebouwd. Uitgiftes kunnen met een functioneel doel voor de business 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
straat wordt opengebroken’.
Er is vastgelegd wie de prioriteit van wijzigingen bepaalt en wie toestemming verleent voor
realisatie en implementatie. Dit beslissingsforum (de Wijzigingsadviescommissie) voldoet aan de
volgende eisen en de wijzigingscommissie is hiervoor verantwoordelijk:
De leden zijn beslissingsbevoegd.
De Wijzigingsadviescommissie is zodanig samengesteld dat er een evenwicht bestaat tussen de
belangen van de beheer- en exploitatieorganisatie (continuïteit en stabiliteit) 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 wijzigingsbeheerder hun standpunten over wijzigingen in de
Wijzigingsadviescommissie inbrengen, of zijn zelf (al dan niet op ad hoc basis) lid van de
Wijzigingsadviescommissie.
De Wijzigingsadviescommissie kan, in overleg met de ICT-afdelingen, 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 geijkte werktijden (kantooruren). Ook kunnen periodes worden
vastgesteld waarin juist weinig of geen wijzigen worden gepland, zoals binnen de kantooruren of
rond de jaarwisseling.
Inschatten van impact en resources.
Bij het inschatten van de benodigde resources en de impact van de wijziging moet de
Wijzigingsadviescommissie, de wijzigingsbeheerder 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
19
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 activiteit binnen
wijzigingsbeheer te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende
handvatten om een eerste inschatting van de status met betrekking tot wijzigingsbeheer te maken.
Zijn criteria 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?
2.5 Coördineren
Goedgekeurde wijzigingen worden doorgegeven aan de betrokken productspecialisten voor de
bouw en samenstelling van de wijzigingen. 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 wijzigingen dient
afdoende aandacht te worden besteed aan communicatie.
Bouwen
Niet alle wijzigingen 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 wijzigingsbeheersysteem. Deze
registratie is 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.
Wijzigingsbeheer vervult hierbij een coördinerende rol.
Als onderdeel van de oplevering van een wijziging moet ook een back-out-procedure
(terugvalscenario) worden geschreven, om de situatie 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 de wijziging niet
goedkeuren als er geen back-out-procedure is. 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. Afwijkingen van dit principe worden vooraf formeel goedgekeurd, eventueel
achteraf in het geval van spoedeisende wijzigingen. Daarbij moet worden gelet op de criteria van
doeltreffendheid en autorisatie die eerder al door de Wijzigingsadviescommissie 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.
20
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 van 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 zijn 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.
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.
Verder wordt voldaan aan onderstaande criteria:
In verband met controle op kwaadaardige programmatuur vindt installatie en regelmatige
actualisering van antivirusprogramma’s en reparatieprogrammatuur als standaardwijziging
plaats.
Bij wijzigingen in besturingsprogrammatuur worden de eigenaren van toepassingssystemen er
tijdig 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 algemeen bekendgemaakte wijzigingskalender. Afwijkingen van de
planning worden gesignaleerd en geregistreerd.
Bij 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 tijdig geïnformeerd over de implementatie, zodat zij
eventueel rekening kunnen houden met risicoverhogende momenten.
Bewaking
Er wordt voortgangsbewaking uitgeoefend op de afhandeling van (voorgestelde) wijzigingen,
waarbij het prioriteren en de voortgangsbewaking van wijzigingen functioneel zijn gescheiden van
de uitvoering van wijzigingen.
Beoordelen van kwaliteit wijzigingsbeheer
21
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activiteit binnen
wijzigingsbeheer te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende
handvatten om een eerste inschatting van de status 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?
Zijn de toetsingsresultaten geaccordeerd door belanghebbenden?
2.6 Evalueren
Doorgevoerde wijzigingen, met uitzondering van de standaardwijzigingen, worden na een bepaalde
tijd geëvalueerd, 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
Wijzigingsadviescommissievergadering bezien of nog verdere nazorg nodig is. 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?
Is de wijziging een succes en zijn alle activiteiten en registraties voor de wijziging gecontroleerd op
afronding, dan kan het wijzigingsverzoek worden afgesloten. Is de wijziging geen succes, dan
wordt de procesgang hervat op de plaats waar het misgegaan is, met een aangepaste werkwijze.
Beoordelen van kwaliteit wijzigingsbeheer
Onderstaande vragenlijst kan door de gemeente worden gebruikt om deze activiteit binnen
wijzigingsbeheer te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende
handvatten om een eerste inschatting van de status met betrekking tot wijzigingsbeheer te maken.
Zijn criteria vastgesteld om wijzigingen te evalueren?
Vindt deze evaluatie volgens een gestandaardiseerde procedure plaats?
2.7 Uitvoeren van urgente wijzigingen
Ondanks alle planningen kan het voorkomen dat een wijziging voorrang moet krijgen14. Urgente
wijzigingen kenmerken zich door het grote en spoedeisende belang dat aan hun uitvoering wordt
gekoppeld. Meestal moeten voor dergelijke wijzigingen direct resources van andere activiteiten
worden vrijgemaakt. Urgente wijzigingen kunnen ernstige gevolgen hebben voor de dagelijkse
geplande werkzaamheden. Het streven is dan ook om zo min mogelijk urgente of onvoorziene
wijzigingen te laten voorkomen. Daartoe kunnen de volgende maatregelen worden getroffen:
Zorg ervoor dat wijzigingen tijdig worden aangevraagd.
Bij het verhelpen van storingen die het gevolg zijn van een slecht voorbereide wijziging, mag
niet verder worden teruggegaan dan een vorige versie, de zogenaamde Previous Trusted State.
Daarna kan in alle rust een verbeterde herhaling van de wijziging worden voorbereid.
Na de hiervoor genoemde maatregelen kunnen er toch nog urgente wijzigingen optreden. Daarvoor
zijn procedures nodig die een snelle afhandeling mogelijk maken zonder dat wijzigingsbeheer de
controle over het proces verliest. Is er geen tijd, of komt het verzoek buiten kantoortijd binnen,
14 Zie hiervoor ook het operationele product ‘Patch Management voor gemeente’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG).
22
dan moet er een alternatieve manier zijn om de autorisatie te verkrijgen. Dat hoeft niet in de vorm
van een fysieke bijeenkomst te zijn, maar het kan ook gebeuren in de vorm van een telefonische
vergadering.
Het kan ook voorkomen dat er geen tijd is om de normaal vereiste testen uit te voeren. In een
dergelijk geval zal de wijzigingsbeheerder de risico’s moeten afwegen en een beslissing moeten
nemen over de uitvoering van de wijziging. Na afloop dienen alsnog de vereiste stappen van de
reguliere procesgang te worden doorlopen, zodat de eventueel overgeslagen testen alsnog worden
uitgevoerd en de administraties weer bijgewerkt zijn (wijzigingsadministratie en CBDB).
23
3 Afspraken vastleggen
In de dienstenniveauovereenkomst(en) (DNO) 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 wijze 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 wijze 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 wijzigingsbeheerproces 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.
24
4 Prestatie-indicatoren
Prestatie-indicatoren dienen aan te geven in welke mate het proces wijzigingsbeheer slaagt 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 tijdseenheid 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 is uitgevoerd.
Het gerealiseerde budget of het aantal bestede uren aan wijzigingen per periode.
Kosten van uitgevoerde wijzigingen.
25
Bijlage 1: template verzoek tot wijziging
In deze bijlage wordt een template verzoek tot wijziging weergegeven, die gemeenten kunnen
gebruiken om hun eigen wijzigingsformulier te ontwerpen.15 Bij het invullen van het
wijzigingsformulier kan ondersteuning noodzakelijk zijn van de beveiligingsfunctionaris (CISO16),
applicatie-, functioneel- en technisch beheer, gebruikersorganisatie van de gemeente et cetera.
Verzoek tot Wijziging (VTW) Versie 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?
15 Hierbij zijn de BiSL Best Practices voorbeeld wijzigingsformulieren als uitgangspunt gebruikt (http://www.aslbislfoundation.org/nl/bisl/best-practices) 16 Chief Information Security Officer
26
Welke andere configuratie-items komen voor dezelfde wijziging in aanmerking?
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 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:
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) of het College Bescherming Persoonsgegevens (CBP)17?
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 voorstel18: Doe een voorstel voor de prioriteit van het wijzigingsverzoek.
Normaal (0) O Verzoek is 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.
17 http://www.cbpweb.nl/ 18 Aankruisen wat van toepassing is.
27
Bijlage 2: bepalen prioriteit en categorie
Hieronder worden de criteria van risico en impact beschreven op basis waarvan bepaald kan
worden in welke categorie een wijziging 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 is en er
meer dan 10 gebruikers bij betrokken zijn.
4 Als blijkt dat een dienst die een primair proces ondersteund niet beschikbaar is en er
minder dan 10 gebruikers bij betrokken zijn.
Als blijkt dat een dienst die een secundair proces ondersteund niet beschikbaar is en
er meer dan 5 gebruikers bij betrokken zijn.
3 Als blijkt dat een dienst die een secundair proces ondersteund niet beschikbaar is 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 is.
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.
Bepaal de urgentie
Bepaal in overleg met de indiener van het wijzigingsverzoek de urgentie en registreer de bepaalde
urgentiecode op het wijzigingsformulier. Hieronder volgt een voorbeeld van urgentiecodes.
Urgentiecode Omschrijving
5 de wijziging kan geen uitstel verdragen.
4 de wijziging kan een maand uitstel verdragen.
3 de wijziging kan drie maanden uitstel kan verdragen.
2 de wijziging kan meegenomen worden in een volgende te plannen release.
1 de wijziging kan gerealiseerd worden wanneer daar tijd en geld voor beschikbaar zijn.
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 wijziging 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 functionaliteiten vanwege
bedrijfsoverwegingen of een noodwet). Het wijzigingsverzoek moet direct worden uitgevoerd,
het gaat hier om het operationeel belang. Wijzigingen met deze prioriteit vallen onder de
categorie ‘Urgente wijziging’. Urgente wijzigingen wijken af van de normale procedures omdat
28
voor dit type de benodigde resources meteen moeten worden vrijgemaakt. 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 uitgesteld, de bedrijfsvoering komt
in gevaar.
0 Normale/standaard prioriteit: geen grote urgentie of hoge impact, maar een wijziging
mag niet worden uitgesteld tot een later tijdstip. Het wijzigingsverzoek is gewenst.
Impact Urgentie Prioriteit Impact Urgentie Prioriteit
5 5 2 2 5 2
5 4 2 2 4 1
5 3 1 2 3 0
5 2 1 2 2 0
5 1 1 2 1 0
4 5 2 1 5 2
4 4 2 1 4 0
4 3 1 1 3 0
4 2 1 1 2 0
4 1 0 1 1 0
3 5 2
3 4 2
3 3 0
3 2 0
3 1 0
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 wijziging 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 bestaande beleid, dient het
wijzigingsvoorstel goedgekeurd (geautoriseerd) te worden door het management team van
de ICT-afdeling. Na goedkeuring zal de wijziging alsnog aan de Wijzigingscommissie
worden voorgelegd. De noodprocedure wordt gevold.
2 Substantiële gevolgen/Middelgroot: Wijzigingen waarbij flinke inspanningen nodig
zijn, 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
29
worden en geen direct gevaar voor de voortgang opleveren. Er is weinig werk mee
gemoeid en er wordt weinig veranderd. De wijzigingsbeheerder kan dit soort wijzigingen
goedkeuren zonder deze voor te leggen aan de Wijzigingsadviescommissie. De
standaardprocedure wordt gevold.
Afhandelingsprocedures
Aan de verschillende categorieën zijn bij voorkeur specifieke afhandelingsprocedures gekoppeld,
Hieronder zijn voorbeelden van afhandelingsprocedures:
De standaard procedure is bestemd voor wijzigingsvoorstellen die een beperkte impact
hebben en geen direct gevaar voor de voortgang opleveren. Bij de standaard 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 standaardwerkzaamheden.
o Wijzigingsbeheer meldt het wijzigingsvoorstel aan voor de agenda van de
eerstkomende vergadering van de Wijzigingsadviescommissie.
o De Wijzigingsadviescommissie beslist tijdens de vergadering over het
wijzigingsvoorstel.
De hoge prioriteit procedure is 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 Wijzigingsadviescommissie belegd.
Hieronder volgt een opsomming van de afwijkingen voor de verschillende
afhandelingsprocedures.
o Wijzigingsbeheer registreert en beoordeelt het voorstel met voorrang vóór de
standaardwerkzaamheden.
o Wijzigingsbeheer verzoekt om een spoedige vergadering van de
Wijzigingsadviescommissie.
o De Wijzigingsadviescommissie beslist tijdens de vergadering over het
wijzigingsvoorstel.
De nood procedure is 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
standaardwerkzaamheden.
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.
o De Wijzigingsadviescommissie 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.
30
Bijlage 3: definities
Bron: http://www.exin-library.com/Player/eKnowledge/itildutchglossary.pdf
Back-out (terugvalscenario): Een activiteit die een dienst of een ander configuratie-item
terugzet op een eerder uitgangspunt. Back-out wordt gebruikt als 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 tijdens 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. Bijvoorbeeld: kostentypen worden gebruikt om gelijke typen kosten
te groeperen, incidentcategorieën worden gebruikt om gelijke typen incidenten te groeperen, CI-typen worden gebruikt om gelijke typen configuratie-items te groeperen. Configuratiebeheer: Het proces dat verantwoordelijk is 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 is, 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 tijdens hun levenscyclus. Het configuratiebeheersysteem onderhoudt een of meer CBDB's, en elke CBDB slaat 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 zijn levenscyclus door dienstenbedrijfsmiddelen- en configuratiebeheer. Wijzigingsbeheer 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 is 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): 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 wijziging effect heeft op bedrijfsprocessen. Impact is vaak gebaseerd op het effect op dienstenniveaus. Impact en urgentie worden gebruikt op
prioriteit aan te geven. Urgente wijziging / noodwijziging / emergency change: Een wijziging die zo snel mogelijk
moet worden geïntroduceerd. Bijvoorbeeld: om een ernstig incident op te lossen of een
31
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 besloten op het moment dat een vergadering plaatsvindt en is afhankelijk van de aard van de noodwijziging. Normale wijziging / normal change: Een wijziging die geen noodwijziging of standaardwijziging is. Normale wijzigingen volgen de gedefinieerde stappen van het wijzigingsbeheerproces.
Oplosgroep: Een groep mensen met technische vaardigheden. Oplosgroepen leveren technische ondersteuning die nodig is voor alle 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 is 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 standaardwijzigingen dienen wel geregistreerd te worden in het wijzigingsbeheersysteem. 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 wijzigingen omvatten aan hardware, software, documentatie, processen en andere componenten. Releasebeheer / uitgiftemanagement:
Uitgifte- en uitrolbeheer / release- en deployment management: Het proces dat verantwoordelijk is voor planning en controle van de samenstelling, het testen en de uitrol van uitgiftes, en voor het leveren van de nieuwe functionaliteit die vereist is door de bedrijfsvoering. Terwijl 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 bedrijfsvoering 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 storing. Bijvoorbeeld: een beschermde kabel biedt weerstand op het moment dat er druk op wordt uitgeoefend.
Wijziging: De toevoeging, verandering of verwijdering van alles dat een effect kan hebben op ICT-diensten. De scope is gericht op alle wijzigingen 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 Wijzigingsadviescommissie bestaat veelal uit vertegenwoordigers van alle afdelingen binnen de ICT-dienstenaanbieder, het bedrijf en derden (zoals toeleveranciers).
32
Wijzigingsbeheer: Het proces dat verantwoordelijk is 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 wijzigingen 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 wijziging, en kan op papier worden
geregistreerd of elektronisch. De term wijzigingsverzoek wordt vaak verkeerd gebruikt als wijzigingsregistratie of de wijziging zelf.
33
Bijlage 4: 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)
Link: https://www.pvib.nl/links&collectionId=6254637
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
Link:
http://www.norea.nl/readfile.aspx?ContentID=36811&ObjectID=345039&Type=1&File=000002166
1_NoreaPvIBhandreiking.pdf
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
34
INFORMATIEBEVEILIGINGSDIENST V00R GEMEENTEN (IBD)
NASSAULAAN 12 2514 JS DEN HAAG
POSTBUS 30435 2500 GK DEN HAAG HELPDESK 070 373 80 11 ALGEMEEN 070 373 80 08 FAX 070 363 56 82
[email protected] WWW.IBDGEMEENTEN.NL