Waarom IAM-projecten falen op governance, niet op techniek.

Ik kom regelmatig binnen bij IAM trajecten waar de techniek prima op orde is. De IGA tool draait, de connectoren werken, er staat een rolmodel of RBAC op papier. En toch is er na anderhalf jaar nog niets aantoonbaar geregeld. Geen access reviews die echt landen, geen JML flows die de business vertrouwt, geen audit waar ze met droge ogen doorheen komen.

Dan kijk je naar wie er bij betrokken zijn. Een sterke IAM architect van de leverancier, een IGA consultant, een paar interne specialisten. Allemaal capabel. Wat er ontbreekt is iemand die het programma als geheel draagt. En die niet zelf in het rolmodel of de SoD matrix gaat zitten knutselen, want dan ben je een week later weer geen PM.

IAM is geen project. Het is een programma. En een programma vraagt iemand anders dan een projectleider.

Waarom IAM-programma’s anders zijn dan traditionele IT-projecten

Drie kenmerken trekken Identity & Access Management uit de projectsfeer.

Eén, er lopen meerdere workstreams parallel op People, Process en Technology. Techniek, processen, governance, communicatie, adoptie. Eén Gantt en één deliverable past daar niet op.

Twee, doorlooptijd 12 tot 24 maanden. Korter is zelden realistisch boven de 500 medewerkers. Langer betekent dat je programma onderweg politiek moet kunnen overleven.

Drie, resultaten zijn cumulatief, niet “klaar”. Een IAM programma stopt niet. Het ontwikkelt zich door naar een blijvende governance functie. De vraag is niet wanneer je klaar bent, maar wanneer je overdraagt.

De rolverdeling die telt

Iets wat ik te vaak hoor: de programma manager regelt het wel. Inclusief de inhoud. Dat klopt niet. Een PM die op de inhoud gaat zitten is binnen drie maanden geen PM meer.

Inhoud is consultants. Doorgaans drie, soms vier. En vaak ook nog per werkstroom aangestuurd door project managers.

De technische IAM consultants. IAM-architect ontwerpt de doelarchitectuur. IGA consultant ontwerpt rolstructuur en reviewproces. SoD specialist bouwt de matrix voor de grote systemen zoals SAP. PAM consultant richt CyberArk of BeyondTrust in.

Een change-consultant. Communicatie, training, adoptie, ADKAR uitwerking, stakeholdermap. IAM is een verandering in People én Process, niet alleen Technology, en dat stuk gaat niet vanzelf.

En in sommige organisaties een business- of process-architect die de rolstructuur tegen de inrichting houdt. Niet altijd nodig. Wel handig als de processen rommelig zijn.

De PM doet iets anders. Geen inhoud. Wel sturing. Concreet: scope, budget en tijd. Het team aansturen. Knopen doorhakken op basis van wat specialisten op tafel leggen. Rapporteren naar stuurgroep en directie. En de juiste mensen in de organisatie verbinden met de juiste consultants, zodat die consultants ook echt hun werk kunnen doen.

“De beste PM voor IAM is iemand die IAM goed kent en er vervolgens bewust niet aan komt.”

En dat is meteen waarom die PM-rol los moet staan van de leverancier. Een PM in dienst van de IGA leverancier heeft een ingebouwd belangenconflict bij elke scope discussie. Onafhankelijk neem je geen positie in op tool of ontwerp, en kan je regie voeren tussen klant, leverancier en interne teams. Klinkt simpel. Is het in de praktijk niet.

Toolselectie en RfP: begin niet met een demo

Veel IAM-trajecten ontsporen al vóór de implementatie. Niet bij de bouw, maar bij de toolkeuze. Organisaties starten met een longlist van leveranciers en een serie demo’s, terwijl de probleemanalyse nog niet eens af is. Dan wordt de demo leidend voordat duidelijk is welke governanceproblemen eigenlijk opgelost moeten worden.

In een typische enterprise spelen meerdere identity-platforms een rol. IGA (Identity Governance & Administration) voor lifecycle en access reviews. PAM (Privileged Access Management) voor admin-accounts en privileged sessions. De centrale IdP voor authenticatie en federatie is in vrijwel elke Nederlandse enterprise inmiddels Entra ID, simpelweg omdat de organisatie al op M365 draait. En in toenemende mate CIEM voor cloud-rechten. Veel RfP’s vergelijken die platforms op featurelijsten alsof het functioneel gelijkwaardige producten zijn. Dat zijn ze niet, en daar gaan trajecten al onderuit.

