How often has a customer sat waiting on an access request, only to discover that it was delayed because the approver left the company and there was no replacement? This is an all-too-common scenario, and one that can be handled with vacancy management. If all of the data/access approvers (owners) can be identified, they can be tracked. Then, as with the line management hierarchy, all thatâ€™s needed is a workflow and voila! Management!
Properly managing data and access ownership is important not only from a compliance perspective – ensuring that the right people are approving access to data at any given time – but also from a customer service perspective. It doesnâ€™t do the company any good to have people not being able to do their job because their access request has stagnated, nor does it do anything for the reputation of the access services team. Although itâ€™s not the access services teamâ€™s fault that the vacancy didnâ€™t get reported, they will bear the brunt of the complaints and blame.
The good news is that there arenâ€™t that many data/access owners in the enterprise, relatively speaking. Itâ€™s really a small percentage of the total body of users. So then why has it been so difficult to manage historically?
Data and access ownership are typically minor components of someone’s job, so when they leave it’s not the first thing that comes to anyone’s mind – “Oh! Johnny left the company and he was the approver for ad-hoc batch job access â€“ he approved 3-5 requests per month. We need to make sure to assign a replacement for that!”
Typically, this is discovered when an irate employee wonders why his request has been sitting around for three weeks with no action. Then it’s a scramble to figure out who should decide who Johnny’s replacement should be.
This segment is about managing vacancies in the data/access ownership arena, to ensure that these vacancies are proactively managed, rather than reactively. We’ll again work through this hierarchy using the five steps I outlined in the Approach section of this month’s Introduction segment.
Step 1: Determine the needed granularity
As with the line management hierarchy, granularity speaks to ongoing management. If your service catalog has hundreds of services, each with its own approver (that is not the requestor’s line manager), it would take hundreds of entries in role manager to account for every last approval role. This becomes difficult to manage.
If there is a centralized service catalog with workflows that auto-route requests to the right approvers, the good news is that there is an easy way to determine which individuals approve what access â€“ just ask the service catalog administrator.
So it may be sufficient to create one role, “data owner” or “access approver.” Or, if the catalog is big enough, maybe narrow it down and create one role per category, such as “UNIX access approver,” “Windows access approver,” “Database access approver,” and so on.
Step 2: Collect available data
Again, if there is a centralized service catalog system, the data (who approves what) should be fairly easy to collect. Even in the absence of a system, it’s likely that the access services team at least maintains some good spreadsheets – otherwise your organization has much bigger issues that managing vacancies. 🙂
Step 3: Obtain missing data
Even if Step 2 yields good, comprehensive results, thereâ€™s still one thing missing: the roles of the individuals who should fill the vacancies, and this is not a trivial analysis to undertake.
If Johnny leaves the company, should it be his line manager that decides who takes on his approver role, or should it be someone else, like the owner of the system that runs the ad-hoc batch jobs that Johnny was approving?
It’s important to ensure that the information collected on filling vacancies matches with the roles created previously. If there’s only one role defined (e.g., “access approver”), the vacancy has to be filled by the line manager, because there isn’t enough information to determine a system manager. If the roles are set up by category, then it might be possible to deduce who the system manager is based on roles.
Another missing component here might be missing approvers – it’s possible that the approver spreadsheets or service catalog records contain approvers who no longer exist and have already left vacancies. These need to be filled as part of the data gathering process.
Step 4: Design the workflow
The first step of the workflow depends on the granularity of the approval role. If there is only one role, then the workflow is done â€“ use the line manager workflow.
If there are a handful of generic roles, the first step in the workflow will be a task to the service catalog administrator or access services team to identify what approvals the individual performed. Then a task can be routed to the person authorized to specify a replacement.
If each ownership type has its own role, then the workflow can route a task directly to the role identified as having authority to specify a replacement.
The latter two scenarios lead us to the second possibly tricky part of the workflow: let’s say that the system manager is asked to replace Johnny, but the system manager role is also vacant. Does the request go to the system manager’s line manager, or to someone else?
Whereas the reports-to hierarchy presented problems with data collection, but the workflow creation was straightforward, the opposite can be expected for data/access ownership. There aren’t *that* many data owners/access approvers in any organization, so getting the list won’t be that difficult. But getting agreement on who is authorized to fill vacancies and how the workflow handles additional upward vacancies can take a while – it will involve potentially different people for each role, and possibly significant discussion.
Part of the discussion also needs to include default actions – how does a pending approval get routed if the vacancy has not yet been resolved?
Step 5: Notification
The two groups most in need of data/access ownership changes are the access services team and the service catalog administrators.
Since the number of changes is relatively small (as compared with reports-to) and since the number of recipients is also fairly small, sending email notifications is more reasonable in this situation, but still not ideal.
As with the reports-to workflow, the better solution is to create an additional step in the data/access ownership workflow, assigning a task to the two groups, requiring them to update their respective information.
The best solution, of course, is still system integration, which again may be fairly simple and inexpensive if the approval information is already stored in an LDAP-compatible repository. Since identity management can easily integrate with such a repository, automated update would be highly achievable. If the data is stored in spreadsheets or if the service catalog repository is proprietary, automation is likely not possible (or cost prohibitive).
In the next segment, we’ll develop the cost center ownership hierarchy and workflow.