Allow me to shed some light on one of the critical organizational aspects of identity and access management (IAM) that we come across often when delivering IAM consulting services to our customers: Organizations that fail to address the quality of content for IAM processes may struggle to gain the acceptance of their business users before they even roll out their shiny new IAM strategy to the corporation.

Most critical access governance processes have a core set of key requirements, including:

• Request and approval;
• Periodical access reviews (aka, recertification);
• Business role modeling; and
• Audit.

To set the scene before we dive deeper into those core elements, let’s explore in greater detail two common failures that can derail even the best-laid of IAM plans.

Failure No. 1: Considering IAM an IT issue

Some organizations still consider identity and access management to be a technical topic for the IT team and do not make an effort to understand it from business users’ point of view. Including business stakeholders is generally a good practice when setting up IAM programs, but it’s equally important to present the content to business users in a way that is meaningful to them so they can perform IAM tasks.

Have you ever asked a business manager to review a set of access rights for their teams? If so, did you hand them the raw extract of access rights that you pulled from your IT systems?

If you were lucky, the manager kindly asked for an explanation of the presented data. In many cases, I have seen managers refuse to work with these reports — and they have my full support in doing so because they are simply not presented any information they can work with.

Failure No. 2: Presenting Low-Quality Content

The quality of the content presented to users is mission-critical, as in all IT projects. For IAM, this means describing the access rights in a suitable way that a business user can understand.

Instead of exposing information such as, “User A71239 is assigned to system SAP-P20 and has XPA_PRD_Z120_JBS_CZUP, XBAC_PRD_ZXY_UASDIUX…” — and hundreds more with similar technical labels — a core recommendation is to present a business-readable description of the access rights granted by assigning these objects.

But how do we to get there?

How to Document Access Control Structures

When introducing access governance, organizations should maintain documentation of access control structures for each business application. As noted above, the key objective of this exercise is to provide business managers with the information they need to understand the access rights they need to manage. Other stakeholders for this content are internal and external audit, the team working on business roles, and simply each IT user in the organization.

To draw a line here, I will not address building a business role model. My aim is simply to create the basis for understanding technical access rights from a business user perspective.

Access control structures address the functionality and content used for access control pertaining to a given business application. Other terms, such as authorization matrix, access catalog and entitlement structures, are used in a similar context. It doesn’t matter what you call it, but it should comprise all required information to interpret the access rights.

This includes the following information to define the context of the business application:

• Application name
• Business purpose of the application
• Business owner
• Technical owner

Next, you need to understand how this application enforces access control technically. We call this an access control model, which addresses:

• Directories, databases and other repositories used;
• Functions used for access control; and
• Description of all parameters evaluated by the application to decide on access.

Now that we understand how access control technically works for the application, the next step is building an access catalog, which looks at each object we use for controlling access. This might comprise of set of composite roles in a SAP system, a set of Active Directory or lightweight directory access protocol (LDAP) groups, Resource Access Control Facility (RACF) authorizations, some legacy parameters in custom-built applications, or a combination of objects across several technical platforms used for a certain business application. For each object some key information must be maintained, including:

• Business-readable name;
• Business-readable description of access rights;
• Technical name of the object;
• Directory where it resides;
• Business owner of the object (often referred to as “data owner”);
• Technical owner of the object;
• Approvers to review requests for this object; and
• Applicable assignment rules on object level (e.g., separation of duties).

Life Cycle Processes for Access Control Structures

This exercise can’t be a one-time-effort; it must become a regular process. A good approach is to define life cycle processes to create, maintain and decommission access control structures for business applications and embed these in change management processes. Key factors to consider include:

• Responsibility for maintaining access control structures;
• Required approval flow for changes, including business, technical and editorial review; and
• Procedures to publish the changed access catalog for use in IAM processes (e.g., request and approval, periodical access review, business role management). This includes importing the content into the catalog of identity governance and administration (IGA) components.

Depending on the starting point of the organization, creating and maintaining access control structures in defined life cycle processes may seem like an extensive and tedious task. But I assure you, it’s worth the effort.