Een Change Advisory Board (CAB) is het overleg dat jouw voorgestelde wijzigingen aan IT-systemen beoordeelt en beslist of een wijziging veilig door kan. De CAB weegt risico, impact, timing en of de wijziging terug te draaien is, en keurt vervolgens goed, stelt uit of wijst af.
Formeel adviseert het overleg; autoriseren doet de aangewezen change authority. In de meeste organisaties zijn dat dezelfde mensen, dus is "goedkeuring door de CAB" de gangbare verkorting, en zo gebruikt deze pagina het ook.
Rollen en verantwoordelijkheden in een CAB
Houd een CAB multidisciplinair: niemand overziet in zijn eentje alle gevolgen van een wijziging. Is je organisatie klein, laat het overleg dan draaien met drie of vier mensen die meerdere van deze petten tegelijk dragen. De verantwoordelijkheden wegen zwaarder dan de bezetting.
| Rol | Verantwoordelijkheid |
|---|---|
| Change manager (voorzitter) | Eigenaar van het proces, stelt de agenda op en legt het besluit vast. Autoriseert wijzigingen niet eigenhandig. |
| Service- of applicatie-eigenaar | Bevestigt dat de business de wijziging nú aankan, en weet waar het systeem voor dient en wie eronder lijdt als het stilvalt. |
| Infrastructuur- of platformengineer | Beoordeelt hoe ver de technische gevolgen reiken en welke afhankelijkheden er zijn, en toetst of het rollbackplan realistisch is. |
| Security-vertegenwoordiger | Stelt vast of de wijziging het aanvalsoppervlak, het toegangsmodel of de gegevensstromen verandert. |
| Operations of servicedesk | Signaleert samenloop met ander werk, freeze-periodes en de supportcapaciteit rond de uitrol. |
| Vertegenwoordiger vanuit de business | Gaat akkoord met wijzigingen die klantgerichte diensten, contractuele afspraken of gereguleerde processen raken. |
Welke wijzigingen moeten langs het CAB-overleg?
Niet elke wijziging hoort op de agenda. ITIL onderscheidt drie soorten, en juist die scheiding voorkomt dat je CAB-overleg een knelpunt wordt.
Over de terminologie: de vaste CAB en de ECAB verderop zijn ITIL v3-termen die de meeste organisaties nog steeds gebruiken. ITIL 4 noemt deze practice change enablement en wijst per soort wijziging een change authority aan, met de waarschuwing dat één centraal overleg voor alles vertraging oplevert. De driedeling blijft in ITIL 4 ongewijzigd.
| Soort wijziging | Route |
|---|---|
| Standaard | Vooraf goedgekeurd en laag risico, volgens een vastgelegde werkwijze. Gaat niet langs de CAB: de goedkeuring is eenmalig op de werkwijze gegeven. |
| Normaal | Volledige beoordeling vóór uitrol door de aangewezen change authority, in de meeste organisaties het CAB-overleg. Het uitgangspunt voor alles wat architectuur, toegang of gegevens raakt. |
| Spoed | Afgehandeld door een verkorte spoed-CAB (ECAB, in ITIL v3-taal). Autorisatie hoort waar mogelijk nog steeds vooraf te gebeuren; de vastlegging wordt daarna afgerond. |
Hoe je met een CAB aantoont dat je aan ISO 27001 en SOC 2 voldoet
ISO 27001:2022 vraagt om wijzigingsbeheer in Annex A 8.32: wijzigingen aan informatieverwerkende faciliteiten en systemen moeten onderworpen zijn aan procedures voor wijzigingsbeheer. De norm schrijft geen commissie voor; die schrijft voor dat wijzigingen worden beoordeeld, geautoriseerd en vastgelegd. Een CAB is daarvoor de gebruikelijke invulling.
SOC 2 dekt hetzelfde af in criterium CC8.1: de organisatie moet wijzigingen aan infrastructuur, gegevens, software en procedures autoriseren, ontwerpen, ontwikkelen of aanschaffen, configureren, vastleggen, testen, goedkeuren en doorvoeren om haar doelstellingen te halen. Auditors trekken daarbij een steekproef van wijzigingen van begin tot eind na.
Wat een auditor wil zien
In de praktijk is de vraag smal en concreet. Voor een steekproef van wijzigingen laat je zien: de vastlegging met aanvrager en goedkeurder, de risico- en impactafweging, testbewijs, een rollbackplan, en een traceerbare lijn van het ticket naar de uitrol die daadwerkelijk heeft plaatsgevonden.
Voor spoedwijzigingen hoort daar ook de goedkeuring achteraf bij. Een spoedroute zonder papieren spoor is een bevinding.
Veelgemaakte fouten
Het probleem is zelden het ontbreken van een CAB, maar een CAB die alleen maar afstempelt. Als er nooit iets wordt afgewezen of uitgesteld, legt je overleg besluiten vast in plaats van ze te nemen, en dat valt een auditor op.
Daar vlak achteraan komt het ontbreken van een catalogus met standaardwijzigingen. Routinewerk belandt in de wachtrij van het overleg, teams gaan er via de spoedroute omheen werken, en zo wordt "spoed" de meest voorkomende wijzigingssoort in je wijzigingsregister.
De derde is goedkeuren in een chatbericht. Een besluit dat niemand een half jaar later kan terugvinden, heeft voor een audit niet plaatsgevonden.