What is the difference between run, grow, and transform spend for identity teams?

Run spend keeps core identity operations working, grow spend adds capacity or coverage, and transform spend funds experimentation or redesign. For identity teams, the key distinction is whether a cost preserves current assurance, expands control coverage, or changes how the programme operates. Misclassifying these items leads to underfunded governance.

Why This Matters for Security Teams

Identity budgets are often split into operational spend that keeps authentication, provisioning, rotation, and monitoring working; expansion spend that adds new apps, regions, or identity coverage; and redesign spend that changes the control model itself. That distinction matters because identity is not a one-time build. It is a continuous control plane that supports every access decision, and underfunding any one of those categories creates visible risk elsewhere. NHI Mgmt Group’s Ultimate Guide to NHIs shows why: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That is not a theory problem, it is an operating model problem. The NIST Cybersecurity Framework 2.0 reinforces the same point by treating governance, protection, and detection as ongoing functions rather than one-off projects. In practice, many security teams discover they have been funding “transform” work while leaving run controls fragile, or cutting run spend until incidents force emergency remediation.

How It Works in Practice

For identity teams, run spend covers the baseline services that must keep operating every day: directory and federation availability, privileged access workflows, lifecycle automation, logging, certificate and secret rotation, policy administration, and help desk support for access issues. This is the budget that preserves current assurance. If it slips, control drift appears fast.

Grow spend expands the programme without changing its core design. Common examples include onboarding a new business unit, extending identity governance to more applications, adding machine identities into scope, improving coverage for contractors or third parties, or increasing detection and response capacity. Grow usually answers the question: what additional scope or capacity is needed to keep pace with the business?

Transform spend funds a different operating model. That may include moving from manual reviews to automated continuous controls, redesigning joiner-mover-leaver processes, introducing zero standing privilege, or replacing static secrets with workload identity and short-lived credentials. In NHI terms, transformation often starts when teams recognise that long-lived secrets and broad service accounts are structurally weak. The Top 10 NHI Issues and 52 NHI Breaches Analysis both show how unmanaged credentials and excessive privilege turn routine operations into breach paths.

A practical budget review usually asks:

• What cost is required to keep existing identity assurance stable?
• What cost adds coverage, volume, or user groups?
• What cost changes architecture, automation, or governance?

This matters because identity teams often absorb growth and transformation into the run baseline, which hides true cost and makes the run budget look bloated. These controls tend to break down when identity ownership is split across infrastructure, security, and application teams because no single group can see the full operating cost chain.

Common Variations and Edge Cases

Tighter budget classification often improves accountability, but it also increases planning overhead, requiring organisations to balance financial clarity against delivery speed. In mature programmes, the same project can include all three spend types, and that is normal. A directory migration may contain run work for stability, grow work for additional user populations, and transform work for a new authentication model. The tradeoff is that finance and security leaders need explicit rules for allocation, or else “innovation” will quietly consume maintenance funding.

Current guidance suggests that identity teams should classify spend based on the primary outcome, not the procurement label. If the item preserves current control effectiveness, it is run. If it broadens reach or capacity, it is grow. If it changes the control architecture, process model, or assurance method, it is transform. That distinction is especially important in NHI programmes, where secret rotation, access reviews, and service-account cleanup can look like projects but are really part of the baseline control plane. The Ultimate Guide to NHIs is useful here because it frames NHI governance as lifecycle management, not a one-time inventory exercise. In environments with heavy regulatory reporting or multi-tenant shared services, the boundary between grow and transform can blur because compliance automation and architectural redesign are often delivered together.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between asset inventory and identity governance?
• What is the difference between centralised identity management and lifecycle governance?
• What is the difference between multi-suite support and identity-led service delivery?