SASE investment justification depends on business outcomes, not ROI guesses

At a glance

What this is: Versa Networks highlights Gartner guidance that SASE funding is best justified by linking investment decisions to business outcomes, costs, benefits, and risks.

Why it matters: This matters to IAM and security leaders because identity-aligned access, remote connectivity, and policy enforcement programmes often stall when the business case is framed as infrastructure spend rather than measurable governance value.

Context

SASE buying decisions often fail because the programme is presented as a technical replacement rather than a business decision about risk, productivity, and operational simplicity. When the ROI story is vague, funding becomes harder to defend and prioritisation shifts toward short-term infrastructure pressure instead of long-term control design. The identity angle matters because remote access, policy enforcement, and access governance increasingly depend on how connectivity is managed.

Versa Networks is surfacing Gartner's guidance as a framing device, not a product argument. For practitioners, the real issue is how to connect network modernisation to governance outcomes that finance, operations, and risk stakeholders can evaluate consistently.

Key questions

Q: How should security teams justify SASE investments to executives?

A: Security teams should justify SASE by tying it to specific business outcomes such as access consistency, operational simplification, risk reduction, and productivity. Executives rarely approve architecture change on technical merit alone. The strongest case compares options using the same financial and governance criteria so the decision is transparent, defensible, and aligned to business priorities.

Q: Why do SASE programmes struggle to get funded?

A: They struggle when the case is framed as an infrastructure upgrade instead of a business decision. If teams cannot show how SASE changes risk, cost, or operating burden in measurable terms, stakeholders see unclear ROI and defer the spend. Funding improves when the proposal links network design to the outcomes leadership already tracks.

Q: What is the main governance risk in SASE adoption?

A: The main governance risk is treating connectivity architecture as a technology choice without clearly defining who benefits, which controls change, and what trade-offs remain. That creates weak accountability and makes later measurement difficult. Good governance requires a named outcome, a comparison baseline, and a clear explanation of how access policy changes.

Q: Should SASE be evaluated as a security control or a business investment?

A: It should be evaluated as both, but the business investment lens comes first because that is how funding decisions happen. A security control that cannot be expressed in business terms is harder to prioritise and harder to sustain. Teams should judge whether the change improves control coverage, reduces operational complexity, and supports strategic priorities.

Technical breakdown

Why SASE business cases break down

SASE programmes often get stuck between architecture language and budget language. The technical value may be clear to security teams, but executive sponsors need a decision model that compares costs, benefits, risk reduction, and operational change in the same frame. Without that translation, the programme reads like a platform preference instead of a governance decision. That is why the report's emphasis on transparent stakeholder discussion matters: it converts an infrastructure project into a business choice.

Practical implication: build SASE funding requests around outcomes, not feature lists.

How business outcomes connect to access governance

SASE influences more than transport. It shapes how users, devices, and services reach internal resources, which means it affects policy enforcement, remote access control, and the consistency of access decisions across environments. In identity terms, that makes SASE part of the control plane around who can connect, under what conditions, and with what visibility. The business case should therefore describe how access risk, user experience, and operational overhead change together.

Practical implication: align SASE justification with access policy, not just network consolidation.

What stakeholders actually need to evaluate

Stakeholders do not need a technical deep dive first. They need to understand which outcomes improve, which risks fall, which costs are shifted, and what trade-offs remain. Gartner's framing suggests that decision quality improves when teams explicitly compare options rather than assuming one architecture is automatically superior. That approach is useful for identity security programmes because it forces clearer ownership of business value and control boundaries.

Practical implication: present SASE as a comparative governance decision with named outcomes and trade-offs.

NHI Mgmt Group analysis

Business-case discipline is now part of security governance. The article shows that SASE adoption is increasingly judged through economic and operational framing, not purely technical merit. That matters because security programmes that cannot explain value in business terms struggle to survive budgeting cycles. Practitioners should treat business-case quality as a control, not a presentation skill.

Access governance is the hidden dependency in SASE justification. Even when the article is not explicitly about IAM, SASE affects how remote users and services are authorised onto resources, which means identity policy is embedded in the investment decision. If access enforcement cannot be described clearly, the organisation cannot prove what the SASE layer is actually improving. Practitioners should tie connectivity decisions to measurable access governance outcomes.

Complexity is the real cost centre, not just licence spend. The article points to a common mistake in infrastructure buying: focusing on subscription cost while undercounting operational complexity, stakeholder alignment, and change management. In identity and security programmes, those soft costs determine whether the new control is adopted consistently. Practitioners should evaluate programmes on operating simplicity as well as financial spend.

Gartner-style framing is valuable because it forces option discipline. The report encourages transparent comparison of costs, benefits, and risks across alternatives, which is the right model for modern security architecture decisions. That approach helps teams avoid making SASE a default answer to every network or access problem. Practitioners should use structured decision criteria before committing to architecture change.

SASE business cases should be written as governance arguments, not procurement requests. The best justification explains which risk path is reduced, which operational burden changes, and who benefits from the change. That makes the proposal legible to finance, operations, and security leadership at the same time. Practitioners should frame SASE funding around decision outcomes that can be defended across the organisation.

What this signals

SASE decisions are increasingly a governance exercise because the architecture affects access control, user experience, and the operational burden of enforcing policy across environments. Teams that separate technical design from funding logic will keep running into stalled programmes and weak executive sponsorship.

Decision framing debt: when security teams cannot describe the outcome, the control, and the cost in the same language, the programme inherits avoidable complexity. That is especially true where remote access and identity policy intersect with connectivity modernisation.

For practitioners

• Define the business outcome first State which outcome SASE is meant to improve, such as access consistency, user experience, policy enforcement, or operational simplification, before discussing products or deployment models.
• Translate technical benefits into budget language Express cost reduction, risk reduction, and productivity impact in terms finance and operations can compare, rather than relying on network architecture terminology.
• Map SASE to access governance controls Show how the architecture affects remote access, policy decisions, and identity-dependent enforcement so stakeholders can see what control problem is being solved.
• Compare alternatives on named criteria Use the same criteria across SASE and non-SASE options, including cost, benefit, risk, and operational complexity, so the decision is transparent and repeatable.

Key takeaways

• SASE funding cases fail when they are built around technical architecture instead of business outcomes that executives can compare and approve.
• The practical challenge is not proving that SASE has security value, but showing how it changes costs, risks, and operating complexity in measurable terms.
• Identity and access governance should be part of the justification because remote connectivity policy and enforcement are inseparable from who can reach what resources.

Key terms

• SASE: A cloud-delivered architecture that combines networking and security capabilities such as SD-WAN, SWG, CASB, FWaaS, and ZTNA. It centralises enforcement across distributed environments, but it does not replace identity governance or privilege design. The model is operationally broad, not a substitute for entitlement control.
• Business Case: A business case is a structured argument for investing in a security initiative based on risk, cost, operational impact, and expected value. In cybersecurity, it translates technical needs into outcomes decision-makers understand, such as reduced exposure, improved resilience, or better compliance. It supports prioritisation and funding decisions.
• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
• Operational Complexity: Operational complexity is the accumulation of manual steps, exceptions, duplicated controls, and fragmented ownership that makes identity governance harder to run. In hybrid workload identity programmes, it often shows up as inconsistent access handling, poor visibility, and slower response to change. Reducing it improves scalability and control.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity, and secrets management. It helps security and identity practitioners connect control design to the business outcomes their programmes must defend.