De IGA tool draait. Connectoren werken. Workflows staan klaar. En toch werkt het niet.
Die zin hoor ik in elke IAM omgeving wel een keer. Meestal tussen de tweede en de vierde maand na go-live. Bij de eerste recertificatieronde, of bij de eerste serieuze mover-event. Dan blijkt dat alles wat de architect in SailPoint of Omada heeft uitgedacht, voor één gebruikersgroep gewoon niet werkt. De manager.
En zonder die manager werkt geen IAM programma. Hoe duur de tool ook was.
Dit patroon zie ik in vrijwel elk groot IAM traject terugkomen. Geen technisch falen. Een verandermanagementprobleem dat zich vermomt als IT-project. Wie dat onderscheid niet ziet, levert keurige techniek af aan een organisatie die er onbedoeld niets mee kan.
Wat een manager in de IAM-keten geacht wordt te doen
Een gemiddelde manager in een corporate met fatsoenlijk ingericht identity-landschap heeft minstens vijf rollen in het IAM-proces. Maakt niet uit of de tool SailPoint, Saviynt, Omada of Microsoft Entra heet, de rollen zijn vergelijkbaar.
Hij keurt toegangsverzoeken goed of af. Hij doet recertificering, meestal halfjaarlijks, soms vaker bij privileged access. Hij signaleert mover-events wanneer iemand van team wisselt. Hij geeft exceptions af op standaardrollen en moet die later kunnen verantwoorden, bijvoorbeeld bij een externe audit op grond van ISO/IEC 27001. En bij Joiner en Leaver is hij de schakel tussen HR en IT die de timing aanstuurt.
Vijf taken. Elk daarvan veronderstelt iets. Inzicht in wat een entitlement betekent. Bewustzijn van SoD. Aanvoelen waar privileged anders is dan regulier. En weten wat een service account is, en waarom die er niet bij de menselijke recertificering hoort.
Voor geen van die dingen krijgt hij in de meeste organisaties structurele opleiding. De manager krijgt zijn eerste toegangsverzoek-mail, leest ‘m half, en klikt op approve. Niet omdat hij slordig is. Omdat hij er nooit op is voorbereid.
Wat de manager letterlijk ziet
Wat een gemiddelde manager in een IGA tool ziet, is zelden ergonomisch. Hij krijgt een mail dat er een access certification klaarstaat. Hij logt in, ziet een lijst van dertig medewerkers, en moet per medewerker tussen de tien en honderd entitlements beoordelen. Entitlements heten dingen als AAD-SG-Finance-Admins, PROD-FIN-REPORT-READ of O365-DG-PMO-EU.
Voor de architect logisch. Voor de manager Latijn. En toch verwacht de governance-stuurgroep een betekenisvolle review.
Waarom manager-enablement structureel onderschat wordt
Architecten en programmaleiders investeren onevenredig in techniek. Een SailPoint of Saviynt implementatie kost miljoenen en levert tastbare deliverables: connectoren, workflows, role-modellen, dashboards. Manager-enablement krijgt vrijwel altijd een fractie van dat budget. Een training van twee uur. Een Confluence-pagina. Een korte video. En dan moet de manager vervolgens halfjaarlijks beslissingen nemen over toegang voor twintig of dertig medewerkers, in een interface die hij vier keer per jaar opent.
Werkt zelden.
In een eerder artikel over waarom IAM-projecten falen op governance heb ik beschreven hoe het zwaartepunt in IAM programma’s structureel verkeerd ligt. Het manager-vraagstuk is daar een directe afgeleide van.
Vier patronen die ik in vrijwel elk programma zie
In elk traject kom ik dezelfde gedragingen tegen, in wisselende verhoudingen.
Bulk-approval. De manager klikt op “approve all” omdat hij de individuele entitlements niet kan duiden. Oude rechten blijven staan en de recertificering wordt een papieren formaliteit.
Delegated approval. Hij geeft het door aan een teamlid. Wettelijk meestal toegestaan, in de praktijk een gat in je governance. De delegate kent jouw entitlement-bibliotheek nog minder dan jij.
Onthouding. De manager doet er niets mee. Reminders gaan af, escalaties volgen, uiteindelijk wordt de approval automatisch toegekend of geweigerd op timeout. Allebei slecht.
En het schaduwspoor. De manager keurt iets goed waarvan hij dacht dat het tijdelijk was. Het blijft staan. Vier jaar later zit het nog steeds in de IGA database en niemand weet meer waarom (en niemand durft het weg te halen, want stel dat).
Geen technisch probleem dus. Wel een verandervraagstuk. En in mijn ervaring bij grote IAM trajecten, precies de plek waar programma’s gemaakt of gebroken worden.
De Prosci-bril op het manager-vraagstuk
Een manager die structureel goed beslist over toegang, doorloopt eigenlijk alle vijf fases van Prosci’s ADKAR-model. Awareness, Desire, Knowledge, Ability, Reinforcement. Wie die bril opzet, ziet veel scherper waar het in IAM programma’s misgaat.
Awareness — beseft hij dat dit ertoe doet?
In de meeste programma’s wordt deze fase wel geraakt. Er gaat een mail uit dat de IGA omgeving live is, en dat managers verantwoordelijkheden hebben. Maar de Awareness blijft procesmatig. Hij weet dát hij iets moet doen, niet waarom. Een audit-finding of een datalek dat terug te leiden was naar een slordige recertificering, is een veel sterker bewustzijnsmoment dan een policy-mail.
Desire — wil hij dit eigenlijk?
Hier zit volgens mij de meest onderschatte breuk. De gemiddelde manager zit niet te wachten op IAM werk. Geen direct rendement op zijn afdeling. Zelden gewaardeerd in een beoordeling. En makkelijk weggeklikt zonder dat iemand het merkt.
Knowledge — weet hij waarover hij beslist?
De typische enablement bestaat uit een tooltraining. Hoe log je in, hoe vind je je campagne, hoe klik je op approve. Wat ontbreekt is inhoudelijke kennis. Wat ís een entitlement. Wat is het verschil tussen privileged en regulier. Wat betekent het concreet als ik dit goedkeur. Werk dat in de meeste programma’s gewoon niet wordt opgepakt.
Ability — kan hij het ook praktisch?
Tijd en tool. Twee variabelen die structureel onderschat worden. Een manager met twintig medewerkers en zeshonderd individuele beslissingen per campagne, in een interface waar hij vier keer per jaar inkomt — die gaat bulk-approven. Geen onwil. Een rationele reactie op een onhandig systeem.
Reinforcement — wat gebeurt er na de campagne?
Hier valt de meeste energie weg. De campagne sluit, de rapportage gaat naar Risk & Compliance, en het volgende halfjaar gebeurt er niets meer met de uitkomsten richting de managers die het werk hebben gedaan. Een organisatie die alleen de eerste fase aanraakt (de awareness-mail), en de andere vier overslaat, krijgt rapportages die in de tool kloppen en in de praktijk geen betekenis hebben.
Wat in IAM-programma’s wel werkt voor manager-adoptie
In trajecten waar de manager-laag wél meeging, zag ik een paar terugkerende interventies. Geen ervan is technisch. Geen ervan kost wat een SailPoint licentie kost. Geen ervan wordt structureel ingebed in IAM programma’s.
Maak de manager-rol expliciet in de governance
Op papier. Niet alleen in de tool. “Als manager beslis je over X, Y en Z. Geen optionele taak.” Klinkt triviaal. Is het zelden. In een organisatie waar de manager-rol expliciet staat opgeschreven en wordt gehandhaafd, doen managers het werk met meer ernst. Dat sluit ook aan op de NIS2 richtlijn, die bestuurders persoonlijk aanspreekbaar maakt en daarmee de hele organisatie dwingt verantwoordelijkheden expliciet te beleggen.
Stop met training-events, ga over op just-in-time enablement
Een tweemaal-per-jaar workshop werkt niet voor een proces dat managers tweemaal per jaar doen. Wat wel werkt: contextuele hulp op het moment dat de manager een approval krijgt. Een korte uitleg in de tool zelf, bij elk entitlement, geschreven door de business owner van de applicatie. Niet door IT.
Schakel de overzichtsdrang in
Veel managers willen overzicht. Geef ze een eenvoudige weergave van “dit zijn alle rechten van mijn team”, niet één toegangsverzoek per keer. Helpt bij begrip én bij recertificering. En het sluit aan op hoe een manager de wereld ziet: niet per entitlement, maar per medewerker.
Maak de consequenties zichtbaar
Wanneer een audit findings oplevert die terug te leiden zijn naar bulk-approvals, deel dat terug aan managers. Niet als verwijt. Wel als signaal. Hetzelfde voor security-incidenten waarbij toegangsrechten een rol speelden. Dit is de Reinforcement-laag die in vrijwel elk programma ontbreekt.
Bouw ownership bij senior managers
Een directeur die zelf zijn recertificering serieus doet, zet de toon voor de hele afdeling. Daar zit meer hefboomwerking dan in nog een communicatiecampagne. Senior leaders die zichtbaar IAM discipline tonen, veranderen de norm. Anders dan bij gewone IT-projecten vraagt dat actieve sponsoring vanuit de top.
Wat een onafhankelijke programma manager hier toevoegt
Een IAM programma wordt zelden uitgevoerd door interne mensen alleen. Er zit meestal een leverancier in voor de tool, een systeemintegrator voor de implementatie, en een interne stuurgroep voor de governance. Wat in mijn ervaring ontbreekt, is een rol die het manager-vraagstuk bewust eigenaar maakt.
Dat is een rol die ik in trajecten waar ik leid, expliciet beleg. Niet als trainer. Niet als communicatiemanager. Wel als degene die zorgt dat de ADKAR fases voor de manager-laag benoemt worden zodat deze ook echt doorlopen worden, en niet alleen op papier. Het is een vakgebied waar IAM en change management elkaar raken, en precies de plek waar veel programma’s hun grootste blinde vlek hebben.
Tot slot
De vraag die ik bij elke IAM kickoff stel — en steeds vaker, omdat het antwoord steeds dezelfde richting opgaat — is niet welke tool er gekozen wordt. Het is: wat is jullie strategie om de manager-laag mee te krijgen?
Geen antwoord daarop? Dan weet je waar het programma over achttien maanden vastloopt.
De tool werkt. De governance niet.
Veelgestelde vragen over IAM-rollout en manager-adoptie
Wat is de grootste oorzaak van een mislukte IAM-rollout?
In mijn ervaring zelden de techniek. Veel vaker hapert het op de manager-laag. De gebruikersgroep die toegangsverzoeken moet goedkeuren, recertificeringen moet uitvoeren en mover-events moet signaleren. Zonder goede enablement op die groep eindigt vrijwel elk programma met groene rapportages die in de praktijk niet kloppen.
Hoeveel tijd kost recertificering een gemiddelde manager?
Voor een manager met twintig medewerkers en gemiddeld dertig entitlements per medewerker gaat het over zeshonderd individuele beslissingen per campagne. Bij conservatieve dertig seconden per beslissing is dat vijf uur werk, twee keer per jaar. In organisaties zonder goede tool-ergonomie loopt het op naar het dubbele.
Werkt het ADKAR-model voor IAM-programma’s?
Ja, en in mijn ervaring beter dan voor veel andere IT trajecten. Het probleem in IAM is namelijk niet technisch maar zit op begrip, motivatie en gedrag bij een specifieke gebruikersgroep. Precies waar Prosci en ADKAR voor ontworpen zijn. De vijf fases passen naadloos op het manager-vraagstuk.
Wat is het verschil tussen privileged en reguliere recertificering?
Privileged access (PAM) heeft een hoger risico-profiel. Accounts die kritieke systemen of administratieve functies kunnen wijzigen. In een goede opzet heeft privileged recertificering een aparte workflow, vaker dan halfjaarlijks (kwartaal of maandelijks), met expliciete validatie door zowel manager als security. Reguliere access kan in een halfjaarlijkse campagne.
Moet ik mijn IAM-programma anders inrichten als ik op NIS2 moet voldoen?
NIS2 verplaatst aansprakelijkheid naar de bestuurder en dwingt daarmee organisaties identity- en accessverantwoordelijkheden expliciet te beleggen. Niet alleen een compliance-vraag, ook een hefboom om manager-adoptie afdwingbaar te maken. Lees verder in NIS2 en IAM: waarom identity & access management nu bestuurlijke prioriteit is.
Welke rol speelt een onafhankelijke programma manager bij manager-adoptie?
Een onafhankelijke programma manager beschermt het belang van adoptie tegen het belang van technische voortgang. Leveranciers en systeemintegratoren hebben een natuurlijke prikkel om naar go-live te willen; adoptie kost ze tijd en marge. Een onafhankelijke programma manager zorgt dat de ADKAR fases daadwerkelijk worden doorlopen en dat manager-enablement een eigen werkstroom met budget en KPI’s krijgt.
