Building a value framework for Identity

In the first blog in this series, I talked about how to build a business case for implementing a new Identity and Access Management (IAM) solution, though the principles involved are general ones that can be applied to any technology purchasing or services procurement decision.

Here, I’ll take a deeper dive into one of the five steps in building a business case. This step entails describing the “today” or “as-is” state, whilst setting it in relation to the desired or “to-be” state.  

Modern identity solutions can automate and streamline many operational processes that are still being done manually in most organisations around the world. These processes tend to be integral to essential business functions, impacting productivity, sales, revenues, and more. For this reason, IAM modernisation provides an especially salient example of the kinds of time and cost efficiencies that can be achieved when legacy systems – particularly ones that are deeply integrated into core business processes – are modernised.

Pointing out these efficiencies in a logically rigorous fashion – and quantifying the costs and benefits involved to the extent that it’s possible to do so – lies at the heart of an effective business case.

What is a Value Framework?

In essence, a value framework outlines in explicit terms how the proposed investment will deliver value to the business. It elaborates which specific changes the project that you’re building a business case for will bring about, and how those changes will translate into cost savings, revenue increases, or other benefits.

Value frameworks often consider four key areas that could be improved by completing the project. These are:

  • direct costs
  • productivity and user experience
  • security, and 
  • revenue.

A value framework should describe what the project will achieve in each of these areas in quantitative terms whenever possible.

To show what this looks like in concrete terms, I’ll use automating the Joiner, Mover, Leaver (JML) process as an example. The JML lifecycle is something that every business needs to manage, since every company hires and sheds staff on an ongoing basis. It’s also a common pain point, and one that can contribute significantly to costs and cybersecurity risks.

Let’s jump right into the first area.


In the as-is state (i.e., before automating the Joiner, Mover, Leaver process), all provisioning is done manually. Whenever a new hire joins the company, a multi-step data entry process is set in motion. First, the employee is entered into an HR system. HR typically also generates a ticket (usually in a system like ServiceNow or Jira) to let IT know that they need to enroll that user into a directory. 

Depending on their role, the new employee will need access to certain software applications. Those that are essential from day one are called birthright apps. An IT team member might have to discuss which apps fall into that category with the hiring manager or HR department. Most employees in most roles use only five to 15 applications per week, which provide core capabilities like video conferencing, email access, document creation, file storage, and time and expense management. Of course, there are also specialised apps that only employees in certain roles need — GitHub for developers, Tableau for business analysts, etc. 

“Movers,” that is, employees who are switching roles, will initiate a similar process, in which supervisors and HR team members discuss whether access to additional tools is needed. When access is provisioned manually, grandfathered access is very common. This takes place when employees accrue access to more and more applications the longer they’re with the company, adding apps as they switch roles or add responsibilities, or as the company acquires new software. Not only does grandfathered access increase security risks, but it can also add costs if the business ends up paying for unneeded software licenses. 

Finally, “leavers” – those departing the company – need to be removed from the directory or made inactive within it. And their access to individual applications needs to be removed as well. In practice, it’s all too common for this de-provisioning process to happen far too slowly, or not at all.

The very first step in the JML process can’t easily be automated. HR’s initial entry of the new hire’s information into the system will need to be performed by hand for the foreseeable future. Thus, I’ll start with ticket creation when considering the costs of manual provisioning. This might take 10 minutes for each new hire. Then, manual entry into the directory might take another 20 to 30 minutes. 

Let’s take a company with 1,000 employees as an example. This company might not be growing very fast, but they may still have 150 employees joining the organisation each year. Setting up each of these new hires in the directory will take an average of 30 minutes, but we’ll also have to consider job role changers as well. That might increase the number of requests to, say, 165. This means that more than 82 hours per year will be spent on this part of the provisioning process.

And this doesn’t include application access provisioning, which is typically more time consuming. Let’s imagine that each user has access to 10 different apps, and that application provisioning takes 30 minutes per user. A 1,000-person company might have 1,500 provision requests per year. This company would be spending 750 hours per year on application provisioning. Add this to the time spent making changes to the directory, and you’ll find that these activities are taking up nearly half of one full-time employee’s working hours.

