IAM risks fit into 4 programme areas, Executive Support, Business Involvement, Strategy and Technology; and one area of the organisation, People. Each of these areas holds a number of risks which must be managed and controlled.
1. Executive Support
Risk 1 – Without executive buy-in to an IAM programme, navigating the business is an uphill task which eats into valuable planning time.
Issue – The identification of responsibilities in the business organization is often the most complex challenge.
Mitigation – This is made much easier if the business value can be explained in clear, simple terms.
Executive sponsors need to be well informed and ready to control the direction of IAM programmes, and to understand the purpose of the individual projects within them.
2. Business Involvement
Without business involvement, IAM projects suffer from:
Risk 2 – Unclear scope
Risk 3 – Scope creep
Risk 4 – Being overtaken by technology requirements
Issue – The business needs to drive the programme and lead the technology, not vice versa.
Mitigation – In addition to meeting regulatory specifications and audit requirements there are other benefits that need to be made clear: the overall view of users; the ability to quickly connect new business partners; and added agility for the business.
It is important that the business environment is understood and mapped out before the technology can be deployed in the proper context.
3. Strategy
Risk 5 – IAM projects can be complex; a big bang approach is difficult to control. The "identity explosion" – the multiplication of corporate identities requiring management has to be considered from the outset.
Issue – Even though the first implementations might only give a small set of functionality to a group of employees, they must be designed so that they can grow.
Mitigation – IAM should be turned into a programme of projects, not one large over scoped project with unclear boundaries.
Projects must be clearly scoped and joined together in a meaningful programme.
4. Technology
A technical programme can be stopped in its tracks by:
Risk 6 – Choosing the wrong product
Risk 7 – Trying to leverage existing failed products
Problem – Letting the programme be driven by System Integrators (SIs) or vendors, in the mistaken belief that they are the experts, will not only destroy the current programme, but affect the success of any future IAM projects as well. IAM programme stakeholders need to understand the environment they are deploying into, not just the tools being deployed, and without a vested interest.
Mitigation – Ensuring that SIs, vendors and technical teams are respected, but controlled by the business and the programme creates a mutually beneficial working environment. Give technical teams a platform to express their concerns and take them on board, but do not allow them to constrain business requirements.
5. People
People have different understandings of how IAM functions due to their role in the business, or previous experience with technology. There will therefore be many different views of how and when to deploy. With conflicting views of what an IAM should involve, projects can quickly become politicised, dividing business and technical teams, creating in-fighting and disillusionment.
Risk 8 – This is one key area which overlays all of the others. People, their knowledge and expertise are vital to the success of any programme. Without the right people, an IAM programme can be just another (failed) project.
Issue – Departments need to be able to control access to their own systems. New user groups need to be easily absorbed without large management overheads.
Mitigation – IAM must be simple enough that it works for the end user. Knowledge must be freely shared, progress communicated regularly, and success celebrated.
This article was originally published in the KuppingerCole Analysts' View Newsletter.