Comment on page
KPIs for IAM Teams
A practical guide for measuring performance of your enterprise identity and access management program
Identity and access management (IAM) is a critical function of any security and IT organization within an enterprise. Its primary role is to ensure that the enterprise’s assets are readily and easily accessible to the authorized users within or adjacent to it.
As organizations seek to build and mature their IAM program, establishing a robust and durable set of key performance indicators (KPIs) is a critical step in ensuring that the performance and efficacy of the program can be adequately and consistently measured.
Every enterprise is organized differently, but generally speaking, IAM-related KPIs can be broken into three areas: Governance/Compliance, Operational, and Security. Naturally, these functional areas are aligned to the goals of the IAM program and the enterprise at large. Security keeps it safe from identity-related threats. Operations keeps the lights on and makes sure processes are running smoothly and efficiently. Governance/Compliance makes sure that policies and technical controls are in place, monitored, enforced, measured, and reported.
With these three functional areas as the organizational framework, here are some baseline key performance indicators that IAM leaders should consider focusing on and measuring. With these fundamental indicators as a starting guide, enterprise IAM leaders can develop and curate a set of measures that are tailored to their organization’s unique technology environment and business objectives.
These KPIs measure an organization’s performance against their regulatory obligations, such as Sarbanes-Oxley (SOx) or PCI DSS, or against their own audit standards.
% of test controls with no control deficiencies
# SOX testing cycles with no IAM-related significant deficiencies
# of non-unique and/or shared IDs
% of access granted with all necessary approvals formally documented
% of roles or entitlements compliant with Segregation of Duties (SOD) requirements
% Accounts disabled within SLA for terminated users" or something similar
When it comes to compliance, one thing to keep in mind is that not all frameworks are prescriptive. In many cases, the controls themselves are up to the organization to define, implement, and measure against, and many unregulated organizations elect to use SOx-like controls to hold themselves to a high standard. Whatever the case may be, auditors will hold you accountable to the controls you define.
Using SOX as an example, below is a simple controls list that you can use as a baseline for compliance and measuring KPIs. Note that ‘X’ usually carries a value of ‘24’, but you can use a larger or smaller time frame based on your organization’s requirements and readiness,
- 1.Accounts for terminated users must be disabled within X hours of the user’s last day of employment
- 2.Accounts may not be provisioned unless documented, formal management approval has been obtained
- 3.Access must be periodically reviewed by authorized individuals to ensure it is still appropriate
- 4.Accounts must be disabled within X hours if deemed inappropriate/not needed during the Periodic Access Review
- 5.Applications must define entitlements that, if granted, would create Segregation of Duties concerns (aka ‘toxic combinations')
- 6.Access may not be granted if it creates an SOD violation, unless compensating controls are implemented
These KPIs seek to measure the performance of the operational functions within the IAM program and team. Examples include:
% of access requests fulfilled within SLA
% of access requests fulfilled accurately
# of Periodic Access Reviews completed within SLA
# of access revocations completed within SLA - as a result of the Periodic Access Review
These KPIs measure the security functions within the IAM program and team. Examples include:
% of access removed within SLA upon employee termination
% of user accounts configured to use Multifactor Authentication (MFA)
# of privileged accounts with unvaulted credentials
# of privileged accounts with unknown owners
# of applications leveraging centralized directory accounts
# of service accounts with unknown owners
SLAs or “service level agreements” are policies set by an organization as a measure of time by which an action will be performed. Setting SLAs for your IAM organization is essential to holding your team accountable and to set expectations across the enterprise with regard to the delivery of IAM tasks.
Seeing who has access to what and what they’re doing with that access is paramount to IAM success. Without persistent visibility into the identities within your organization, you are quite simply flying blind. After all, you cannot effectively manage what you cannot see.
A major challenge in IAM is the fact that for every identity, there is often some logarithmic function of downstream attributes automatically associated with it. For example, one person leaving the company may actually spawn dozens of actions for the IAM organization to remove individual accounts across a multitude of applications used by that departing employee. This is where the trouble lies. While you can never have too many qualified bodies in an IAM team, you need automation to keep up with this enterprise identity sprawl.
In a perfect world, each identity on a network would have the perfect level of birthright access from day one and seamless just-in-time, just-for-now access to the specific resources they need at any given moment. If this scenario sounds familiar to you, it is likely because it is indeed the essence of the elusive “zero trust” model that so many organizations are seeking to achieve and investing so heavily in. True “zero trust” only exists in this imaginary, perfect world, and even then, it’s easiest when you start from scratch. What a luxury that would be. Nevertheless, when it comes to compliance controls, the expectation is that of perfection when the auditors come knocking, so you need efficient, repeatable processes to thrive in IAM.
The reality on the ground inside many enterprise organizations is that identity and access management is far from perfect. You are not starting from scratch; you have thousands of users who expect the availability of resources and to be able to fulfill their roles and responsibilities. Access policies, entitlements, and group memberships can vary between systems for the same user, so both wide-angle and telephoto visibility are essential to success in IAM.
Measuring the performance of your IAM program does not need to be painful. Start with defining your controls, attach the KPIs that align with your goals, and commit your team to some SLAs. Measure these at a regular cadence and you will be well on your way to achieving IAM success by remediating vulnerabilities caused by identity blindness and sprawl.