Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van...

33
Handreiking Proces wijzigingsbeheer Een operationeel kennisproduct ter ondersteuning van de implementatie van de Baseline Informatiebeveiliging Overheid (BIO)

Transcript of Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van...

Page 1: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

Handreiking

Proces wijzigingsbeheer

Een operationeel kennisproduct ter ondersteuning van de implementatie van de Baseline Informatiebeveiliging Overheid (BIO)

Page 2: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 3: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 4: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 5: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 6: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 7: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 8: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 9: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 10: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 11: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 12: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 13: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 14: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 15: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 16: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 17: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 18: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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:

Page 19: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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’

Page 20: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 21: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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?

Page 22: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 23: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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)

Page 24: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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?

Page 25: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 26: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 27: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 28: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 29: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 30: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 31: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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.

Page 32: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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

Page 33: Proces wijzigingsbeheer - Informatiebeveiligingsdienst · De impact van de wijzigingen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

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)

[email protected] / [email protected]