Ook ik heb het wel eens gedaan: een maturity model ontwikkeld. In mijn geval voor het beheer van elektronische identiteiten, digitale toegang en toegangsrechten, oftewel Identity & Access Management (mijn dagelijkse werk). Er is wat mij betreft niets tegen maturity modellen, want ze kunnen helpen om na te gaan hoe je verder komt op een bepaald gebied. Daarover nadenken kan heel nuttig zijn.
Het begint echter te kriebelen als het model wordt ingepakt in een scan. Ook dat kan nog nuttig zijn als de context universeel is, bijvoorbeeld een norm voor een branche of de wetgeving. Iedereen moet aan de wet voldoen en als een scan kan aangeven in hoeverre ik daar aan voldoe of juist niet voldoe, dan is dat prima. Maar als de context is dat degene die de scan uitvoert bepaalt waar je aan zou moeten voldoen, dan is de uitkomst bij voorbaat dat je onvolwassen bent. Er moet dan zeker nog een hoop gebeuren om volwassenheid te bereiken en de uitvoerder kan daar waarschijnlijk goed bij helpen. Je bent dan meestal op weg om naast nuttige zaken ook minder nuttige zaken te implementeren.
Daarom heeft het mij altijd tegen gestaan om een maturity scan voor Identity & Access Management (IAM) uit te voeren (en ben ik allergisch voor zulke scans op andere gebieden). Er is geen goede norm voor. En als je maar genoeg IAM functies als ‘verplicht’ meeneemt is het onderwerp van de scan (de klant van ons bedrijf dus) altijd onvolwassen. En dat moet je dan erg vinden als klant.
Wij doen het dus niet, zo’n scan. We kijken liever met u naar wat uw beveiligingsbeleid en risicoanalyses zeggen dat er moet gebeuren. We hebben alles wat IAM te bieden heeft opgedeeld in 21 relevante functies/processen, van verificatie van de gebruiker tot rechtenbeheer en toegang op basis van machine learning. Per onderdeel bekijken we of het een nuttige bijdrage levert aan uw beveiliging. Als dat zo is, dan geven we meer precies aan wat er moet gebeuren. Het is een simpele methode die snel werkt en niet resulteert in overbodige maatregelen.
©Peter Jurg, maart 2020
