Beleid wijzigingsbeheer

Onderdeel van Beleidsset informatiebeveiliging op BIO 2.0, op maat gemaakt met contextvragen · Markdown-bron

Word nodig? Kies dit stuk in de generator en download het daar, zonder of met je eigen antwoorden.

In het kort. Regelt hoe een wijziging in productie wordt aangevraagd, beoordeeld, getest, goedgekeurd en doorgevoerd. Behandelt het wijzigingsproces met standaard-, normale en spoedwijzigingen, werkinstructies voor beheertaken, het installeren van software, de scheiding van omgevingen en acceptatietesten.

Onderwerpen. 3. Het wijzigingsproces; 4. Bedieningsprocedures; 5. Software installeren; 6. Scheiding van omgevingen; 7. Testen en acceptatie.

Zonder profiel: tekst die van een contextvraag afhangt, staat in een kader met de vraag erboven.

1. Doel en reikwijdte#

Dit beleid werkt het strategisch informatiebeveiligingsbeleid uit voor wijzigingen in informatiesystemen, infrastructuur, software en configuratie in de productieomgeving. Het regelt hoe een wijziging wordt aangevraagd, beoordeeld, getest, goedgekeurd en doorgevoerd, hoe omgevingen gescheiden zijn, hoe beheertaken zijn beschreven en wie software mag installeren, zodat een wijziging de beschikbaarheid, integriteit en vertrouwelijkheid van informatie niet onbedoeld aantast. Het gaat over de ISO-beheersmaatregelen 5.37, 8.19, 8.29, 8.31, 8.32 en 8.33.

Voor wie. Het beleid is primair bedoeld voor de beheerorganisatie, de wijzigingsmanager, functioneel beheer en de systeem- en proceseigenaren. Het geldt ook voor leveranciers die wijzigingen doorvoeren op systemen van de organisatie en voor iedereen die software op een apparaat van de organisatie wil installeren.

Waarop. Alle systemen, netwerken, clouddiensten en werkplekken waarmee de organisatie informatie verwerkt, en de ontwikkel-, test- en acceptatieomgevingen die daarbij horen. Is het beheer uitbesteed, dan gelden de eisen uit dit beleid als minimumeis voor de leverancier. De organisatie legt dat vast in het contract en toetst de naleving met een onafhankelijke verklaring, zoals een ISO 27001-certificaat of een ISAE 3402- of ISAE 3000-rapport; het vastleggen loopt via het beleid informatiebeveiliging bij inkoop, het toetsen via het beleid contractbeheer.

Buiten dit beleid vallen de eisen aan het bouwen van software en de regels voor testgegevens (beleid veilige softwareontwikkeling; de regel over testgegevens staat hier verkort herhaald), de termijnen voor het verhelpen van kwetsbaarheden (beleid kwetsbaarheden en patchmanagement; het doorvoeren van een patch loopt wel via dit proces, als standaardwijziging) en de rechten in productie (beleid logische toegangsbeveiliging).

Alleen als: Wie beheert je IT? «Regie: eigen organisatie stuurt, beheer is uitbesteed»

De organisatie stuurt, een leverancier voert het beheer uit. Het wijzigingsproces van de leverancier is leidend voor de uitvoering; de organisatie houdt de goedkeuring van wijzigingen met gevolgen voor haar processen of informatie en legt dit beleid als eis in het contract.

Alleen als: Wie beheert je IT? «Volledig uitbesteed»

Het beheer is volledig uitbesteed. De leverancier voert wijzigingsbeheer uit volgens dit beleid, zoals vastgelegd in het contract. De organisatie keurt wijzigingen goed die haar processen of informatie raken en ontvangt elke maand een overzicht van alle doorgevoerde wijzigingen.

2. Uitgangspunten#

1. Elke wijziging in productie is vastgelegd, beoordeeld en goedgekeurd voordat hij wordt doorgevoerd. Spoedwijzigingen worden achteraf binnen vijf werkdagen beoordeeld. #
2. Er wordt niet getest in productie. #
3. Elke wijziging heeft een weg terug. #
4. Hoe groter het risico van een wijziging, hoe zwaarder de beoordeling en de goedkeuring. Het impactniveau van de betrokken informatie weegt daarin mee. #
5. Terugkerend beheerwerk staat beschreven, zodat het niet van één persoon afhangt en elke uitvoerder het op dezelfde manier doet. #
6. Termijnen en frequenties in dit beleid die niet uit een wet of uit de BIO 2.0 komen, zijn standaardwaarden. De organisatie past ze aan op haar eigen risicoafweging en legt de keuze vast bij de vaststelling van dit beleid. #

