Skip to content
Notifications
Clear all

Am I the only one who thinks iboss's pricing model gets punitive at scale?

19 Posts
19 Users
0 Reactions
40 Views
(@emilyl)
Honorable Member
Joined: 3 months ago
Posts: 527
 

That's a really good question about documenting the cost-vs-risk decisions. We don't have a formal process for that either, and your point about it being an *unconscious* risk acceptance is spot on. It probably just looks like a budget line item to them.

It makes me wonder, would a formal process even help? Or does just having the DLP overage report in a spreadsheet already create the liability record, no matter what process you wrap around it?



   
ReplyQuote
(@harryj)
Reputable Member
Joined: 3 months ago
Posts: 381
 

The "buy premium features, can't turn them on" part is exactly why our last security review failed. We had to show full DLP was enabled for our main office block, but the financial model meant we couldn't afford to apply the same policy to our engineering VPC. The auditor called it a control inconsistency. The vendor just calls it a pricing tier.

It turns the feature list into a menu of liabilities you can't actually use.


Automate the boring stuff.


   
ReplyQuote
(@carlosm)
Honorable Member
Joined: 3 months ago
Posts: 339
 

I checked into their Enterprise Agreement last year for a client. You're right - it was basically a bigger pool, not a true flattening. It came with a "committed use discount" on the overage rate, but the meter was still running. It just made the surprise bill spikes slightly less painful, without fixing the forecasting problem.

It's that shift from policing for security to policing for cost that kills me. When your weekly team sync starts with "we need to talk about the DLP bill from the backup job," you've already lost.


Keep automating!


   
ReplyQuote
(@davidn3)
Reputable Member
Joined: 2 months ago
Posts: 277
 

Getting them to clarify what increments constitute "data volume" is often the critical step. Without that, even a fixed overage rate can be gamed.

We had a similar negotiation, but discovered a loophole in their "volume" definition. They were counting bidirectional traffic for some protocols but only egress for others, which made our internal modeling useless until we standardized the metric. That forced us into a painful audit of our own traffic patterns to even understand the bill.

Your predictable cap is a good outcome for finance, but does it actually incentivize better security posture, or does it just make the penalty for exceeding your quota a known quantity?


Data is the only truth.


   
ReplyQuote
Page 2 / 2