IGA Capability: Identity Analytics and Reporting

Last modified 20 Feb 2024 12:13 +01:00

Alternative names

  • Identity analytics (IdA)

  • Identity analytics and intelligence

  • Identity intelligence

Identity Analytics and Reporting Functions

  • Customizable reports and visualizations. Reports, selecting and summarizing identity data. Customization of report structure and look. Structured machine-readable reports, aimed at post-processing. Dashboards, providing quick data overview. Visualization, presenting the data in interactive, human-friendly form.

  • Risk assessment. Definition, maintenance and automatic evaluation of risk model based on identity data. Evaluation of overall risk levels, per-user risk levels, and risk-based analytics.

  • Risk-based triggers. Triggering events based on risk analysis, such as initiating remediation actions, microcerticications and notifications. Using risk information in processes, such as approval processes.

  • Anomaly detection. Detection of data that stand out from their surrounding (outlier detection), such as users that have different privileges than their colleagues. Detection of suspicious combination of privileges, such as detection of over-privileged users.

  • Compliance management. Organization of policies that represent compliance frameworks, evaluation of compliance levels, identification compliance violations. Monitoring progress of compliance (addressing policy violations). Partial enforcement of policies (enforcement modes), allowing gradual introduction of new policies. Evaluation and reporting of policy compliance. Initiating remediation of policy violations.

  • Simulation. Simple preview of an effect of change (number of changed objects). Large-scale simulations, estimating results of many changes on many objects (such as role model changes, re-organizations). Thresholds, stopping operation if number of changes is unusually high. Interactive "what if" analysis.

  • Role mining. Suggesting role definitions by analyzing similarities in attributes and entitlements.


Responsibility of identity analytics and reporting capability lies mostly with analysis of identity data, summarizing and extracting relevant information, providing reports and dashboards, visualising identity information. Identity analytics dive deep into the data, considering identity data in context, using complex models to extract information. One of the most important information extracted from identity data is estimate of risk levels. The information extracted from identity data is used to initiate actions, such as starting remediation processes and triggering microcertifications.

Identity analytics and reporting capability can be roughly divided into two parts. First part is responsible for analytics, processing the data, compiling reports, using models to compute meaningful results, detecting situations that require attention and overall, providing insight into the identity data. Second part is responsible for triggering actions based on the data, raising alarm in high-risk situations, addressing policy violations, bringing attention to suspicious and unusual situations, suggesting improvements. The two parts do not have a strict boundary. In fact, they are usually entwined, built around common concepts and models, depending on each other.

The most basic requirement for data analytics is usually the ability to create reports. Almost all the IGA platforms have reporting functions, varying in sophistication and customizability. In the past, most platforms focused on printable reports, supporting various templates and style customization. Recently, the focus has shifted on on-line interactive reports, dashboards and visualizations, with an ability to export selected data in structured form for post-processing (e.g. in a spreadsheet processor).

Central concept of identity analytics and reporting is usually concept of risk. This makes perfect sense. Most identity governance systems work with an enormous pile of identity data. Some parts of the data are well-structured, clean, organized and strictly managed. However, such parts are usually quite small. Majority of the data are far from being clean or organized, and their management usually leaves a lot to be desired. There are data that we do not mind low quality, such as user-provided data used only for presentation purposes. However, there places where data quality is essential, such as data used for policy decisions. All the data are not created equal. It is usually not in the power of identity governance team to take care of all the data equally, to clean up all attribute values, to make a detailed review every single role assignment, to re-certify the assignment several times a year, to periodically review and update all roles definitions and policies. This would be an enormous task, even in a relatively small system with low user population. Identity governance team needs to prioritize the work, focus attention to serious issues, addressing them individually, postponing trivial issues, addressing them in bulk. Ho0wever, to do that, the team needs to know the difference between serious issue and trivial issue. When it comes to information security, there is often just one metric that drives all the effort: risk. The issue that poses high risk needs to be addressed immediately, focusing on the specific situation, considering all circumstances. The issue that poses low risk can be postponed, waiting for the time when it can be resolved efficiently in a group of similar issues.