3. Het wijzigingsproces#

1. [lijneigenaar wijzigingsbeheer] richt wijzigingsbeheer in volgens een algemeen geaccepteerd beheerraamwerk, bijvoorbeeld ITIL of ISO/IEC 20000 voor technisch beheer en BiSL voor functioneel beheer, en legt vast welk raamwerk geldt en welke processtappen daaruit volgen. [8.32.02] #
2. Elke wijziging staat in [wijzigingsregister] met: omschrijving, aanvrager, betrokken systemen, risicoklasse, testplan en testresultaten, rollbackplan, besluit en datum van doorvoeren. De wijzigingsmanager bewaakt dat geen wijziging buiten het register om gaat. [8.32.01] #
3. Elke wijziging krijgt van de aanvrager een risicoafweging van de mogelijke gevolgen voor beschikbaarheid, integriteit en vertrouwelijkheid, met een beschreven plan om terug te gaan naar de vorige situatie (rollback). [8.32.01] #
4. Wijzigingen vallen in drie soorten, elk met een eigen goedkeuring: [8.32.01] - standaardwijzigingen: vooraf beoordeelde, terugkerende wijzigingen met laag risico (zoals reguliere updates en patches), als type goedgekeurd door het wijzigingsoverleg en uitgevoerd volgens een vast draaiboek; - normale wijzigingen: beoordeeld en goedgekeurd door het wijzigingsoverleg (CAB), met de systeemeigenaar en, bij een hoog risico of informatie met impactniveau kritiek of hoger, advies van de CISO; - spoedwijzigingen: goedgekeurd door [spoedgoedkeurder] en achteraf binnen vijf werkdagen in het wijzigingsoverleg beoordeeld. #
5. Na het doorvoeren controleert de uitvoerder of de wijziging werkt zoals bedoeld en sluit hij de wijziging pas af na die controle, met het resultaat in het register. Een mislukte wijziging draait de uitvoerder terug volgens het rollbackplan en meldt hij aan de wijzigingsmanager. [8.32.01] #
6. Wijzigingen door leveranciers op systemen van de organisatie lopen via hetzelfde register en dezelfde goedkeuring, ook als de leverancier eigen accounts gebruikt. [8.32.01] #
7. De wijzigingsmanager rapporteert maandelijks aan de lijneigenaar het aantal wijzigingen per soort, de mislukte en teruggedraaide wijzigingen en de spoedwijzigingen met hun beoordeling achteraf. [8.32.01] #

Alleen als: Wie beheert je IT? «Eigen beheer»

8. Het wijzigingsoverleg komt ten minste wekelijks bijeen, onder voorzitterschap van de wijzigingsmanager van de eigen IT-afdeling, en legt zijn besluiten vast in het register. De uitvoerder van een wijziging keurt zijn eigen wijziging niet goed. [8.32.01] #

Alleen als: Wie beheert je IT? «Regie: eigen organisatie stuurt, beheer is uitbesteed» of «Volledig uitbesteed»

9. In het contract staat welke wijzigingen de leverancier zelf mag goedkeuren (standaardwijzigingen) en welke de organisatie vooraf goedkeurt. De organisatie heeft een vaste vertegenwoordiger in het wijzigingsoverleg van de leverancier. Het wijzigingsregister van de leverancier is voor de organisatie in te zien en de contracteigenaar toetst het jaarlijks aan dit beleid. [8.32.01, 8.32.02] #

4. Bedieningsprocedures#

1. Voor terugkerende beheertaken (starten en stoppen van systemen, back-up en herstel, standaardwijzigingen, verwerken van batches, afhandelen van storingen en meldingen, onderhoud en opschonen van logging) legt de beheerorganisatie werkinstructies vast in [beheerdocumentatie]. [5.37.01] #
2. Een werkinstructie beschrijft ten minste: wie de taak uitvoert, de stappen in volgorde, de afhankelijkheden van andere systemen, wat te doen bij een fout, wie te waarschuwen en waar de uitkomst wordt vastgelegd. [5.37.01] #
3. De werkinstructies zijn beschikbaar voor wie ze nodig heeft en voor niemand anders. De eigenaar van het systeem of de dienst werkt ze bij na elke wijziging die de taak raakt en beoordeelt ze ten minste jaarlijks op actualiteit; een wijziging van een werkinstructie wordt als wijziging goedgekeurd. [5.37.01] #