De echte selectievraag in een RfP draait om IGA en PAM, en steeds vaker om hoe die twee samenwerken met de Entra ID-controls die er al staan: Conditional Access, Privileged Identity Management (PIM), Entitlement Management. Wie dat onderscheid niet maakt vergelijkt drie verschillende productcategorieën onder één paraplu en stelt zichzelf bovendien de verkeerde vraag.

Wat ik in leveranciers selectie vrijwel altijd terugzie: scorecards die vele features wegen zonder weging op organisatorische volwassenheid. Gartner’s Magic Quadrant for IGA en Forrester’s Wave for Identity Management worden vaak als selectiebasis gebruikt, logisch, want het zijn de meest gestructureerde marktoverzichten. Maar beide rapporten beoordelen leveranciers op productvolwassenheid. Niet op of jouw organisatie de volwassenheid heeft om er waarde uit te halen. Een SailPoint, Saviynt of Omada krijgt dezelfde score op “supports access reviews”, terwijl de echte vraag is of jouw applicatie-eigenaren überhaupt zinvol kunnen reviewen. Die vraag staat zelden in de RfP.

“Een enterprise-grade IGA-platform lost geen organisatie op waarin applicatie-eigenaarschap niet bestaat.”

Een slechte toolkeuze is zelden technisch verkeerd. Veel vaker past de volwassenheid van de organisatie niet bij de volwassenheid van de tool. Een platform dat bij een ander bedrijf prachtig werkt, kan bij jou de boel verlammen omdat de fundamenten ontbreken. Dat is geen tooling-fout. Dat is een selectie-fout.

Een variant van hetzelfde patroon zie je inmiddels rond AI-tooling. Afdelingen gaan zelfstandig met agents en assistants aan de slag, buiten de centrale governance om, en de organisatie ontdekt achteraf dat er een tweede schaduw-IT-laag is ontstaan met andere regels. Daar schreef ik eerder over in Shadow AI is geen schaduw-IT probleem maar een governanceprobleem. De parallel met de tool-first reflex bij IAM is groter dan je zou denken.

De rol van de programma manager in deze fase: zorgen dat de probleemanalyse vóór de demo komt. Dat het selectieteam business, security én IT bevat. En dat er onafhankelijke expertise aan tafel zit, niet alleen de implementatiepartner van de favoriete leverancier.

Change is geen restpost

People, Process, Technology. Vrijwel elk IAM-traject zet de meeste energie op Technology, voldoende op Process, en bijna niets op People. Tot het misloopt. En dan blijken die twee laatste de bottleneck te zijn geweest.

Wat verandert er eigenlijk voor mensen in zo’n programma? Voor applicatie eigenaren: jij wordt nu aanspreekbaar op wie toegang heeft tot jouw applicatie, en je moet daar twee keer per jaar over rapporteren. Voor people-managers: bij elke functiewijziging moet je stilstaan bij de toegang van je medewerker. Voor admins: je oude vaste account verdwijnt, je werkt voortaan via een PAM kluis met session recording. Voor de eindgebruiker: je login kan veranderen, de manier waarop je rechten krijgt verandert, en je verliest zeker rechten die je had.

Dat is allemaal change. En voor de meeste betrokkenen onzichtbare change, want toegang is iets dat al werkt. Dat maakt IAM een lastig ADKAR traject. Vooral op de A en de D.

Awareness vraagt om uitleg waarom dit programma loopt en welk risico het wegneemt. Niet één kick-off, maar herhaalde communicatie via de juiste kanalen. Desire vraagt om eerlijkheid over wat dit voor de individuele rol betekent. En een verhaal over wat het oplevert: minder ticket werk, minder audit-stress, minder vingerwijzen na een incident. Knowledge en Ability vragen om training die past bij de doelgroep, want een applicatie eigenaar heeft andere uitleg nodig dan een people manager. En Reinforcement vraagt dat de governance cyclus ook echt cyclus wordt.

