Notifications
Clear all
Topic starter
25/06/2026 1:31 am
TL;DR: A healthcare organisation spent 10 to 12 months trying to build an IAM platform for 160-plus facilities across 20-plus states, yet the effort stalled, costs rose, and clinical staff felt the impact, according to SailPoint. The lesson is that IAM complexity, integration load, and lifecycle upkeep often make custom builds a false economy.
NHIMG editorial — based on content published by SailPoint: Blog Facepalm Files, why buy when we can build, and why it failed
By the numbers:
- The company needed to manage identities and access across 160+ medical facilities in 20+ states.
Questions worth separating out
Q: How should organisations decide whether to build or buy IAM capabilities?
A: Organisations should compare three things: lifecycle coverage, integration burden, and three-year operating cost.
Q: Why do custom IAM projects often stall after early design work?
A: They stall because the programme must solve many dependencies at once: directories, business applications, approvals, evidence generation, and exception paths.
Q: What do security teams get wrong about IAM total cost of ownership?
A: They often count licence costs or initial development effort but ignore support, maintenance, testing, compliance work, and the business cost of delayed access.
Practitioner guidance
- Model three-year IAM operating cost before committing to build Include engineering time, support effort, compliance evidence, access reviews, and remediation work.
- Test lifecycle coverage before approving any custom design Require proof for provisioning, recertification, offboarding, and exception handling across the identities you actually run, including service accounts and other non-human identities.
- Quantify integration burden across every source system Count directories, applications, stateful exceptions, and manual dependencies.
What's in the full article
SailPoint's full blog post covers the personal case study and decision-making detail this post intentionally leaves for the source:
- The step-by-step timeline of the failed internal IAM build over 10 to 12 months.
- The business-value assessment used to quantify wasted effort and lost productivity.
- The estimated year-one cost comparison that changed the conversation.
- The postscript on how the organisation eventually moved to an off-the-shelf IAM solution.
👉 Read SailPoint's facepalm file on why building IAM did not work →
Build vs. buy in IAM: what stops custom identity projects?
Explore further
25/06/2026 10:59 am
Build-versus-buy is an identity governance decision, not a software preference. The central failure in this story was not a missing feature. It was a programme decision that underestimated how much organisational context IAM must absorb before it can govern access reliably. In practice, custom IAM efforts fail when leaders treat identity as something engineering can assemble after the fact. The lesson for practitioners is to evaluate IAM as a governance operating model, not a coding exercise.
A few things that frame the scale:
- The company needed to manage identities and access across 160+ medical facilities in 20+ states, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: What should identity leaders do when a custom IAM build is already consuming time without results?
A: They should stop measuring progress by meetings completed and start measuring it by working lifecycle controls, successful integrations, and reduced business friction. If those outputs are not improving, the organisation should reassess whether the custom path still makes sense.
👉 Read our full editorial: Build vs. buy in IAM: why custom programs stall at scale
