July 1


Identity Management Series – Role and Rule Basing Part 5: Implementation and Cleanup

The final step in this month’s activity is to implement the roles and clean up any extraneous access that’s left behind. As in the previous segment, the distinction between enterprise and IT roles doesn’t matter, so I will generalize. The reason for this is that what you implement depends on your strategy – as defined in Part 3. You may be implementing full enterprise roles with all of the underlying IT roles defined, or you may be implementing IT roles only.

In either case, the process is the same.


There are two parts to implementing the new access for all applicable role members:

  1. applying the new access (it’s sometimes easier to just delete what’s there and start over rather than trying to compare as-is vs. to-be and adjust), and
  2. removing any extraneous access.

Care should be taken here – is that extraneous access indicative of another role, or just a relic from a past job function? Hopefully these situations have already been caught, but it might be useful to develop a process to handle issues like this – to ensure consistency and quality despite the 11th hour discovery. But it’s very important to do something about the extraneous access – if it really is just a relic, revoke it!

Before making any access changes, it is critical to clearly communicate with impacted users – let them know when the changes are going to be made, and whom to contact for help if anything goes wrong. Also be sure to pick a time that is convenient to the users (the week before year-end close activities is not a good time).

Setting up for future access requests

Applying role- and rule-basing to a group of people may change the way they request access in the future. Be sure to make the necessary changes to access request processes, and communicate this information clearly to the users.

The best approach is to post information about the changes in the same place where users request access. This is especially important when implementing IT roles only, and not full enterprise roles. The more clear the end-users are on what they need to request and what will come to them automagically, the better it will be for them in terms of satisfaction, and for the access services team in terms of workload.

Role and rule maintenance

Although roles will not change as frequently as the users who need them, they will change over time. At a minimum, a process should be put in place to review each role once per year or more often if something major happens, like a significant organizational change or a replacement or upgrade of a system. This is something that should be specified in the access control policy or standard. Ownership of this process should fall on the information security department, on a senior access administrator or (better yet) a role engineer. It’s also a good idea to maintain a network of business liaisons in each department that can alert the process owner if a change is needed off-cycle. Depending on the bandwidth of the people involved, this could be done all at once as a yearly effort, or a few at a time as part of a perpetual calendar.

Cleanup of obsolete permissions

When all of the IT roles and rules have been defined for all enterprise roles needing to use a particular system, there may be some leftover permissions that aren’t assigned to any individual or any role. It’s a good idea to remove those.

Extra credit (and waaaayyy out of scope)

One of the reasons why systems with really granular permissions end up with such a huge repository of permissions and groups is that new permissions and groups are created without any analysis of what’s already there.

To really do this right (time permitting, of course – yeah right!) the permissions assigned to each IT role should be analyzed for redundancy or excessive access and adjusted accordingly. Whether or not this is worth the time and effort will again depend on your specific circumstances, but if it’s a system that attracts audit and no one seems to know how the permissions work or what exactly they give, it’s a good idea. Also, if you’ve got mainframe users who require two or three IDs because their permissions won’t all fit on a single ID (I’ve seen this!), it’s definitely a good idea.

Action recap

This month’s exercise was to begin role- and rule-basing the organization to facilitate access request and granting:

  • Prioritize departments and identify enterprise roles in the target departments
  • Develop a strategy for designing IT roles (depth vs. breadth), and get to the to-be from the as-is, with help from the power users; remember to test each role thoroughly
  • Clearly document and obtain proper approvals for implementing the roles
  • Implement the roles carefully, ensuring proper communication with the affected users. Also set up processes for maintaining the roles going forward, and adjust request processes as needed.
  • Remove any leftover permissions that are not in use.

Next month, we’ll talk about hierarchies of information, and rules for maintaining those hierarchies.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.


You may also like

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Tired of feeling defeated on Friday?

Where the stack of work to get done is bigger than what got finished. You dread next week before the weekend even begins.

It doesn’t have to be this way.