TL;DR: Identity security programmes fail when teams implement them as technical projects, ignore process owners, and miss the business redesign required for measurable ROI, according to SailPoint. The operational lesson is that governance, not customization, determines whether identity programmes reduce risk or simply automate broken workflows.
At a glance
What this is: This is SailPoint’s argument that identity security programmes fail when they are run as IT implementations rather than business transformation efforts.
Why it matters: It matters because IAM and IGA teams can deliver tooling and still miss risk reduction if process owners, operating model changes, and ROI outcomes are left outside the programme scope.
Context
Identity security is a business programme problem when it is used to preserve existing workflows instead of redesigning them. In practice, that means the programme is judged only on technical delivery, while the real governance work, process ownership, operating model change, and measurable outcomes, is left untouched.
The article describes a familiar failure pattern: teams implement identity controls “as-is,” customise heavily to match legacy business requests, and proceed without enough business analysis or experienced implementation support. The result is not a broken tool, but a programme that automates the wrong process and then struggles to prove value.
Key questions
Q: What breaks when identity security is implemented as an IT project?
A: The programme usually preserves old business processes, hides weak ownership, and produces technical delivery without operational change. That means the organisation can go live while still carrying the same approval friction, exceptions, and inefficiency it had before. The failure is governance, not software.
Q: Why do identity programmes often miss their ROI targets?
A: They are often scoped around configuration and deployment instead of process redesign and measurable business outcomes. If leaders do not reduce manual work, remove redundant approvals, or change decision rights, the programme may be technically complete while the business value remains unrealised.
Q: What do security teams get wrong about heavy customization in identity projects?
A: They treat customization as proof that the platform fits the business, when it can actually mean the business process was never challenged. Excess customization often locks in legacy behaviour and makes the identity environment harder to govern, audit, and improve over time.
A: Treat identity governance as an operating change that spans IT, security, HR, compliance, finance, and application owners. Assign a cross-functional owner or steering group before vendor selection, and gather requirements from the teams that will use the workflow. When ownership is narrow, adoption suffers, requirements miss real needs, and change management problems show up later as resistance.
Technical breakdown
Why “as-is” identity delivery creates governance debt
Identity programmes fail technically when teams copy existing business processes into a new control stack without rethinking the underlying workflow. That keeps legacy approvals, exceptions, and handoffs intact, so the technology merely accelerates the old model instead of improving it. In governance terms, the programme inherits process debt: technical success, operational inertia, and weak business ownership. The problem is not customization by itself, but customization used as a substitute for redesign.
Practical implication: assess whether each identity workflow is being redesigned for control and efficiency, or simply replicated in software.
Why customization can hide a missing operating model
Heavy customization often appears to be responsiveness, but it usually signals that the team has not defined the operating model clearly enough. If business owners are absent, technical teams fill the gap by building whatever is requested, even when it embeds poor process choices into the identity lifecycle. That creates a fragile programme because policy, process, and technology no longer reinforce each other. Modern identity governance needs process accountability first, configuration second.
Practical implication: require named business owners for identity workflows before approving custom build decisions.
Why ROI is a governance signal, not just a finance metric
The article’s ROI theme is important because unrealised value often shows up before a programme is formally declared a failure. If management cannot point to process simplification, risk reduction, or measurable business improvement, then the identity effort may be operating as an IT deployment rather than a transformation programme. That is a governance signal, not a reporting problem. It shows the programme was scoped around implementation effort instead of business outcomes.
Practical implication: track whether the programme is changing business processes and control outcomes, not just delivering features.
Breaches seen in the wild
- Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity security fails when business process redesign is treated as optional: The article shows that the core failure is not lack of tooling, but lack of transformation. When teams preserve legacy workflows and call that implementation, the programme becomes a control layer over unchanged business behaviour. The implication is that identity governance must be measured against process change, not deployment completion.
Heavy customization is often a symptom of missing business ownership: When a technical team builds whatever is asked for, the identity programme inherits the organisation’s unresolved process decisions. That creates brittle governance because no one has challenged whether the request reflects how the business should operate. Practitioners should treat uncontrolled customization as evidence that ownership and design authority are misaligned.
Identity programme value depends on operating model maturity, not project execution speed: The article makes clear that teams can spend heavily and still miss the intended outcome. That is a reminder that faster delivery does not equal better governance when the control model itself is wrong. For practitioners, the real question is whether identity work is changing decision rights, accountability, and process efficiency.
Identity process inertia: The article exposes a common failure mode where identity controls are built to preserve existing business steps rather than eliminate or improve them. That makes the programme look busy while leaving underlying inefficiency untouched. Practitioners should recognize that this kind of inertia is a governance problem before it becomes a technology problem.
Partner expertise matters when internal teams are too close to the current process: The article argues that recovery often starts when teams accept help from people who have seen similar transformations succeed elsewhere. That matters because identity security programmes can become self-reinforcing loops of local assumptions. The practitioner takeaway is to test whether the team has enough external perspective to challenge its own design defaults.
What this signals
Identity security programme debt: When teams optimize for delivery speed and technical completeness, they often accumulate process debt that later appears as audit pain, recertification friction, and weak adoption. For IAM leads, the signal is simple: if business owners cannot explain why a workflow exists, the programme has likely implemented the old process rather than improved it.
Identity security needs the same discipline as any other business transformation. That means aligning control design to decision ownership, process simplification, and measurable outcomes, not to the convenience of the implementation team.
For practitioners
- Define business process owners before build starts Assign accountable process owners for joiner, mover, leaver, access request, and recertification workflows before configuration begins. If ownership is undefined, the technical team will encode legacy process assumptions into the identity programme.
- Replace as-is implementations with redesign workshops Run structured workshops to map current-state workflows, remove unnecessary approvals, and decide where identity controls should change the business process rather than mirror it.
- Limit customization to explicit control requirements Treat every custom workflow or integration as a governance decision. Approve only changes that support measurable risk reduction, auditability, or lifecycle control, not convenience requests.
- Track outcome measures alongside delivery milestones Measure process simplification, exception reduction, and control effectiveness in parallel with implementation progress so programme success is judged on business change, not just system go-live.
Key takeaways
- Identity security programmes fail when they preserve legacy business processes and treat governance as an IT delivery task.
- The article’s core warning is that heavy customization and missing process ownership can produce implementation progress without meaningful business value.
- Practitioners should redesign workflows, assign accountable owners, and measure outcomes that show the programme is changing how the business operates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The article is about aligning identity work to business context and objectives. |
| GV.OV-01 — Oversight of the Cybersecurity Risk Management Strategy | The post centres on governance oversight and outcome accountability. | |
| Recommendation — Define identity programme goals in business terms before assigning technical delivery scope. Tie identity delivery to oversight metrics that show control effectiveness and business change. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article concerns how identity processes are designed and governed across account lifecycle work. |
| Recommendation — Review account lifecycle processes to ensure business ownership and approved workflows are explicit. | ||
| NIST SP 800-53 Rev 5 | PM-1 — Information Security Program Plan | The post treats identity as a programme with operating-model and governance implications. |
| Recommendation — Manage identity security as a governed programme with defined outcomes and accountability. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | The article stresses governance intent and business-aligned policy over ad hoc technical build. |
| Recommendation — Set policy that requires identity workflows to be justified by business and risk objectives. | ||
Key terms
- Identity Security Programme: An identity security programme is the operating model for controlling who or what can access systems and data. It combines policy, workflow, ownership, review, and lifecycle management so access decisions are traceable, repeatable, and defensible rather than left to ad hoc technical implementation.
- Process Owner: A process owner is the business stakeholder accountable for a specific application, role set, or access decision. In access governance, this person reviews evidence, approves or terminates access, and acts on risk within their domain. The role is central because it ties permission decisions to real operational responsibility.
- Operating Model: An operating model is the practical way a governance programme is run, including decision ownership, workflow design, integrations, and control boundaries. For identity security, the operating model determines whether policy intent survives real execution across human, NHI, and AI-assisted processes.
- Process debt: Process debt is the accumulation of undocumented steps, inconsistent handoffs, and manual workarounds that make a workflow fragile. In identity operations, it shows up as hidden exceptions, unclear ownership, and poor measurement that automation later amplifies rather than removes.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 14, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org