Alleen als: Wie beheert je IT? «Regie: eigen organisatie stuurt, beheer is uitbesteed» of «Volledig uitbesteed»

4. De leverancier houdt de werkinstructies voor de uitbestede taken bij; de organisatie heeft inzage in de instructies die haar systemen raken en in de instructies voor herstel na een storing. [5.37.01] #

5. Software installeren#

1. Gebruikers hebben geen lokale beheerrechten op hun werkplek. Software komt alleen op werkplekken en servers via de softwarecatalogus of een goedgekeurde wijziging, geïnstalleerd door de beheerorganisatie of door een geautomatiseerde uitrol onder haar beheer. [8.19.01] #
2. De beheerorganisatie houdt een lijst bij van toegestane software, met per product de versie die in gebruik mag zijn. Het installeren of uitvoeren van software buiten die lijst wordt technisch tegengehouden, bijvoorbeeld met applicatiewhitelisting, of minstens gedetecteerd en binnen [termijn verwijderen software] verwijderd. [8.19.01] #
3. Een verzoek om nieuwe software toetst de beheerorganisatie op leverancier, licentie, beveiliging en privacy voordat de software in de catalogus komt; de CISO adviseert bij software die toegang krijgt tot informatie met impactniveau kritiek of hoger. [8.19.01] #
4. Van software op servers en werkplekken bewaart de beheerorganisatie de vorige versie zolang die nodig is om terug te kunnen, en verwijdert zij versies die de leverancier niet meer ondersteunt volgens het beleid kwetsbaarheden en patchmanagement. [8.19.01] #

6. Scheiding van omgevingen#

1. Ontwikkeling, test, acceptatie en productie zijn gescheiden omgevingen, met eigen accounts en rechten, zodat een fout of een aanval in de ene omgeving de andere niet raakt. Voor een systeem zonder eigen test- of acceptatieomgeving legt de systeemeigenaar vast hoe wijzigingen wel vooraf worden getest. [8.31.01] #
2. In de productieomgeving wordt niet getest. Is een test in productie onvermijdelijk, dan keurt de proceseigenaar die vooraf schriftelijk goed, met de omvang, het tijdvak en de maatregelen om schade te voorkomen; de goedkeuring hoort bij de wijziging in het register. [8.31.01] #
3. Significante wijzigingen worden getest in een omgeving buiten productie voordat ze in productie gaan. Afwijken kan alleen met voorafgaande goedkeuring van de proceseigenaar, die het risico vastlegt. [8.31.02] #
4. Ontwikkel- en testomgevingen zijn herkenbaar als zodanig, bijvoorbeeld in de naam en op het scherm, en hebben geen koppeling naar productiesystemen van andere organisaties zonder goedkeuring van de systeemeigenaar. [8.31.01] #
5. Testgegevens volgen de regels in het beleid veilige softwareontwikkeling: fictieve gegevens, en persoonsgegevens alleen als onderbouwde uitzondering met advies van de privacy officer en de CISO. De systeemeigenaar legt bij elke acceptatietest vast welke gegevens zijn gebruikt. [8.33.01] #
6. Zijn in een testomgeving toch productiegegevens gebruikt, dan heeft die omgeving dezelfde beveiliging als productie en verwijdert de beheerorganisatie de gegevens direct na de test; het verwijderen staat in het register bij de wijziging. [8.33.01] #

7. Testen en acceptatie#

1. Acceptatietesten volgen een vaste testmethode: een testplan met testgevallen afgeleid van de functionele eisen en de beveiligingseisen, uitgevoerd door of namens de systeemeigenaar. Bij een wijziging met een hoog risico of aan een internetbereikbaar systeem bevat het testplan ook een beveiligingstest, zoals een controle van de instellingen of een penetratietest. [8.29.01] #
2. Tests die vaker terugkomen (regressietests, controles op beveiligingsinstellingen) automatiseert de beheerorganisatie waar het kan, en de uitkomst wordt bij de wijziging bewaard. [8.29.01] #
3. Van elke acceptatietest maakt de tester een verslag met de uitgevoerde tests, de resultaten, de openstaande bevindingen en het besluit tot acceptatie door de systeemeigenaar. Het verslag hoort bij de wijziging in het register. [8.29.01] #

