On creating an IAM governance body
On creating an IAM governance body
Out of all the disciplines of IT security, identity and access management (IAM) is known for being notoriously complex -- and for good reason.
Deployments are fraught with unforeseen complications, such as dirty data, poor business processes and "project scope creep." However, out of all the factors that can make or break an IAM deployment, apathy concerning IAM governance is perhaps the most significant. In fact, proper governance is so critical to the success of IAM programs that a whole new sub-discipline -- IAM governance -- is emerging as a standalone practice.
IAM governance is the establishment and management of policies, processes and accountabilities for core IAM functions, such as defining roles and entitlements, and managing approvals for access requests. It concerns the oft-neglected people and process legs of IT, and is critical to the long-term success of any IAM deployment.
Based on feedback we've received from over 100 IAM projects, it's abundantly clear that the organizations that have taken the upfront time to set up an IAM governance body prior to detailing the specifications of the solution are typically far more successful than those that play it by ear.
An IAM governance body is a group of individuals who are collectively responsible for creating organizational IAM policies, establishing authority to see and execute those policies to fruition, and gather feedback from the field to tweak any misaligned policies. It goes beyond simple executive sponsorship for your company's IAM program.
Here are four guidelines that could provide your organization some direction while thinking about IAM program governance.
Establishing the need
The first step is to ask yourself if you really need a governance body. The answer is pretty simple: If the “project” is long enough to require a vision and a roadmap, then it's probably not appropriate to call it a project. You most likely have an IAM program on your hands that will become a permanent feature of your organization. If this is the case, establishing a governance body will be a tremendous help.
Defining a framework
The optimal time for defining who's who in your governance body is once your organization has laid down a vision and roadmap for your IAM program, delineated its scope, and have identified drivers and related key use cases. While detailed requirements would still have yet to have been defined, it is still the opportune time to communicate roles and responsibilities to the main stakeholders.Recruiting supporting members
As functional specifications are being drawn up, it will be important to recruit the appropriate supporting members. If key members are the legislative component of the governance body, then supporting members constitute, albeit not exclusively, the executive component.
Supporting members are the closest to the action, and are responsible for things such as educating their respective constituencies regarding SLAs and process changes, enlisting executive aid where necessary, and putting the IAM policies into action.
Meetings and maintenance
During the functional specifications phase of the program, it will be important for the key members of the governance team to promptly make appropriate policy decisions as needed. Because of this, we suggest a small group (two to three members should suffice) meet weekly or bi-weekly with the functional specifications core team, as various IAM policy questions arise.
Toward the end of the functional specifications phase, the technical supporting members of the governance body should be identified in preparation for the technical requirements and design phase of the program. It will be their responsibility to work with the key members in order to define operational issues, identity data management policy, and other technical standards within the organization.
We've found that in most cases, this framework is effective. It may need to be adjusted to suit the needs of your organization, but the bottom line is that proper governance can make or break any IAM program -- so why not do it right?