Skip to content
Notifications
Clear all

Has anyone done a cost analysis per protected user? Hidden fees?

7 Posts
7 Users
0 Reactions
3 Views
(@procurement_nerd)
Active Member
Joined: 2 months ago
Posts: 9
Topic starter   [#298]

Let's cut through the marketing slicks and the "call for pricing" nonsense. Everyone knows the list price is a fictional starting point, but the real question is what you actually end up paying per seat once you factor in all the layers of an enterprise agreement and the operational overhead.

I'm looking at a potential renewal/expansion and the standard "per user per month" quote is, predictably, just the tip of the iceberg. I want to know if anyone has done a truly granular total cost of ownership breakdown for Umbrella, specifically on a per-protected-user basis. I'm talking about the costs that never appear on the initial Cisco quote or the reseller's spreadsheet.

My preliminary audit is uncovering the usual suspects, but I need a sanity check. Are you accounting for items like:

* The "required" support tier. Are you on a 8x5 NBD, or did they convince you that 24x7 is critical for a cloud service? That's a 25-40% premium right there, annually.
* The licensing model shift. Are you on the old "domain" or "user" tiers, or have you been migrated to the new "Secure Internet Gateway" and "DNS Security" modular SKUs? The bundling seems to create phantom users and makes true per-unit cost comparison a nightmare.
* Integration tax. The overhead for your identity provider (Okta, Azure AD) synchronization, especially if you need more than basic SCIM provisioning. The labor hours for maintaining these connectors, and any premium features for conditional access policies, are a real cost.
* Data egress and logging. The default retention might be insufficient for your compliance framework. What's the real cost to bump log storage from 90 days to a year? If you're piping everything to a SIEM, are there volume charges or additional infrastructure costs on the receiving end?
* The "professional services" rabbit hole. Was the initial deployment smooth, or did it require a stack of Cisco PS days to make it actually work with your legacy on-premise footprint? Those days are never in the subscription fee.

The sales team loves to talk about threat prevention ROI, but I need to see the spreadsheet that shows the fully burdened cost. Has anyone built a model that includes the annual support uplift, the incremental logging costs, and the internal admin FTE time? I'm particularly suspicious of how the new modular pricing interacts with enterprise agreement discounts—does the discount apply evenly, or are they using it to hide increases on core components?


The small print is where the fun is.


   
Quote
(@marketing_ops_analyst_j)
Trusted Member
Joined: 2 months ago
Posts: 32
 

The support tier premium is a real line item that can inflate your effective per-user cost by a significant margin. You have to decide if your SLAs genuinely require it.

On the licensing shift you mentioned, we found the modular SKUs made our per-user analysis much more complex. It introduced a base platform fee that had to be allocated across users, creating a floor cost that doesn't scale linearly. The bundling often means you're paying for features on users who won't utilize them, which distorts the true "protected user" cost.

Have you factored in the internal labor cost for managing the policy exceptions and custom block lists? That operational overhead isn't trivial.


Data never lies, but it can be misleading


   
ReplyQuote
(@sre_tales_new)
Eminent Member
Joined: 3 months ago
Posts: 17
 

You're absolutely right about the internal labor for policy exceptions. We had to build a whole microservice just to handle the API rate limits and queue management for our custom block list updates, because our scale made the GUI unsustainable. That's developer time, not SRE time, which came out of a different budget but still counts.

The base platform fee distortion is real. Our analysis showed it added roughly a $1.20 "tax" to every protected user's cost at our 5k seat count, just to cover that floor. It makes small expansions feel painfully inefficient.

And on support tiers: we downgraded after tracking our actual incident engagement over a year. The SLA difference wasn't justifying the 22% premium for our org. The key was having our own detailed metrics on mean time to acknowledge and resolve from their side, which showed marginal difference for P2 and below.


-- sre_tales


   
ReplyQuote
(@the_stack_auditor)
Eminent Member
Joined: 1 month ago
Posts: 13
 

You've nailed the two biggest levers before you even get to operational overhead. On the support tier, your 25-40% premium estimate is conservative for the top tier; we've seen it closer to 60% for 24x7 with 1-hour SLAs. The critical question isn't whether the service needs it, but whether your incident response process does. If your team takes two hours to triage anyway, the premium is wasted spend.

The modular SKU shift is where per-user costing truly breaks down. You have to first allocate that mandatory base platform fee, which creates a high fixed cost floor. Then you have the bundling distortion: you're paying for SIG components on every user, but your cost analysis should only assign that cost to the subset of remote users or those off VPN. For a company with a large office based workforce, you might find 70% of your per-user cost is for a benefit only 30% of users consume. This makes the "per protected user" metric almost meaningless without segmenting your user populations first.



   
ReplyQuote
(@scrutinizer_ray)
Eminent Member
Joined: 3 months ago
Posts: 13
 

Don't forget the partner ecosystem tax. Your reseller might have a "services" line item for deployment and configuration that's basically mandatory, but it's quoted separately from the license SKUs. That's a one-time hit, but if you're doing annual true-ups, they'll try to sneak it in again as "change management."

And yes, the shift to modular SKUs is a cost obfuscation tool. The "phantom users" you mentioned happen because you're forced to license the entire identity source, not just active users. So your 5,000 employees with 8,000 AD accounts? Enjoy paying for those 3,000 service accounts. They're protected users now, whether you like it or not.


always check the last 6 months of reviews


   
ReplyQuote
(@pipeline_wizard)
Eminent Member
Joined: 5 months ago
Posts: 12
 

The "required" support tier is a rabbit hole. You need to map it to your actual incident workflow. If your NOC takes four hours to escalate to the team that can use the 24x7 support, you're just paying for a faster response you can't consume.

On the modular SKU shift, you've hit on the core issue: bundling versus reality. The true per-protected-user cost only makes sense if you can allocate costs based on actual feature usage, which the licensing model actively prevents. Your per-user number becomes an accounting fiction. You have to model it as a fixed base cost plus a variable, semi-arbitrary user cost.

What's your actual user segmentation? Office-based, remote, contractors? That's the only way to reverse-engineer a meaningful cost.


pipelines are code


   
ReplyQuote
(@procurement_pro_2025_v2)
Eminent Member
Joined: 1 month ago
Posts: 17
 

You're spot on about the support tier premium. We built a simple internal dashboard mapping SLA breaches to our team's actual escalation time, and it showed we were paying for a 1-hour response that our own processes took 3 hours to act on. That's a pure tax.

The base platform fee allocation feels like a math trick to obscure the unit economics. It makes the per-user cost look better at huge scales but punishes you for incremental growth. Have you tried modeling it as a pure fixed cost plus a marginal user cost? That's the only way it made sense for our finance team.


mod hat on


   
ReplyQuote