Top reasons to get started on your Identity and Access Management project

Identity and Access Management (IAM) and Identity and Access Governance (IAG) have become key components of an organisation’s security posture. There are countless reasons why an organisation would choose to start an IAM or IAG project. For those that are starting on this journey, one thing is crucial – to be completely transparent about the justifications and objectives for organisational spend on such a project. Alongside this, understanding the common pitfalls and practical tips prior to starting your project will add to its success and overall effectiveness. Here, we’ll help you to identify the main benefits that an IAM project will deliver and clearly align these to the organisation’s objectives.

Preconceived ideas and pitfalls to avoid before starting your project

An IAM or IAG project is not only about deploying a technical product. Many functions and departments of the wider organisation are involved in the implementation. It is a more, functional and organisational project, the operation of which can

fail if insufficient attention is paid to a series of points. This section

will help organisations to identify the pre-conceived ideas and pitfalls and look at how they can be avoided.

PRE-CONCEIVED IDEA:

“IAM is a magic bullet”

Unfortunately, there is nothing magical about IAM. You can’t use it as

a magic wand to deal with blurred organisational lines, the inconsistent definition of job profiles or technical degeneration that makes applications incompatible with current standards.

In order to prevent disappointment down the line, you need to:

  • Evaluate your ‘IAM maturity’
  • Set out a roadmap to increase this maturity
  • Specify the requirements for each step in order to get the very most out of IAM

For example, an IAM project will not integrate all IS applications into its scope, at least in the first phases of the project, such as the ‘accounts and rights provisioning strand’.

As such, attention needs to be paid to stop You therefore need to pay attention to failures such as “IAM stops where the IS starts”. You need to be realistic, communicate clearly about the scope of your project, even

at the initial stages, to avoid this. If necessary, you will also need to be prepared  to adapt to market technologies, internal processes, budget,etc.

PRE-CONCEIVED IDEA:

“Manage the project yourself to save time and have fewer headaches”

Implementation of this type of project very often impacts on your whole organisation. IAM is a cross-functional project that can disrupt the organisation. For this reason, it is essential to communicate and involve all stakeholders. This applies to business lines, HR, general

management, the IT department, management controllers, auditors, and so on. The best approach is to make allies, by finding arguments that concern them and by reaching out to the people with something at stake from the outset.

PITFALL:

“Buying the software package before you

have even defined your need”

This is one of the biggest mistakes that happens to organisations during the implementation of and IAM project. For the most part, IAM packages do what they are designed to do, but that is not to say they all do it in

the same way, with the same functional coverage.

It’s important not to go all in on a particular solution as a group choice, for example, or because it is discounted, or on the strength of an overly subjective piece of advice, before you have a good overview of what is expected in the short, medium and long terms from IAM.

For instance, it is easy to understand why a small subsidiary would not necessarily want to use and deploy group solutions that are unsuited to

it from a functional and technical perspective. If the IS is of a reasonable size, it may be preferable to consider manual procedures to begin with and to meet the project’s priorities.

However, once you have chosen your solution, the approach needs to switch. It is essential that you investigate exactly how the solution functions, perhaps seeking help from a partner, so that your plans are

in accordance with the general capabilities of the solution. This will limit special developments. In addition, functionalities not accounted for at the outset may be available and make it easier to accommodate some use cases.

PITFALL:

“Wanting to do everything at once”

Pay close attention to the initial scope. You should forget about implementing your IAM project in one fell swoop. An iterative approach

is by far the best course of action: break it down into functional modules, geographical or organisational units, user populations or application scopes, etc.

You need to make step-by-step progress, starting with a reduced, controlled scope so that you understand the nuts and bolts of the software packages you’re using. The blitz approach has given way to the batch approach once and for all. In order to manage expectations, you need to communicate this to stakeholders.

PITFALL

“Short-term thinking”

Just because the IAM solution has been implemented, it doesn’t mean it stops there. IAM is a very dynamic system which long outlasts the initial build. It is crucial you know who will be managing the project once this initial phase is complete, who will operate it, who will upgrade it, etc.

This means having a service continuity guarantee; without one there is

not much point starting at all. 

PITFALL:

“Thinking you know how people work day to day”

You know how your company is organised from a high-level perspective, its main business areas, its key specific features, how it has changed in the past and perhaps how it might evolve in the future.

However, do you know enough about how each member of staff operates and the working demands they face? Do you know about the constraints on office-bound and roaming staff? Those that have a desk and those that don’t? Those that have low-bandwidth network access, are remote support teams or work antisocial hours? What about how the organisation operates during the holidays?

An IAM project will have to address the operational reality on the

ground, and will only be welcomed if it makes every day use simpler and takes account of legitimate specific differences. You therefore need to look beyond organisational principles in order to:

  • Understand how the company functions operationally
  • Compare these uses with the theoretical organisational model
  • Separate “operational biases” that need not be factored into IAM from “actual specific characteristics” that IAM must adapt to

Six best practices for starting your IAM or IAG project

Know your Information System (IS)

An IS will very often be long-established, and encompass a variety of systems, all of which makes implementing an IAM project more complex. To keep nasty surprises to a minimum, it is advisable to identify clearly, and quickly, the people responsible for the functional and technical aspects of the application fleet, so that they can be involved very early in the preliminary scoping phase.

Define your need clearly

It is essential to determine your needs clearly in the short term, and in the medium and long terms if known. This allows you to plot your roadmap and identify the key steps in your project. While there is a strong temptation to keep adding functionalities, it is important not give into it, or you may never get started on the project. A better approach is to split the project into batches and iterations, and anticipate upgrades, as far as possible, while also considering the consistency of the user population.

Do not mix genres

In an attempt to oversimplify, some shortcuts can prove ill-advised. For example, lifecycle management cannot be addressed in the

same way for internal IS users as for external clients. The constraints and volumes for both are very different. You might have one

thousand internal staff, but millions of client identities to manage, and attempting to manage these in the same way can lead to disaster. This logic also applies to applications to manage in an SSO or federated identity management project, or a strong authentication project.

Get away from ambiguous names: IAM, IAG, IAI

For those that are involved in the implementation, but who may not have a technical background, referring to IAM, IAG, IGA, IRM, IAI, IDaaS, etc. can be a major source of confusion, this can even include suppliers. This is especially true when each step in the project might only overlap partially with these concepts. As an illustration:

a) Identity recertification functionalities might greatly improve the quality of data in a step centred on identity management and the creation of an identity reference base

b) A rights recertification step might greatly help in defining job profiles and upgrading the entitlements model.

Master the vocabulary

The vocabulary used seems easy and understandable to all, but do not be mistaken. Is everyone in your organisation aware of the difference between a credential and an authorisation? How about authentication and identification? What is the definition of an account, a role and a profile? Mastering the various terms used in this type of project to avoid misinterpretations is vital to

the smooth running of an IAM implementation. Putting together a presentation and an internal glossary, illustrated with relevant examples, is very often a good way of ensuring everyone speaks the same language.

Get a grip on communication

Getting a grip on communication means first identifying the impacts of deploying your project upon the organisation. You will then be able to plan, target and control how it is communicated. This means identifying the actors concerned, when and how to involve them, how to assess the gains, etc.

Olivier Morel, Ilex International
Image Credit: 8MAN