KuppingerCole Analysts' View on IAM Strategic Planning

   

Article

Top Risks of IAM Programmes

Rob Newby

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.

   

Commentary

Step back and review your IAM program: Why you need to review your IAM/IAG Strategic Planning now

Martin Kuppinger

IAM/IAG (Identity Access Management/Governance) is changing. The Computing Troika of Cloud, Mobile, and Social Computing creates new challenges. Different deployment models, new devices and mobile users, and more groups of users to deal with more closely are fundamentally changing the business demand for IAM/IAG. The good thing: There finally is strong demand not only from IT, Information Security, and Audit for IAM/IAG, but also from business.

However, there are new challenges and new types of demand. The need for quickly on- and off-boarding business partners, giving access to business partner applications, managing access to the Cloud, integration of customers using various types of logins, etc. – all these are new challenges that extend the scope of IAM and IAG.

Addressing these challenges is neither about doing something different nor about killing and replacing your IAM. It is about extending and embracing what you have and move it to the next level, to support the new requirements businesses are facing.

That is the reason why it is time to set back and review IAM programs: IAM/IAG is changing. Thus, it is mandatory to review what you have today and think about how to best extend that to a future-proof IAM/IAG that supports the new business demand. The IAM/IAG infrastructures of most organizations will become hybrid, with components running on-premises and others in the Cloud. The term “hybrid” indicates that this is about something that is integrated. Hybrid is not about having an internally-facing and an externally-facing IAM/IAG infrastructure, but a consistent, integrated, well thought-out approach that protects existing investments whenever possible and adds what is required for the future.

KuppingerCole Advisory Services support you in the review and redefinition of your IAM/IAG Strategic Planning. And there is no better place to learn about the changing landscape and new solutions than EIC 2014.

Related KuppingerCole Research


Related KuppingerCole Blog Posts