I too have done it before: developed a maturity model. In my case for the management of electronic identities, digital access and access rights, or in short Identity & Access Management (my daily work). As far as I’m concerned, there is nothing against maturity models, because they can help you determine how you are going to progress in a particular area. Thinking about it can be very useful.
However, it starts to tickle when the model is wrapped up in a scan. That too can be useful if the context is universal, for example a standard for an industry or legislation. Everyone has to comply with the law and if a scan can indicate the extent to which I comply or do not comply, then that is fine. But if the context is that whoever performs the scan determines what you should comply with, the outcome is a priori that you are immature. There is certainly still a lot to be done to reach maturity and the performer can probably help with that. You are then usually on the way to implementing less useful things in addition to useful ones.
That is why I have always been reluctant to perform a maturity scan for Identity & Access Management (IAM) (and am allergic to such scans in other areas). There is no good standard. And if you include enough IAM functions as ‘mandatory’, the subject of the scan (our company’s customer) is always immature. And as a customer, you have to be sorry about that.
So we don’t do it, such a scan. We prefer to look with you at what your security policy and risk analyses say needs to be done. We have broken down everything that IAM has to offer into 21 relevant functions/processes, from user authentication to rights management and machine learning-based access. For each component, we look at whether it makes a useful contribution to your security. If it does, we indicate more precisely what needs to be done. It is a simple method that works quickly and does not result in unnecessary measures.
©Peter Jurg, March 2020