Risk is a very useful concept. However, it is quite elusive and intangible thing. We cannot simply measure risk in standardized international units, similarly to measuring distance or time. Yet, risk can be measured, or rather assessed. Information security researchers are developing risk assessment models for decades. Even though the models provide just a relative estimate (assessment) of risk, they can tell the difference between high-risk situation and low-risk situation. That is exactly what we need to prioritize the work.

Some IGA platforms incorporate automatic evaluation of risk assessment models. IGA platform is an ideal place to make such evaluation, as it contains a lot of data to work with. IGA engine can quickly evaluate what is a (relative) risk posed by individual user, what department is accumulating high amount of risk, which business roles are granting dangerous combination of privileges. Such assessment can be used to identify the places where to look first. This is known as a risk-based approach to identity governance.

When high-risk situation is identified, the IGA platform usually triggers an action:

  • Notify responsible person (usually information security team).

  • Add additional approval step in access request process.

  • Initiate microcertification, as an attempt to lower the risk by removing unnecessary privileges.

  • Start remediation process, or create a case to resolve the situation.

  • Immediately disable access of high-risk user, to avoid imminent impact.

Overall, risk is a useful metric to watch over time. While absolute value of risk is almost meaningless, the dynamics of overall risk is interesting. Changes in overall risk level are important clues to plan identity governance and information security activities. It is important to watch for situations where overall risk increases, look for the cause and address it. Also, it is important to plan long-term activities to maintain or even decrease overall risk in time. As IGA platform can quickly compute identity-related risk from the data, it is one of the best tools in the information security toolbox.

However, the risk is complex, multi-dimensional concept. IGA platform can provide only one aspect of overall risk. There is no standard way how to compute risk, there are many models, and each model has to be customized for the needs of a particular organization. Moreover, risk modeling capabilities of IGA platforms vary significantly. Some platform have a hardcoded risk model that is almost impossible to customize. Other platforms expect you to implement the model yourself. Many products still do not have any risk modeling capability at all. However, even if risk modeling capabilities of IGA platforms are appropriate, properly customized for your 0organization, the result still depends on the quality of input data. Results of risk modeling can only be as good as risk assessment of "atomic" entitlements. This assessment has to be done manually, for every entitlement, as IGA platform has no practical way how to discover that risk level automatically. Even if the IGA platform can analyze all the low-level permissions, access lists, operating system privileges, database grants, algorithms and all the other details, the platform still cannot know how important is the information (know as asset in information security parlance) that the entitlement grants access to. Therefore, there is still a lot of manual work to do, even if you have the best and most sophisticated IGA platform. However, the work is worth doing. Risk-based approach to identity governance makes a perfect sense, and the investment will pay off in the long run.

Identity governance approach based on risk modeling is not a panacea. It has many limitations and assumptions, and the results are difficult to validate. Therefore, risk assessment is often supplemented with other methods. Such additional methods may be less systematic, yet they can detect issues that were missed by risk-based approach. Moreover, such methods provide more than just a reduction of risk. Some such methods can be used to clean the data and policies, to make the system simpler, improving maintenance efficiency and visibility.

Anomaly detection methods are popular, and often very efficient tools in identity governance toolbox. Such methods detect anomalies, users, roles and other objects that are unusual, that do not seem to fit among other objects in the system. Following methods are regularly used in identity governance systems:

  • Outlier detection: detection of users that have different access rights than similar users. This method works by analyzing similarities and differences between users. This method usually detects persons in organizational unit that have significantly different privileges than their colleagues. Similar method can be used to detect roles with unusual privileges.

  • Excessive access detection (detection of over-privileged users): detection of users that have very broad access. This usually means access to many systems, being member of many groups, users possessing powerful administration privileges and so on. Unlike outlier detection, this method does not compare similarities and differences, it rather looks for suspicious accumulation of privileges. Excessive access detection often provides the same results as both outlier detection or risk-based alerts, as over-privileged users usually both differ from their colleagues and the breadth of access creates significant risk. However, there may be users, or even entire departments, that have access to large number of low-risk entitlements. Such cases are not detected by outlier detection as the user group has consistent rights, and this may be missed by risk-based approach as the cumulative risk may still be relatively low. This method is also useful in case that risk assessment of "atomic" entitlements was not completed, therefore the risk model does not provide meaningful results yet.