Daarom hoort er vanaf dag één een change-consultant in het team. Communicatiekalender naast de Gantt. Stakeholdergesprekken met de mensen die straks het werk gaan doen. Meten of de boodschap landt. Eigen werkstroom, eigen budget, eigen specialist.

De PM regelt dat die werkstroom er is. Niet wat erin staat.

Vijf fasen van een IAM-programma, kort

Even het globale plaatje. Werkt voor de meeste organisaties tussen 500 en 10.000 medewerkers.

Voorbereiding (fasen 1-2)

Discovery en nulmeting, 4 tot 8 weken. Consultants brengen applicaties, identiteiten, eigenaren en processen in kaart en scoren per domein. Change consultant bouwt de eerste stakeholdermap. PM regelt scope, budget, mandaat, en zet de juiste mensen aan tafel.

Fundament leggen, 3 tot 6 maanden. Consultants ontwerpen IdP aansluiting, opschoningsproces en eerste rolstructuur. Change consultant start de awareness en onboardt applicatie eigenaren in hun nieuwe verantwoordelijkheid. PM hakt knopen door bij keuzes over IdP en rollen. Plus, hij houdt de tool-first reflex tegen, want die komt altijd langs.

Bouw en doorontwikkeling (fasen 3-5)

Automatiseren, 6 tot 9 maanden. Hier komt het bouwwerk in elkaar. Consultants bouwen SCIM- en IGA-koppelingen en ontwerpen de rolcatalogus mét de business. Change-consultant traint people managers op de nieuwe Joiner Mover Leaver (JML) flow. PM dwingt prioritering af, rapporteert voortgang en risico’s, en escaleert wanneer applicaties hun mijlpalen missen.

Governance inrichten, parallel, 6 maanden om uit te werken. Reviews zijn de moeilijkste fase, want niemand heeft er zin in. Consultants ontwerpen het access review-proces, de smart defaults en de SoD matrix, en richten PAM in voor privileged accounts. De controls in deze fase corresponderen direct met ISO 27001:2022 Annex A.5.15 tot A.5.18 en met de zorgplicht uit de Cyberbeveiligingswet (de Nederlandse implementatie van NIS2). Change consultant adresseert review-moeheid voordat die toeslaat. Mensen hebben er gewoon geen zin in en dat is een ADKAR-Desire-issue, niet iets dat je met een betere planning oplost. PM bewaakt completion en revocation rate, en grijpt in als reviews verzanden. Want governance pas oppakken als er een audit-bevinding ligt is geen governance: de piepmethodiek is geen governanceproces.

Doorontwikkelen, continu. Consultants ontwerpen just-in-time architectuur, secrets management en credential lifecycle voor AI agenten. Dit is ook de fase waarin non-human identities — service-accounts, workload identities en agent-credentials — net zo strikt beheerd moeten worden als menselijke gebruikers, iets dat in de meeste organisaties nog niet is geregeld. En het is het moment om eigenaarschap voor agents formeel te beleggen: wie is verantwoordelijk voor wat een AI-agent doet, en namens wie. Voordat het aantal agents de governance voorbij rent. De change consultant bouwt het reinforcement programma. PM organiseert de overdracht naar een blijvend governance team, regelt eindrapportage, en houdt het thema op de directieagenda.

Voor de NIS2 context bij die laatste twee fasen verwijs ik graag naar mijn eerdere stuk over NIS2 en IAM. De auditkant van governance staat daar verder uitgewerkt, inclusief de NCSC-richtsnoeren en DORA-context.

Over timelines, legacy en role drift

Die doorlooptijden hierboven zijn nadrukkelijk geen garantie. In organisaties met veel legacy, organisch gegroeide autorisatiestructuren of jarenlange role drift lopen IAM-programma’s vrijwel altijd langer. Soms aanzienlijk langer.

Wat verlengt het in de praktijk: historische uitzonderingen die nergens gedocumenteerd staan, lokale workarounds die afdelingen hebben verzonnen rond systemen die niet meekonden, entitlement-sprawl over jaren heen, ontbrekende applicatie-eigenaren, handmatige processen die nog draaien naast de officiële systemen, oude SAP-landschappen waarin rollen historisch zijn gegroeid, overgenomen bedrijven die nog op hun eigen identity-fundament draaien, en AD-groepen waarvan niemand meer weet waarom ze ooit zijn aangemaakt of wat ze openen.

