Topic starter
14/05/2026 4:10 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by SailPoint: “Facepalm Files: The moment you realize you painted yourself into a corner and wish you had taken a different turn”.
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.
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.
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.
Practitioner guidance
- Define business process owners before build starts Assign accountable process owners for joiner, mover, leaver, access request, and recertification workflows before configuration begins.
- 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.
Bottom line: Identity security programmes fail when they preserve legacy business processes and treat governance as an IT delivery task.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/05/2026 7:00 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Identity security fails when teams treat it as an IT project