The heart of identity governance is about the policies. Policies specify how things should be, what is the ideal state of all the systems and data. As organizations and regulations tend to be quite complex, policies are often complex too. Moreover, policies tend to change in reaction to changed regulations or organizational needs. All of that makes policy management quite a challenging thing to do.

It is an idealistic assumption that a new policy can be applied, and everything will comply immediately. When a new policy is applied, there will be many violations. Therefore, new policy cannot be enforced immediately. The policy needs to be specified in machine-processable form and the definition has to be used to identify the violations. The violations have to be addressed, only then the policy becomes enforceable. However, addressing policy violations is usually manual, slow and tedious process. The process has to be managed, progress has to be monitored, making sure that the compliance converges. Compliance reporting functions allow monitoring of compliance, identifying violations, monitoring the progress using charts and so on. Compliance reporting is not used just to bring a system to compliance. Not all the policy statements can be strictly enforced. Some policy violations have to be addressed by manual remediation, leaving the system in a state of temporary partial non-compliance. Therefore, compliance reporting is used all the time, to make sure that the system stays compliant and that all compliance violations are addressed.

Some IGA platforms provide pre-defined policies corresponding to common regulations, such as SOX and HIPAA. However, each organization is different, and compliance of each organization requires slightly different policies. pre-defined policies are an excellent starting point, however, their off-the-shelf applicability is questionable. Real compliance is very likely to require at least some amount of policy customization.

Complexity of policy definitions makes it often quite hard to predict the effects of policy and data changes. Simulation functions attempt to make such predictions. Simulation can be very simple, such as estimating the number of effected users when role definition is changed. However, more complex simulation capabilities are needed to get holistic and useful results. Simulation usually need to work on many objects at once, such as simulation of changes of the entire role model, simulation of many changes in organizational structure (re-organization events) and so on. Such a large-scale simulation usually cannot be computed in "real time", it may take several hours to compute the simulation. IGA platforms sometimes provide capabilities to automate simulations during normal operation. For example, an IGA platform may run simulation of a reconciliation process first, and stop execution of real reconciliation if number of changes is suspiciously high (a capability known as threshold). Some IGA platform provide a "what if" analysis capabilities, providing interactive capability to make smaller simulations quickly, usually simulations of changing a single role or policy statement.

Good role engineering is absolutely essential for many parts of the IGA system to work properly. If role structure is wrong, access certification process is going to take a huge amount of effort, and in the end it only makes auditing and certification processes much more demanding. If role structure is right, role assignments are easier to automate, approval and certification effort is reduced, and visibility is greatly improved. However, role engineering is a demanding process. It requires excellent knowledge about the organization, its structure and functions, and it is almost always burdened by historical baggage. Moreover, role engineering is not a one-off project, it is a perpetual process, maintaining and updating role definitions as organizational structures and requirements change. It would require a team of super-humans to do that - unless the effort is supported by the right tools. Analytics, in general, provide valuable insights for role engineering. However, it takes a specialized tool to make role engineering more efficient. Role mining functions are designed to analyze structure of attribute values and entitlements, identifying similarities and suggesting role definitions.

Identity analytics and reporting is essential to make sense of identity data. Insights gained by the analytics can be used to improve policies and processes, identifying problems and, most importantly, provide input to risk management processes. However, the data provided by analytics can be only as good as are the input data. Using analytics on invalid data can do more harm than good. If wrong information is fed to risk model, the output will be meaningless. Entire exercise will be a waste of time, a mere security theater. Similarly, role mining, anomaly detection, or even the most sophisticated "artificial intelligence" tools are useless if they work on wrong data. Reliable, first-hand information on user attribute values, group membership and other entitlements is required for identity analytics mechanisms to work. Therefore, identity analytics can be built only on a very strong identity management foundation, a platform that provides structured, reliable and up-to-date information, directly retrieved from the connected system (identity resources).


Risk assessment capabilities of IGA platform are limited to assess identity-related risks. IGA platform cannot evaluation complete risk for an organization. There are many aspects in a risk model that an IGA platform has very limited visibility, such as network security or physical security. However, results of identity-related risk analysis produced by IGA platform is a valuable part of organization-wide risk assessment.

Was this page helpful?
Thanks for your feedback