Change management in de IT-audit: wat de auditor toetst en welk bewijs telt

Bij vrijwel elke IT-audit begint het toetsen van de beheersmaatregelen bij wijzigingsbeheer. Dat is geen toeval. Een applicatie die een rente berekent, een autorisatiematrix afdwingt of een rapport genereert is alleen betrouwbaar als niemand de code, de configuratie of de database ongemerkt kan aanpassen. Kan dat wel, dan kan de auditor op geen enkele geautomatiseerde control steunen en moet hij alles wat de applicatie doet handmatig narekenen. Change management is daarom een van de general IT controls: het fundament waarop de rest van de audit rust.

Dit artikel beschrijft wat een auditor per stap van het wijzigingsproces wil zien, hoe hij controleert of de wijzigingenlijst compleet is, hoe je functiescheiding regelt in een klein DevOps-team, en op welke vier patronen bevindingen ontstaan.

Waar de eis staat

De formulering verschilt per kader, de kern niet. In SOC 2 is het criterium CC8.1: de organisatie autoriseert, ontwerpt, ontwikkelt of verwerft, configureert, documenteert, test, keurt goed en implementeert wijzigingen aan infrastructuur, data, software en procedures. In ISO 27001:2022 is Annex A 8.32 de maatregel voor wijzigingsbeheer, met daaromheen 8.31 (scheiding van ontwikkel-, test- en productieomgevingen), 8.29 (beveiligingstesten bij ontwikkeling en acceptatie), 8.9 (configuratiebeheer) en 8.19 (installatie van software op operationele systemen). Clausule 6.3 van de hoofdtekst gaat over wijzigingen aan het managementsysteem zelf en is iets anders. NEN 7510:2024 volgt dezelfde nummering. Bij een ISAE 3402-rapport schrijft de serviceorganisatie haar eigen beheersingsdoelstellingen, en een doelstelling over geautoriseerde, geteste en goedgekeurde wijzigingen ontbreekt vrijwel nooit. DORA noemt ICT-wijzigingsbeheer in artikel 9 als onderdeel van het ICT-risicobeheerkader. ITIL 4 spreekt sinds 2019 van change enablement en onderscheidt standaard-, normale en noodwijzigingen. Die driedeling komt in de audit terug.

Wat de auditor per stap wil zien

Registratie. Elke wijziging aan productie heeft een vastlegging: een ticket, een pull request, een item in een wijzigingskalender. De vastlegging beschrijft wat er verandert en waarom. De auditor controleert de vorm minder dan de vindbaarheid: kan hij van een willekeurige uitrol terug naar de aanvraag?

Beoordeling en goedkeuring. Iemand anders dan de aanvrager beoordeelt de impact en het risico en keurt goed voordat de wijziging naar productie gaat. Het woord voordat is het toetspunt. De auditor vergelijkt het tijdstip van goedkeuring met het tijdstip van uitrol. Een goedkeuring die na de uitrol is vastgelegd is geen goedkeuring, hoe netjes het ticket er verder ook uitziet. Een change advisory board is voor grote wijzigingen gebruikelijk, maar geen eis; wel moet vastliggen wie mag goedkeuren en voor welk type wijziging.

Testen. De wijziging is getest in een omgeving die niet productie is, tegen acceptatiecriteria die vooraf zijn bepaald, en het resultaat is vastgelegd. "Getest, akkoord" in een ticket zonder iets erachter is geen bewijs. Een pipeline-run met geslaagde tests, een testrapport of een screenshot van de acceptatietest wel.

Uitrol. De persoon die de wijziging heeft ontwikkeld brengt hem niet zelf naar productie, of de uitrol loopt via een pipeline die alleen goedgekeurde code accepteert. Bij een uitrol met risico voor de dienstverlening hoort een terugvalscenario. De auditor vraagt niet alleen of dat bestaat, maar ook of het bij de laatste mislukte uitrol is gebruikt.

Verificatie achteraf. Na de uitrol stelt iemand vast dat de wijziging doet wat was bedoeld en dat er niets anders is meegekomen. Bij wijzigingen aan de infrastructuur is dat vaak een controle van de configuratie tegen de beoogde staat.

De volledigheid van de lijst is het echte onderwerp

Bijna elke organisatie kan een stapel goedgekeurde tickets laten zien. De auditor begint daar niet. Hij vraagt de complete lijst van alles wat in de periode naar productie is gegaan, en hij wil die lijst uit een bron die de ontwikkelaars niet zelf kunnen bewerken: de deploymenthistorie van de pipeline, de releaselog van het platform, de wijzigingslog van de cloudomgeving. Uit die lijst trekt hij zijn steekproef, bij een control die dagelijks of vaker werkt in de praktijk vaak in de orde van vijfentwintig wijzigingen over een periode van een jaar. Per wijziging wil hij vervolgens de aanvraag, de goedkeuring vooraf, het testbewijs en de identiteit van de uitvoerder zien.

De reconciliatie tussen die deploymentlijst en het ticketsysteem is waar het misgaat. Handmatige wijzigingen, hotfixes, wijzigingen door een leverancier en aanpassingen rechtstreeks in de database staan wel in de eerste lijst en niet in de tweede. Elke uitrol zonder bijbehorend ticket is een afwijking, en één ongeautoriseerde wijziging aan een kritiek systeem is genoeg om de control als niet-effectief te beoordelen. Hoe die reconciliatie past in de bredere bewijslast staat in bewijs in een IT-audit.

Doe die vergelijking dus zelf, voordat de auditor komt. Trek de deploymentlijst, zet hem naast de tickets en verklaar elk verschil. Wat je niet kunt verklaren, is precies wat de auditor gaat vinden.