In actuality, this work is usually shared across a team, which could be made leaner – as well as faster and more effective – if there was no need to spend time on these manual tasks.

Productivity and User Experience

Whether employees’ technology experiences are largely positive or negative isn’t something that can easily be quantified. Still, it can have a major impact on retention, as well as how happy and productive people are at work.

What can be quantified is the impact of slow provisioning processes on how much employees are able to accomplish. It’s not atypical for it to take a week or more for businesses to give new hires access to the IT resources they need to get their jobs done. 

Going back to our fictitious 1,000-person company with a 15% employee churn rate each year, you’ll have 150 new hires each losing a week of productivity. With 15 additional employees changing roles, and assuming there are 40 hours in the work week, the company will have lost a total of 6,600 hours of productivity by the year’s end. 

Imagine that the average employee’s wage is $39 per hour, including benefits. This will mean that the company is wasting $257,400 on an annual basis because of this lost productivity.

In reality, this figure doesn’t capture the full extent of the losses. Some new hires will in fact need training before they can become productive, while others can get started right away. Some may be working on a per-project or contract basis at much higher hourly rates. The cost of delaying contract developers’ access to the tools they need to get their jobs done is astronomically higher, for example.


While it’s impossible to predict the exact costs that might be associated with a breach or major cybersecurity event that occurs as a result of a company’s failure to terminate account access as soon as employees depart from their roles, we do know that data breaches continue to become more costly. IBM Security’s 2022 Cost of a Data Breach Report reveals that the average cost of a breach reached a new all-time high of $4.35 million in 2022. 

We also know that internal bad actors are capable of doing far more damage, more quickly than external attackers. And we know that departing employees are more likely to be disgruntled than those that are planning to stay in their roles. Recently laid-off or involuntarily terminated workers might steal or expose sensitive data or try to harm the company to get revenge.

In one recent example, former employees of a major international financial services organisation retained system and email access for several weeks after their jobs were terminated. During this period, one departing employee send 450 messages to the company’s clients, asking them to follow her to her new role with a competitor.

Easier to calculate are the costs associated with excess software licenses. Most application vendors bill on a per user, per month basis. The longer it takes to offboard users, the more money will be wasted on unnecessary licenses. If it takes two months to remove accounts that are no longer needed, that will increase annual licensing costs by more than 20% over what they should be.


Revenues might be the hardest element in a value framework to describe in quantitative terms, but it might also be the most important. How much revenues are lost – or never earned – will vary enormously depending on the employee’s role and what projects they’re working on. If developers who are building a revenue-generating application ramp up more slowly, and that delays the software’s release, the associated revenue losses might be enormous. Or imagine a member of your sales force. What’s that person’s monthly closing target for that given year? How many major deals did they miss while waiting for access to an application? 

In certain industries (like e-commerce) it’s nearly guaranteed that the company will earn less every day that its website’s not performing optimally. Which employees, in which roles, contribute to optimising that site’s performance?

The To-Be State

Once you’ve outlined the costs and pains associated with the “as-is” state, you’ll need to compare them with the investment required to implement the new solution. 

This calculation should take into account the total cost of ownership (TCO) of any hardware or software that you’ll be replacing. Because modern Software-as-a-Service (SaaS) companies maintain the infrastructure on your behalf, keep the software updated, and guarantee uptime rates, all you’ll need to worry about with a new SaaS solution is licensing and deployment. This may result in significant cost savings, especially when compared with legacy on-premises applications.

What I’ve been describing here is simply a framework. You can look at nearly any business problem or pain point in the same way – whether that’s password resets or protecting your customers against online fraud – by considering it through the four lenses of cost, productivity/user experience, security, and revenue.

Regardless of the specific solutions involved, the goal should be to describe how the technology in question can enhance efficiencies, enable productivity, and make your business run better.


Learn more about why you should consider Okta for your security and identity needs and how you could start building a business case for this by clicking here.