About to embark on a journey in the world of identity? Looking to atone for past Identity and Access Management (IAM) or Identity Governance and Administration (IGA) sins? If so, with an IAM roadmap in place, one of the first steps we recommend is to thoroughly consider what are the appropriate IAM roles and responsibilities. In general, there are five components to create a good identity program, which consists of an IAM advisory committee, IAM project team, IAM core team, business stakeholders and IAM operations.
In this post, we focus our attention on the IAM advisory committee, sometimes referred to as an IAM steering committee or IAM program committee.
At Protiviti, we’ve been helping organizations deliver IAM programs for over 15 years. Throughout that process, we have been fortunate enough to work with hundreds of companies from beginning to end. One of the key insights that we’ve noticed is: IAM programs are rarely successfully delivered without an IAM program committee.
Define scope for committee decision-making
The purpose of an IAM program committee is top-down decision-making and program governance. Often, IAM programs become plagued with indecision and disagreements, especially where business process changes are concerned, since multiple business units may be affected by the decision. When this happens, it’s handy to have a committee in place to settle disputes, allocate resources and make decisions.
But that’s not the only area of the concern for an IAM program committee, which also:
- Approves updates to the IAM roadmap: Typically, IAM programs are multi-year endeavors and corporate priorities can and do change. The committee should regularly review corporate goals and review if IAM roadmap changes are warranted.
- Communicates upstream: Bi-directional communication with company executives, typically the CIO (if the CIO is not part of the committee).
- Reviews metrics: Tracking IAM program metrics is critical to ensure the program is delivering the intended impact on the organization.
- Provides financial oversight: IAM programs may have a large budget, and it’s important for an oversight committee to ensure projects stay within budget.
Also document out-of-scope items
In addition to documenting in-scope topics, it is important to explicitly document topics that are out of scope. To prevent IAM steering committee overreach, day-to-day tactical decisions should be made at the IAM project team level (see the middle tier of the diagram above). Here are a few examples of topics that should be out of scope:
- Technical architecture: The steering committee may require, as part of IT best practices, that the enterprise architecture group to approve the IAM design document. While this is acceptable, it’s a tell-tale sign that the IAM steering committee is overstepping is boundaries.
- Line-item project plan reviews: The steering committee should avoid spending time pouring over each line of a project plan. Their focus should be at the strategic roadmap level (for example, deprovisioning for these 10 applications is expected to go live by end of Q1, etc.) rather than the level of project plan line-items (for example, the connector for AD is set to be completed in DEV by February 12).
Documenting both in-scope and out-of-scope topics is a relatively painless task for IAM steering committees that can provide invaluable guidance that maximizes the committee’s efficiency and limited time. So why not block off a few hours this week to write your IAM steering committee scope document?