How to Create an Effective IAM Program

Identity and access management (IAM) should be treated as a complex, long-term program with an open-ended set of deliverables. As such, an IAM program requires strong executive sponsorship, incremental deliverables, effective project management and strong technical resources to design, deploy, operate, support and upgrade multiple software products. This piece details those requirements and explains how to create an effective IAM program and operational structure.

Scope of IAM

It’s not uncommon for IAM implementations to be long or indeed endless, as deliverables are continually added over the life of multiple systems. Organizations go through both business and infrastructure changes, including re-organizations, mergers, acquisitions, divestitures, OS upgrades, cloud migrations, new application deployments, etc. These changes trigger matching requirements in IAM systems and consequently lead to implementation and maintenance effort. In other words, ongoing investment is a good thing – it means the business benefits from a constantly expanding set of capabilities.

This is not to imply that individual deliverables cannot be implemented quickly or operated efficiently. Rather, successful implementation of one feature or integration usually triggers interest by new stakeholders, who request additional features or integrations.

It is helpful to think of IAM process automation as iterative optimization. Ongoing expansion in the scope of deployed systems should be the responsibility of a permanent team, rather than implemented by a team assembled for a single set of deliverables and then released to other, non-IAM projects.

Successful organizations create a permanent IAM program, rather than staffing for a short-term deployment project.

What is Identity and Access Management (IAM)?

IAM is a complex set of capabilities. A useful definition for IAM is the set of processes and technologies used to effectively and consistently manage the identity lifecycles, attributes, entitlements and credentials of human users and non-human software agents, across systems and applications. IAM systems are deployed to meet regulatory obligations and internal control objectives, to make IT access administration and user authentication more efficient and agile, and to reduce IT operating costs.

Product Categories Within IAM

The functional product categories within IAM include:

• Directories, which provide scalable and reliable storage and query services for identity, entitlement and credential data.
• Identity governance and administration, with a focus on securing the entitlements and credentials of "internal" and "business partner" identities.
• Consumer IAM, optimized to create, update, delete and manage the preferences of large numbers of relatively simple identities.
• Privileged access management (PAM), which is intended to address the problem of static, plaintext passwords, to broker privileged access to systems and to introduce accountability to such access.
• Federated access and multifactor authentication (MFA): Often in a single product, these are designed to reduce login friction between users and multiple applications while at the same time increasing assurance that users are who they claim.

Each of these categories tends to be automated with distinct software products.

IAM Stakeholders

IAM’s many stakeholders include: IT, audit, compliance, application owners and business users. These stakeholders may have conflicting or at least non-overlapping objectives. Without a mechanism to synchronize priorities, IAM programs can degenerate into ongoing conflicts about what to do and where to begin.

A strong executive sponsor with both the authority to resolve disputes and the funding to deliver outcomes is essential to IAM program success. Because IAM stakeholders are so widely distributed across different parts of the organization, it’s critical the sponsor resides higher up in the organization hierarchy to have authority over as many of them as possible.

The concept needing an executive, or leadership-level sponsor for IAM may be surprising, because IAM is relatively small compared to other highly-placed IT initiatives or programs, but it is important nonetheless.

Technical Acumen Required for IAM

IAM incorporates both business process automation and integration with a wide variety of systems and applications. Typically, multiple software products are involved, each with its own architecture, extensibility mechanisms, etc. This complexity means significant technical expertise is required to move IAM ahead.

A best practice is to have at least one dedicated, strong technical resource per IAM product. Ideally, the same person is not responsible for multiple IAM software components, because each one will require one or more full-time employees (FTEs) to deploy, integrate, configure, support and extend. Assigning the same technical expert to multiple IAM products could potentially dilute this individual’s availability and extend deployment or feature-addition timelines.

IAM Project Management

Consider managing IAM as a program, rather than a project, because there is a lengthy sequence of deliverables. Within the overall IAM program, each deliverable should be organized as a project. Each implementation project should be assigned a project manager.

