“What can users actually do if they have application role XY?”
The question should have been easy to answer. It was not.
A few years ago, I took part in a discussion between an application team and the central IAM team. The application owners could explain the individual access rights contained in the role, but they could no longer determine what their combination meant from a business perspective. The people involved in the original role design and application onboarding were no longer available, and the underlying design decisions had not been retained.
At the time, the organization was implementing a new IGA solution. The platform would provide better workflows, a central catalog, and improved governance capabilities. However, it could neither reconstruct the original business intent of the role nor determine whether its combination of access rights was still appropriate. Nor could it assign the missing lifecycle ownership.
The discussion highlighted an IAM challenge we still encounter frequently: the technology was available, but the work required to make it effective had not been clearly assigned.
This article examines seven situations that may initially appear to be technology limitations but are often caused by missing design, execution, or input responsibilities. For each situation, it shows what organizations should diagnose and where they can start.
Across all seven, three questions matter: Who defines how the process should work? Who executes and monitors it? And who provides the data, decisions, and business context required for it to work?
1. Audit Findings Return Despite Process Changes
What is happening?
An audit finding is closed after an additional report, workflow step, or mandatory field has been introduced. Twelve months later, the same weakness appears in another application, business unit, or location.
The individual process may work as designed, but the underlying control is not executed consistently across the organization. This is particularly common when centrally connected applications and locally administered applications follow different procedures.
What should be diagnosed?
- Who owns the control objective beyond the individual workflow?
- Who ensures consistent execution across central and decentralized processes?
- Whose input is required to achieve the desired control objective?
Where should organizations start?
Trace one finding from the control objective through process design and operational execution to the required inputs. This control-to-execution trace helps distinguish a missing report from a missing responsibility.
2. Access Reviews Complete Without Meaningful Decisions
What is happening?
The IGA platform creates the campaign, sends notifications, records decisions, and produces evidence. From a technical perspective, the review is complete. Nevertheless, reviewers approve access rights they do not understand.
The cause is not always unwillingness. Reviewers may lack understandable access descriptions, relevant risk information, or training on what they are expected to assess. A click-through guide can explain which button to press, but not what makes an access decision appropriate.
What should be diagnosed?
- Who defines the review criteria and expected decision?
- Who prepares reviewers and monitors the quality of their decisions?
- Who delivers the input a reviewer needs to make an informed decision?
Where should organizations start?
Perform a review-readiness check before launching the next campaign. Verify that ownership, descriptions, risk context, decision criteria, and reviewer enablement are in place before asking the business to approve anything.
3. Exceptions Lack Clear Decision Authority
What is happening?
Urgent projects, legacy limitations, regulatory variations, and management requests regularly require deviations from standard IAM processes. Several stakeholders may provide input, but no one is certain who can make the final decision.
Adding another workflow does not establish this authority. An exception may also create a permanently different process that must be implemented, operated, monitored, and financed. Many requests become less urgent once these implications are made visible.
What should be diagnosed?
- Who designs the exception process?
- Who may approve the deviation and accept the residual risk?
- Whose input is required to make this decision?
Where should organizations start?
Introduce an exception decision record containing the owner, rationale, implementation effort, operational cost, residual risk, compensating controls, and expiration date. This makes the full cost of the exception visible before it is approved. The decision should then rest with a body of IAM stakeholders who hold the relevant authority for budget, architecture, and operations.
4. Applications Are Connected Without Defined Ownership
What is happening?
Connecting an application to an IGA platform enables provisioning, request routing, and access reviews. It does not establish ownership of the application’s authorization model.
The IAM team can define onboarding standards, offer standard IAM processes and manage technical integration. However, it usually lacks the application knowledge required to define the business meaning of access rights. Application owners, in turn, may understand individual access rights but no longer know why they were combined into a particular role.
Ownership also does not end after onboarding. Access descriptions must be maintained, new access rights introduced, obsolete ones retired, and access roles reviewed when the application or business changes.
What should be diagnosed?
- Who owns the application’s authorization model and its business meaning?
- Who maintains descriptions for access rights?
- Whose input is required to create meaningful and business-oriented descriptions of the access model?
Where should organizations start?
Define an operational application ownership model rather than assigning an owner only for onboarding. Central IAM should support application owners with templates, training, quality criteria, and escalation paths without taking over their business responsibility.
5. Lifecycle Automation Compensates for Poor Source Data
What is happening?
Automated identity lifecycle processes depend on accurate and timely source data. When HR events or attributes are incomplete, delayed, or inconsistent, organizations often add correction logic to the IAM platform.
This may keep the process running, but it shifts responsibility away from the authoritative source. It can also create different versions of the same identity data in HR and IAM.
What should be diagnosed?
- Who defines which events and attributes IAM requires?
- Who is responsible for delivering the required data on time and at the expected quality, and for correcting errors?
- Whose input is required to achieve the desired process goals?
Where should organizations start?
Establish an identity data contract between HR, IAM, and the relevant business stakeholders. It should define required attributes and events, their meaning, delivery timelines, quality expectations, and responsibilities for error resolution.
6. Provider SLAs Are Green While Control Outcomes Are Not
What is happening?
A provider may meet every agreed SLA while the IAM control still fails. The platform is available and tickets are processed on time, but access remains incorrect because application information is incomplete or business decisions arrive too late.
Availability and response times measure provider performance. They do not automatically measure input quality, decision quality, or the effectiveness of the end-to-end control.
What should be diagnosed?
- Who defines the service levels, control objectives, and indicators used to measure them?
- Who monitors SLAs, KPIs, and control effectiveness indicators and who acts on deviations?
- Who provides the customer inputs and business decisions required to achieve the expected control outcome?
Where should organizations start?
Create a responsibility model for each IAM service. Use a RACI matrix to assign provider and retained customer responsibilities for key activities and decisions, and document required business inputs, dependencies, and expected control outcomes alongside it. Together, these elements provide the baseline for the service measurement framework.
Outsourcing execution does not transfer accountability for IAM effectiveness.
7. Manual Processes Break End-to-End Control
What is happening?
Manual IAM processes are not automatically ineffective. They may be appropriate when integration is not feasible or when human judgment is required. The risk arises when handovers are informal, process status is invisible, evidence is inconsistent, and completion depends on individual knowledge.
Differences between centrally connected and locally administered applications are a frequent source of inconsistent control execution. Decentralized processes therefore need to support the same control objectives, even when their execution remains manual.
What should be diagnosed?
- Who designs the end-to-end process, including where automation ends and manual intervention begins?
- Who performs, documents, and confirms each manual step?
- Whose input is required to achieve the desired process goals?
Where should organizations start?
Trace one real transaction through its complete lifecycle. This end-to-end transaction trace often reveals undocumented queues, broken handovers, missing evidence, and unclear escalation paths that are not visible in a high-level process description.
Start with One Capability
A complete IAM organizational assessment can quickly become a large and resource-intensive exercise. A more practical approach is to start with one capability that has a visible challenge, such as Entitlement Management for an application with unclear access rights.
For the selected capability:
- Define the expected outcome.
- Identify the tasks required to achieve it.
- Separate design, execution, and input responsibilities.
- Assign ownership for each task and outcome.
- Identify gaps, overlaps, and unclear handovers.
- Implement the most important improvement.
- Measure whether the outcome improves.
This exercise may also expose unrealistic IAM job profiles. If strategy, process design, engineering, operations, provider management, and data correction are assigned to one position, the organization may have combined tasks that require fundamentally different skills.
Testing the method on a single application or capability surfaces its practical problems before you apply it across the organization. The objective is not to design the complete IAM organization in the first workshop. It is to understand whether the method produces clearer responsibilities and better decisions.
Technology Still Matters, Within the Right Organization
IAM platforms are essential for scalable automation, integration, risk detection, and compliance reporting. However, IAM platforms can only be effective when the required ownership, processes, inputs, and operational responsibilities are in place.
Before investing in additional technology, organizations should determine whether their current challenges result from missing functionality or from unclear ownership, insufficient input quality, and incomplete process design. Otherwise, the new platform may reproduce the same organizational weaknesses through a more modern interface.
Effective IAM requires suitable technology, clearly assigned responsibilities, and an organization capable of providing the design, execution, and input on which the technology depends.
Continuing the Journey
If you recognize any of these situations in your IAM organization, this article is only the starting point. Over the coming months, we will publish further deep dives into the organizational aspects of IAM and practical ways to address them. Follow the series through our newsletter for the upcoming articles.
If you would like to discuss your current IAM setup or provide feedback on this article, feel free to contact me at pt@kuppingercole.com.