Dat zijn niet allemaal grote problemen apart. Bij elkaar opgeteld zijn ze het wel. Hoe ouder de organisatie, hoe groter de kans dat rechtenstructuren historisch gedrag weerspiegelen in plaats van ontworpen governance.

“Veel IAM-programma’s ontdekken pas tijdens implementatie dat er feitelijk geen betrouwbaar autorisatiemodel bestaat om op voort te bouwen.”

En boven op die historische complexiteit komt nu een nieuwe laag bij. AI-agenten en service-accounts hebben hun eigen identiteit en hun eigen autorisaties nodig, en zonder die laag mee te plannen valt elke AI-governance terug op een fundament dat er feitelijk niet ligt. Dat verlengt de scope verder, en dwingt programma’s om niet alleen het verleden op te ruimen maar tegelijk de toekomst in te richten.

Een organisatie met zware legacy en jarenlange role drift kan onmogelijk dezelfde IAM-doorlooptijd verwachten als een relatief greenfield-organisatie. Wie dat in de business case wegmoffelt onder optimistische plaatjes, koopt zichzelf alleen maar uitstel van executie. Beter aan de voorkant eerlijk zijn over de extra inspanning die ontvlechting van het bestaande vraagt. Anders staat fase 3 al na twee maanden vast op een rollenmodel dat de werkelijkheid niet kan beschrijven.

Waarom IAM-implementaties vastlopen

Eén, de programma manager wordt te junior ingekocht. Iemand die actielijsten bijhoudt en stuurgroepen plant, maar geen weerwoord heeft tegen de leverancier of de CISO. Dan stuurt de leverancier het programma. Vraag bij selectie naar boardroom ervaring, niet naar het aantal Gantt charts.

Twee, consultants wordt gevraagd om regie te voeren. Een IGA consultant die ook stakeholders moet aligneren, komt niet toe aan het rolontwerp. Of het rolontwerp wordt platgeslagen om de planning te halen. Niet omdat consultants slecht zijn. Omdat ze niet aan twee dingen tegelijk kunnen werken.

Drie, geen mandaat. De stuurgroep is een rapporteer overleg in plaats van een beslissingsorgaan. Dat los je niet on the fly op. Dat regel je voordat je begint.

Vier, de PM gaat op de inhoud zitten. Hij gaat zelf de rolstructuur herontwerpen. Of de communicatiekalender invullen. Of de SoD-matrix wegen. Vaak goedbedoeld en met de juiste achtergrond. Maar de stuurgroep krijgt vanaf dat moment geen heldere keuzes meer voorgelegd, scope verwatert, en de consultants raken hun rugdekking kwijt. Discipline op de rol is alles. Ook als je de inhoud goed kent. Vooral dan, eigenlijk.

En vijf, de business sponsor verdwijnt waardoor het programma in een vacuum terecht komt met als risico dat het als een nachtkaars uitgaat wachtend tot de volgende audit finding.

En als de uitvoering hapert

Zes, change wordt achteraf bedacht. Een communicatieplan dat in fase 4 erbij wordt verzonnen omdat de uitrol vastloopt. Een training die pas op de dag van go-live klaar is. Een reviewcyclus waarvan applicatie-eigenaren pas leren als ze de eerste mail krijgen. Dan ben je niet aan het managen, dan ben je aan het brandblussen.

Afsluiten

Een IAM-programma hoeft niet perfect te starten. Maar zonder regie, mandaat en aandacht voor change eindigt het vaak als een technisch project met bestuurlijke verwachtingen.

Veelgestelde vragen over IAM-programma’s

Wat is het verschil tussen een IAM-project en een IAM-programma?

Een IAM-project heeft één duidelijk doel, één team en een eindige doorlooptijd — bijvoorbeeld de uitrol van MFA op één applicatie of de migratie naar een nieuwe IdP. Een IAM-programma omvat meerdere parallelle workstreams op People, Process en Technology, duurt 12 tot 24 maanden, en loopt na go-live door als blijvende governance-functie. De kern: een project levert iets op, een programma verandert de manier waarop toegang in de organisatie geregeld wordt. Wie IAM als project benadert mist de organisatorische en bestuurlijke component die het werk juist tot een programma maakt.