Inside this structural framework, project managers are responsible for delivering new capabilities on time and on budget. It is a good idea to also leverage project managers when prioritizing new capabilities, once each deliverable is complete.

A rule of thumb to consider is between 0.5 to 1.0 project managers per concurrent deliverable. If an organization plans to work on, for example, four initiatives at any given time, then it makes sense to have from two to four project managers in the IAM program.

IAM is a complex topic and it's helpful for project managers to understand not just resources and timelines but also the subject matter at hand. It is therefore a best practice to send project managers to relevant product training and retain them in the IAM area for a long time, rather than pulling a fresh PM from a project management office for every new initiative.

While it is a good idea to draw up a long-term IAM roadmap with strategic deliverables that may require years to complete, consider a periodic approach, where the roadmap is examined every 6 or 12 months and:

• Remove any no-longer-needed items.
• Add newly discovered deliverables.
• Identify the most urgent deliverables. At least one and as many as N, where the organization is prepared to work on N items concurrently.
• Assign resources and timelines for those N most urgent deliverables.

Repeat this prioritization exercise as work is completed, rather than trying to plan out deliverables years in advance.

In some organizations, different people are responsible for:

• Architecture
• Product selection
• Software deployment
• Ongoing support of running systems

These silos can create perverse incentives. Architects select technologies that fit well into an overall picture but may not have required features. Procurement teams could choose products with attractive features but that may be difficult to deploy. Deployment teams might focus on installation and upgrade, but disregard operational support.

Consider a single team that lives with the IAM system for its entire lifecycle, engaged early in the architectural design and tasked with long-term support of the system. This team can pull in architecture, procurement specialists and systems integrators when required, but it should "own" the system from cradle to grave.

Similarly, consider the teams responsible for different IAM functions – such as directories, onboarding, deactivation, review/recertification, password management, privileged access, MFA, federated access, etc. – to coordinate and integrate. This does not mean they must buy from a single vendor or run on the same platform, but they should evaluate business processes with a big picture in mind and implement integration between IAM components whenever possible.

Communicating IAM Program Priorities

IAM is big and complex. There is always a lot going on. There are many stakeholders, each with their own priorities. It's helpful to communicate clearly with all stakeholders what IAM capabilities are already deployed, what outcomes they are generating, what's planned and in what sequence. The same venue can be used to share information about the health of IAM-related systems.

Because priorities evolve and system health is real-time, this data is "live." A best practice is to build an IAM portal and publish all this information. It should be open to the entire organization and updated both:

• In near-real time, as it relates to system health.
• Whenever the roadmap, timelines or priorities evolve.

Transparency aids collaboration and reduces conflict between stakeholders.

Roles and Responsibilities

The overall IAM program should include:

• An IAM program sponsor
• A program manager, responsible for roadmap, priorities, procurement, staffing, etc.
• Someone responsible for communication of the IAM program’s current state, health, plans and priorities with the overall organization (e.g., via an IAM portal).

For each IAM software product, an implementation and support team should include people with specific responsibilities and skills (see Figure 1).

For each deployment initiative (new product, feature or integration), consider assigning a team that might include:

• A fractional or full-time project manager (depending on scope of work).
• The team responsible for the impacted software product (see above).

READ: Centralized IAM Best Practices

How to Set Up a Successful IAM Program

Effective IAM programs have multiple prerequisites. To be successful, consider focusing on:

• Executive support: The program should be supported by a strong executive sponsor and built for the long run.
• Staffing: This should include program and project managers, as well as technical experts with skills pertaining to every involved product. A persistent team should be involved in each IAM software product, from initial requirements gathering through procurement, design, deployment and ongoing support.
• Transparency: Transparency is an important tool to reduce friction between stakeholders, and an IAM portal that includes real-time system status, accomplishments and a long-term roadmap is recommended.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.