How should organisations start an IAM programme without making it a pure IT project?

Why This Matters for Security Teams

An IAM programme becomes a pure IT project when it is framed as a tooling rollout instead of a business control initiative. That usually leads to narrow scoping, weak executive ownership, and requirements built around directory hygiene rather than operational risk. The result is predictable: identity lifecycle failures, access sprawl, and audit findings are treated as technical nuisances instead of signals that mission-critical processes are exposed. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes the point indirectly by anchoring identity to control effectiveness, not software deployment.

For NHI Management Group, the pattern is consistent across identity programmes that stall: teams inventory accounts before they define the business decisions those accounts support. That inversion is costly because the organisation ends up optimising for administration rather than resilience. NHI risk research shows how quickly this drifts into exposure, including the Ultimate Guide to NHIs finding that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams encounter the real cost only after audit evidence, outage recovery, or a secrets leak has already forced the issue.

How It Works in Practice

The right starting point is not a target architecture diagram. It is a short discovery cycle that maps identity failure to business impact. Interview process owners, application owners, audit, and operations to identify where access problems block revenue, slow delivery, or create control failures. Then translate those findings into programme scope: which identity classes matter first, which systems carry the highest risk, and what “good” looks like in terms of approval, lifecycle, and evidence.

A practical IAM launch usually includes four moves:

• Define the business outcomes first, such as reducing onboarding delays, eliminating orphaned access, or improving segregation-of-duties evidence.
• Baseline the current identity estate across people, NHI, service accounts, privileged access, and external parties.
• Prioritise the highest-friction and highest-risk journeys, not the largest technical inventory.
• Convert findings into requirements for governance, automation, and auditability before selecting tools.

This sequencing matters because IAM is a control plane, not a ticket queue. A programme that starts with business pain can justify lifecycle automation, stronger review discipline, and better privileged access boundaries. It also creates a defensible case for tackling secrets management and workload identity later, especially where service accounts or API keys are embedded in application workflows. NHIMG’s 2024 Non-Human Identity Security Report notes that only 19.6% of security professionals express strong confidence in securely managing non-human workload identities, which is a useful reminder that maturity gaps are common, not exceptional. Where secrets handling is part of the discovery, cases such as Azure Key Vault privilege escalation exposure show why lifecycle and permissions cannot be separated from operating reality.

These controls tend to break down when the programme is owned exclusively by infrastructure teams in highly fragmented environments, because business process owners never define the access decisions the technology is supposed to enforce.

Common Variations and Edge Cases

Tighter IAM governance often increases stakeholder overhead, so organisations have to balance control depth against delivery speed and change fatigue. That tradeoff is real, especially where multiple business units run their own platforms or where audit pressure is already high. The answer is not to centralise everything on day one, but to define a consistent decision model and then phase adoption by risk.

Current guidance suggests three common variations. First, in regulated environments, audit and risk teams should co-own scope because compliance evidence is part of the business requirement, not an afterthought. Second, in fast-moving product organisations, IAM can start with one painful journey such as joiner-mover-leaver handling or privileged access reviews, then expand once value is proven. Third, for organisations with significant machine-to-machine access, the programme must eventually include NHIs, because a human-only IAM plan will miss the credentials that actually run production. That is where identities with opaque ownership or long-lived secrets create hidden exposure, as seen in incidents like TruffleNet BEC Attack — Stolen AWS Credentials.

There is no universal standard for how quickly an IAM programme should broaden beyond the first use case, but best practice is to use the initial business case to fund the next control area rather than locking the programme into one department’s implementation priorities.

Related resources from NHI Mgmt Group

• Where does cross-environment agent discovery fit in an IAM programme?
• What breaks when organisations rely on patching without identity containment?
• How should healthcare organisations onboard travelling clinicians without delaying patient care?
• How should organisations validate Azure IAM maturity?