Alleen als: Bouwt je organisatie zelf software, apps of koppelingen? «Ja»

4. Voor eigen software voert de bouwstraat bij elke wijziging automatisch unit-, integratie- en beveiligingstests uit. Uitrol naar productie gebeurt alleen via de bouwstraat, na goedkeuring in het wijzigingsregister; ontwikkelaars hebben geen schrijfrechten in productie. [8.29.01, 8.31.01, 8.32.01] #

Alleen als: Bouwt je organisatie zelf software, apps of koppelingen? «Nee, alleen inkoop en configuratie»

5. Bij een nieuwe versie van een leverancier test de organisatie zelf in de acceptatieomgeving de eigen processen, koppelingen en autorisaties, naast het testverslag van de leverancier, voordat de systeemeigenaar de versie accepteert. [8.29.01, 8.31.02] #

8. Rollen en verantwoordelijkheden#

9. Naleving en controle#

Controleraamwerk. De naleving van dit beleid wordt met de volgende controles aangetoond. De uitkomst en het bewijs worden vastgelegd in [registratie van controles]; afwijkingen gaan als bevinding naar het risicoregister.

Afwijkingen. Afwijken van een eis kan alleen op basis van een gedocumenteerde risicoafweging. De systeemeigenaar dient het verzoek in bij de CISO, met de reden, de compenserende maatregelen en de looptijd. De afwijking geldt pas na acceptatie van het risico door [risico-eigenaar] en staat in het risicoregister; afwijkingen worden ten minste jaarlijks opnieuw beoordeeld.

Niet naleven. Het niet naleven van dit beleid wordt behandeld als beveiligingsincident en kan leiden tot het intrekken van toegangsrechten of tot maatregelen volgens de rechtspositieregeling of het contract.

10. Samenhang#

Dit beleid valt onder het strategisch informatiebeveiligingsbeleid. Het raakt het beleid veilige softwareontwikkeling (testgegevens, bouwstraat en acceptatie van opleveringen), het beleid kwetsbaarheden en patchmanagement (patches als standaardwijziging, configuratiebeheer en software zonder updates), het beleid informatieclassificatie (impactniveau als maat voor de zwaarte van de beoordeling), het beleid informatiebeveiliging bij inkoop en contractbeheer (afspraken over wijzigingen door leveranciers), het beleid back-up en recovery (werkinstructies voor back-up en herstel) en het beleid logische toegangsbeveiliging (rechten in productie en in de beheerdocumentatie).

Bijlage A: BIO 2.0-maatregelen#

De maatregelen van dit domein (8, waarvan 6 overheidsmaatregelen), waar dit stuk ze invult en welke controle ze aantoont. Nummers volgens BIO2 v1.3 definitief - 9 januari 2026; de tekst van de maatregel staat bij het CIP. Waar de BIO 2.0 geen overheidsmaatregel kent, geldt de ISO 27002-beheersmaatregel.

Bijlage B: Afkortingen#

Nog in te vullen#

• lijneigenaar wijzigingsbeheer: de manager die dit beleid uitvoert, bijvoorbeeld het hoofd IT
• wijzigingsregister: het systeem waarin wijzigingen worden vastgelegd, bijvoorbeeld het ticketsysteem
• spoedgoedkeurder: de functie die buiten het overleg mag goedkeuren, bijvoorbeeld de dienstdoende IT-manager
• beheerdocumentatie: de plek waar werkinstructies staan, bijvoorbeeld de kennisbank van de beheerorganisatie
• termijn verwijderen software: bijvoorbeeld vijf werkdagen
• beheerorganisatie: de eigen afdeling of de leverancier die de systemen beheert
• registratie van controles
• risico-eigenaar: de manager die restrisico's accepteert
• eigenaar van dit beleid: de manager die dit beleid uitvoert en laat naleven
• vaststeller: wie het beleid vaststelt, bijvoorbeeld de directie of het bestuur