Functiescheiding in een klein DevOps-team

De klassieke eis luidt dat ontwikkelen, goedkeuren en uitrollen bij verschillende personen liggen. In een team van drie is dat niet als vaste rolverdeling te organiseren, en dat hoeft ook niet. De scheiding zit per wijziging: de auteur van de code keurt zijn eigen pull request niet goed, en de uitrol gebeurt door de pipeline en niet door een ontwikkelaar met rechtstreekse toegang tot productie.

De auditor toetst dat op drie punten. Ten eerste de branchbeveiliging: verplichte review door minimaal één ander, geen force push naar de hoofdtak, en geen uitzondering voor beheerders. Ten tweede de toegang tot productie: hebben ontwikkelaars accounts waarmee ze buiten de pipeline om kunnen uitrollen of de database kunnen aanpassen? Dat raakt direct aan toegangsbeheer, en het is de vraag waar kleine teams het vaakst op vastlopen. Ten derde de werking door de tijd: stond de branchbeveiliging de hele periode aan, of is hij een keer tijdelijk uitgezet voor een lastige merge? De audit log van het versiebeheersysteem laat dat zien.

Lukt de scheiding vooraf niet volledig, dan is een detectieve control het alternatief. Iemand anders dan de ontwikkelaar beoordeelt periodiek de deploymentlijst, stelt vast dat elke uitrol een goedgekeurde wijziging is en legt die beoordeling vast met datum en naam. Dat is een volwaardige compenserende maatregel, mits de beoordelingen aantoonbaar hebben plaatsgevonden. Een procedure die dat beschrijft zonder dat er ooit een beoordeling is vastgelegd, telt niet.

Infrastructuur als code valt onder dezelfde regels. Een aanpassing aan een Terraform-bestand of een Kubernetes-manifest is een wijziging aan productie en doorloopt hetzelfde proces als applicatiecode. Configuratiewijzigingen die iemand rechtstreeks in de console van de cloudleverancier doorvoert, zijn de handmatige wijzigingen waar de reconciliatie hierboven over gaat.

Standaardwijzigingen en noodwijzigingen

Niet elke wijziging hoeft afzonderlijk te worden goedgekeurd. Een standaardwijziging is vooraf goedgekeurd als type: een routinematige patch, het aanmaken van een gebruiker volgens een vaste procedure, een wijziging in een parameter binnen vastgestelde grenzen. De auditor wil dan de catalogus zien waarin staat welke wijzigingen standaard zijn, wie die catalogus heeft goedgekeurd en wanneer hij voor het laatst is beoordeeld. Een catalogus die in de loop van de jaren is gegroeid tot vrijwel alles standaard is, holt de control uit.

Noodwijzigingen doorbreken de volgorde: eerst uitrollen, dan goedkeuren. Dat is toegestaan als de procedure daarvoor bestaat, de goedkeuring achteraf binnen een vastgestelde termijn plaatsvindt en de noodwijziging in dezelfde lijst staat als alle andere wijzigingen. De auditor kijkt daarnaast naar het aandeel. Een organisatie waar een derde van de wijzigingen via de noodprocedure gaat, gebruikt de noodprocedure als omweg om het reguliere proces heen.

Wijzigingen bij leveranciers

Voor een SaaS-toepassing beheer je het wijzigingsproces niet zelf. Je steunt dan op het assurancerapport van de leverancier, en de vraag is of change management in de scope van dat rapport zit en of er uitzonderingen op zijn gerapporteerd. Lees daarbij de complementary user entity controls. Veel leveranciers verwachten dat de klant nieuwe releases in een acceptatieomgeving test of expliciet accepteert voordat ze actief worden. Dat deel van het proces is dan jouw control, en de auditor vraagt er bewijs van bij jou, niet bij de leverancier.

Vier patronen waarop bevindingen ontstaan

Het eerste patroon is goedkeuring na uitrol. Het ticket is compleet, de reviewer heeft getekend, maar het tijdstip ligt na de deployment. Dit gebeurt vooral bij teams die het proces zien als documentatie achteraf in plaats van als voorwaarde vooraf.

Het tweede is een ticketsysteem dat niet alles bevat. Hotfixes gaan via de chat, een leverancier past iets aan na een telefoontje, een beheerder wijzigt een instelling in de console. De deploymentlijst laat het zien, het ticketsysteem niet.

Het derde is testbewijs dat uit één woord bestaat. "Getest" in een veld, zonder testresultaat, zonder criteria, zonder wie het heeft gedaan. Bij een Type II-onderzoek over een observatieperiode van een jaar is dat niet achteraf te repareren.

Het vierde is beheerderstoegang die de pipeline omzeilt. De branchbeveiliging staat aan, maar drie mensen hebben een rol waarmee ze rechtstreeks naar productie kunnen. De auditor vraagt dan of die toegang in de periode is gebruikt, en het logboek geeft het antwoord.

Wat je vooraf kunt doen

Trek de deploymentlijst over de afgelopen drie maanden uit de pipeline en leg hem naast het ticketsysteem. Controleer bij tien willekeurige wijzigingen of de goedkeuring vóór de uitrol ligt en of het testbewijs meer is dan een vinkje. Kijk in het versiebeheersysteem of de branchbeveiliging in die periode is gewijzigd. Inventariseer wie buiten de pipeline om naar productie kan. Wat daaruit komt, is de werkvoorraad voor de maanden voor de audit. Hoe Secure Audit change management toetst als onderdeel van een bredere beoordeling staat op de pagina over de IT-audit.