Most identity and access management (IAM) products and services don’t provide real value until they are integrated with applications. And while today’s IAM leadership spends significant resources on these integrations, prioritisation can be difficult. However, a formal IAM prioritisation model ensures alignment with corporate priorities and allows transparency with stakeholders, and it does not need to be complex. In fact, to encourage effective execution and communication, it should be simple.
Note that prioritisation decisions have broader applicability than just IAM products. Prioritisation is also useful during role engineering and privileged access management (PAM) initiatives, for example. No matter the type of integration, a company needs a business-oriented way to prioritise its applications.
We recommend a simple prioritisation model based on risk, impact and friction. The model described below shows the criteria used to evaluate applications in each of these areas, as well as a starting point to determine the relative weight of these drivers.
Without an effective strategy in place, the organisation might consider only one side of the business at the expense of another, or only one driver to lead the integration, which could hinder the integration process in a number of ways. The applications selected might not be the most important to the business as a whole, and/or the users who interact with these applications might not have the bandwidth to add another project.
Some foundational insights about enterprise applications are required for any effective prioritisation model. These elements do not have to be perfect, but the effectiveness of the model depends on their maturity. Insights on the technology, usage, risk and compliance requirements for applications are required to score individual applications. Typically, this information is tracked in an application inventory, but for smaller organisations, that step may not be necessary. As a prioritisation model is established, however, maturing these insights may be required. The visibility of a transparent prioritisation model will also often naturally improve application insights as application owners understand their impact.
Some foundational insights about enterprise applications are required for any effective prioritisation model. These elements do not have to be perfect, but the effectiveness of the model depends on their maturity.
Know Your Drivers
The three most common drivers of prioritising applications include risk, impact and friction.
Prioritisation by risk considers all the applications at the enterprise and prioritises applications with the highest risk designation. Multiple factors contribute to such a designation. The first is data classification, which considers data points such as personally identifiable information (PII), protected health information (PHI), Sarbanes-Oxley compliance (SOX) and the Payment Card Industry (PCI) standard. All these data points have valuable classified information, which directly impacts the risk each application holds.
Proprietary information is another attribute that contributes to an application’s risk designation. Are secret formulas, processes or methods used or stored within an application that could impact the company’s success if the application were compromised? If so, any applications with trade-secret information should have a higher risk designation than others.
When defining risk designations to applications, the IAM team should use data that is already being collected. For example, companies should already be capturing risk designation points through disaster-recovery or business-continuity plans. These plans should serve as a starting point for the IAM team to score applications based on risk.
Prioritisation by impact scores applications according to their influence to the organisation. For example, which applications are the most critical to run the business? Which applications are used by the majority of the organisation? Which applications create the most manual work? Applications necessary for the business to run effectively should hold a higher impact score.
Prioritisation by impact also takes into account manual intervention needed to support applications. Do users constantly require assistance with the application? Does it take a long time for users to gain access to the application after the request has been made? Applications that have a high service-request volume could benefit the most during integration and may have a high impact on the enterprise.
The last driver, friction, scores applications by the ease of integration from both a business and technology perspective. For this driver, off-the-shelf applications are more easily integrated and hold a higher priority than homegrown applications. Applications that have a simple technology stack consisting of fundamental software products and programming languages make integration more fluid; by contrast, legacy or unsupported applications often cause more complications due to outdated technology.
Similarly, prioritisation on the basis of friction must consider the cost of integration. Does the organisation have the funds to integrate all applications, or do budgetary limits necessitate selecting some applications but not others? In turn, large legacy applications would yield a higher cost of integration, resulting in an increase in friction.
Prioritisation by friction also considers current business goals and needs. For example, when a division at the enterprise has multiple ongoing projects, applications that map to these projects could pose more resistance and slow the integration process. In addition, stakeholders focus on more essential applications, resulting in less friction during integration.
In addition, friction considers the culture of the business. What are the political relationships within the organisation? Will the IAM team have difficulties based on how the division or organisation works? If employees are not willing to be advocates for the application-integration process, or do not have the time to do so, the IAM team will face a more strenuous and prolonged process.
The ease and cost of integration, along with the goals and culture of the business, all come together to help form a way to prioritise by friction.
These three drivers — risk, impact and friction — cover most cases. However, individual organisations may have additional drivers, or a custom set of drivers, tailored to their unique business needs. In any case, once the business understands all their drivers, it must score each of the applications against the drivers from low to high. Once the company has developed an effective scoring system, it can assign relative weights to the drivers when it comes time to pick a strategy. Note, too, that it is important to score the drivers in order to evaluate all possible strategy outcomes before choosing a strategy. See the graphic below for an example of a scoring strategy:
Pick a Weighting Strategy
After the IAM team understands how its applications score among the drivers, it should pick a weighting strategy that reflects the organisation’s unique business needs and goals. Each strategy applies a different weight to the three drivers and generates an application prioritisation list. The IAM team and key enterprise stakeholders should agree on the strategy the organisation utilises. Below are some sample strategies:
The remediation-driven strategy prioritises applications with the highest risk score — applications most dangerous to the company in the event of a disaster or a breach to the application. With this strategy, risk would hold the most weight out of the three drivers.
This strategy focuses on the applications with a high score in impact and a low score in friction. These applications will not only have a timely integration process; once integrated, they will also have a significant effect on the company. With this strategy, the IAM team would assign more weight to the drivers’ impact and friction while using risk to determine a logical order if multiple applications share a similar score.
The efficiency strategy considers the applications that have the highest impact score. Once integrated, these applications will affect the majority of the organisation. For this strategy, the IAM team assigns the most weight to the impact driver.
After the organisation has selected a strategy and scored the drivers, it is beneficial to step back and take a holistic view of the process. Are business needs lining up with the integration of applications, or should the strategy scale be changed? As the enterprise goes through the integration-prioritisation model, it will learn which weighted scale works best for the organisation moving forward. The graphic below outlines the constant learning and improving process companies face while utilising the integration-prioritisation model:
Utilising an integration-prioritisation model helps the organisation make business-centered decisions for IAM projects. Rushing into an integration project without careful consideration can lead to many shortcomings — a company’s integration may fail or be incomplete because it didn’t consider all the drivers. Similarly, stress can occur if members of the organisation feel they don’t have time for another project or if the IAM team chooses the busiest time of the year to add another project. In addition, the company could be left with a misallocated budget because it did not correctly forecast an integration timetable. However, following a defined strategy for prioritising application integration allows the organisation to extract maximum value for all its integration projects, resulting in a more smoothly run enterprise.