Which teams should be accountable for Zero Trust budget decisions?

Why This Matters for Security Teams

zero trust budgets are rarely just technology spend. They determine whether an organisation can actually enforce least privilege, segment access, validate device posture, and monitor privileged activity across users, workloads, and Non-Human Identities. That makes the budgeting question a governance issue, not simply a procurement exercise. NIST SP 800-207 Zero Trust Architecture frames Zero Trust as a strategy built on continuous verification and explicit policy decisions, which means funding has to follow the control points that make those decisions real.

The common mistake is allowing one function to sponsor the programme while other teams absorb the operational burden. Security architecture may define the target state, but IAM, PAM, network security, endpoint security, and NHI owners often carry the implementation cost. If budgets are assigned too narrowly, teams tend to buy dashboards before enforcement, or controls before ownership, and the result is a programme that looks mature but still leaves privilege paths open. Security leaders should also align spending to the control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, because that is where accountability can be translated into measurable control coverage. In practice, many security teams discover misallocated Zero Trust spend only after a major access review, incident, or audit exposes the gap between policy and enforcement.

How It Works in Practice

Accountability should be assigned to the teams that own the risk-reducing control, not just the platform that exposes the control. For a practical Zero Trust funding model, each domain should sponsor the line items it must operate day to day:

• Security architecture owns the reference design, dependency map, and control prioritisation.
• IAM funds authentication assurance, lifecycle automation, RBAC refinement, and identity proofing where relevant.
• PAM funds privileged session control, JIT access, secrets protection, and administrative isolation.
• Network security funds segmentation, policy enforcement, and remote access control.
• Endpoint and cloud teams fund posture validation, telemetry, and conditional enforcement.
• NHI owners fund workload identities, service account governance, and machine-to-machine credential lifecycle.

This model works best when budget requests are tied to specific control outcomes and measurable coverage, such as privileged access reduction, segmentation depth, and policy decision visibility. It also helps to separate one-time transformation costs from run-state costs, because Zero Trust programmes often fail when capital projects are approved but no operating budget exists for continuous tuning, policy exceptions, and telemetry review. Current guidance suggests using governance forums to resolve overlaps and prevent duplicate tooling purchases across identity, endpoint, and network stacks. The operating model should also show who can approve exceptions, who owns exception expiry, and who is accountable for remediation. That is especially important when NHI controls are involved, because workload and service identities often fall between platform teams and security teams unless ownership is explicit. For a broad implementation view, NIST’s architecture guidance in NIST SP 800-207 Zero Trust Architecture is useful for mapping control decisions to enforcement points rather than to organisational titles.

These controls tend to break down in federated enterprises with shared services and outsourced operations because no single team owns the end-to-end policy enforcement path.

Common Variations and Edge Cases

Tighter budget ownership often increases coordination overhead, requiring organisations to balance clear accountability against slower approval cycles and competing priorities. In practice, there is no universal standard for exactly how Zero Trust funding should be split, so mature organisations usually adopt a federated model with central governance and distributed cost centres.

One common variation is a central security transformation fund that pays for architecture, standards, and shared tooling, while product, infrastructure, and identity teams fund their own implementation work. That approach can work well when the enterprise has many business units, but it only succeeds if the central team can enforce architecture standards and reject fragmented tool purchases. Another edge case is a merger or large cloud migration, where IAM and NHI costs rise together and the budget owner may need to be a joint steering group rather than a single director. For regulated environments, funding may also need to align to resilience and control testing obligations under frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where audits require proof that controls are both designed and operated. The practical question is not who “likes” Zero Trust, but who can be held accountable when enforcement gaps appear.

Where environments rely on legacy directories, flat networks, or unmanaged service accounts, the budget model often collapses because the controls needed for real enforcement are missing or too expensive to retrofit quickly.

Related resources from NHI Mgmt Group

• Who should own microsegmentation decisions in a zero trust programme?
• Who is accountable for access decisions under zero trust governance?
• Who is accountable when zero-trust access decisions fail?
• Who should own Zero Trust decisions when IAM, networking, and cloud teams all touch the same controls?