Wat doet een IAM-programma manager precies?

De IAM-programma manager voert regie op het programma, niet op de inhoud. Concreet: scope, budget en tijd bewaken, het team aansturen, knopen doorhakken op basis van wat specialisten op tafel leggen, rapporteren richting stuurgroep en directie, en de juiste mensen in de organisatie verbinden met de juiste consultants. Hij verzint geen doelarchitectuur, geen rollenmodel en geen SoD-matrix — dat doen de IAM-architect, de IGA-consultant en de change-consultant. Een PM die op de inhoud gaat zitten verliest binnen drie maanden zijn regiefunctie.

Hoe lang duurt een gemiddeld IAM-programma?

Voor organisaties tussen 500 en 10.000 medewerkers reken op 12 tot 24 maanden tot een werkende basis met automatische JML-flows, een rollencatalogus en een eerste governance-cyclus. In organisaties met veel legacy, organisch gegroeide autorisatiestructuren, overgenomen bedrijven of jarenlange role drift loopt het vrijwel altijd langer. Een greenfield-organisatie komt aan de korte kant van die range uit; een enterprise met oude SAP-landschappen, entitlement-sprawl en handmatige processen aan de lange kant of erover. Wie een kortere doorlooptijd belooft, moet uitleggen welke fase is geschrapt.

Wanneer huur je een onafhankelijke IAM-programma manager in?

Wanneer er intern geen resource is met de juiste seniority én onafhankelijkheid. De PM moet boardroom-ready zijn — in staat om met CISO, CIO en HR-directeur op gelijke voet te praten — techniek en change kunnen overzien zonder erin te gaan zitten, en losstaan van de tool-leverancier om scope-discussies onbevangen te kunnen voeren. Voor de eerste 12 tot 18 maanden is een externe PM vaak de meest efficiënte route, eventueel parttime na de fundament-fase. Een PM in dienst van de IGA-leverancier heeft een ingebouwd belangenconflict bij elke scope-discussie en is daarom zelden de juiste keuze.

Waarom mislukken IAM-projecten zo vaak?

Zelden op techniek. Vrijwel altijd op regie, mandaat, eigenaarschap en change. Vijf patronen kom je vrijwel overal tegen: een te junior programma manager die geen weerwoord biedt tegen leverancier of CISO, consultants die gevraagd worden om regie te voeren waardoor inhoudelijk werk platgeslagen wordt, een stuurgroep zonder beslismandaat, een PM die zelf op de inhoud gaat zitten, en change die pas in fase 4 wordt bedacht omdat de uitrol vastloopt. Daar bovenop een tool-first reflex en onderschatting van legacy en role drift. De IGA-tool werkt meestal wel. De organisatie eromheen niet.

Wat is access governance en waarom is het belangrijk?

Access governance is het geheel van processen waarmee een organisatie kan aantonen dat de juiste mensen op het juiste moment de juiste toegang hebben — en dat ook periodiek hertoetst via access reviews, SoD-bewaking en privileged access management. ISO 27001:2022 belegt dit expliciet in Annex A.5.15 (Access control), A.5.16 (Identity management), A.5.17 (Authentication information) en A.5.18 (Access rights). DORA artikel 8 vraagt om een ICT-risk-management-framework dat dezelfde controles afdwingt voor de financiële sector, en de Nederlandse Cyberbeveiligingswet legt de zorgplicht uit NIS2 vast met persoonlijke bestuurdersaansprakelijkheid. ENISA en het Nederlandse NCSC publiceren beide richtsnoeren die deze controles concreet uitwerken. Zonder access governance kun je geen incident binnen 24 uur reconstrueren, geen audit doorstaan en geen onderbouwde risico-analyse leveren. Het is het verschil tussen “IAM-tool draait” en “IAM-programma levert iets bestuurbaars op”.

Ric van Westhreenen

Programma Manager gespecialiseerd in IAM, digitale werkplek en digitale transformatie. Pragmatisch, hands-on, getting things done.

Verbind op LinkedIn →