With no rate card, the counting rules are the only published price
Every enterprise deal here is a custom quote, which removes the usual anchor entirely: there is no list to discount from and no benchmark rate to argue toward. What remains negotiable is the definition of what gets counted, how it is averaged, and which modules sit in scope. Those three are the price list, and the buyer who audits them controls the deal.
Prepared by Redress Compliance · August 10, 2026 · Security advisory. Based on 10 to 14 cloud security negotiations, 2024 to 2025.
Executive summary
Unverified workload counts in first proposals ran 20 to 40 percent above the measured average.
The meter is billable workloads, and a workload is not a server: virtual machines, container hosts, serverless functions, and data resources each convert at ratios fixed in the order form rather than in marketing material.
Autoscaling groups, short lived containers, and abandoned development accounts inflate a vendor connector scan, and the inflation compounds at every renewal because it becomes the baseline.
The averaging clause is worth more than two discount points, and it is one sentence. Whether the count is a peak, a monthly average, or a term average changes the bill materially in any elastic estate, where a peak based count can run double the term average.
That method has to be written into the order form rather than assumed, and it is the clearest example of why the counting rules matter more here than the rate does.
Scoping the expensive modules to crown jewel accounts cut proposals 25 to 35 percent with no security coverage loss anyone could name. Core posture management belongs estate wide; runtime sensors and data security posture rarely do.
That last clause is the important one: the buyers who scoped narrowly were asked what coverage they had given up and could not identify any, which reframes the conversation from risk appetite to scope discipline.
A live competing quote moved the rate 15 to 30 percent, including in accounts that had already standardised. That is worth stating plainly because security teams frequently regard the standardisation decision as closing the commercial question. It does not.
The competitive quote works even where the buyer has no intention of switching, because it restores an anchor to a category that otherwise has none.
Which modules belong estate wide, and which do not
| Module | What it covers | Sensible scope |
|---|---|---|
| Posture management core | Misconfigurations and attack paths | Estate wide |
| Runtime sensor | Workload runtime detection | Production crown jewels |
| Data security posture | Data discovery and exposure | Accounts holding regulated data |
| Code security | Infrastructure as code and pipeline scanning | Active development organisations only |
The platform bundle discount looks generous until you price the modules you would not otherwise buy, which is the standard shape of a consolidation offer in a category with no list price.
Anchor on the modules that have a named owner and a stated use case, and let the rest be the vendor's problem to justify rather than yours to decline.
The test that made this work for the buyers in our file was simple and worth borrowing: after scoping the expensive modules to crown jewel accounts, they were asked which security coverage they had actually surrendered, and could not name any.
If the same question produces a concrete answer in your estate, the wider scope is justified. If it produces a general unease about coverage, it is not. The adjacent platform comparison sits in the Palo Alto licensing guide.
Building a count the vendor has to accept
- Use your cloud billing data as the inventory, not the vendor connector scan, because your bill is the neutral record and a scan run during a busy week is not.
- Average across at least 90 days, and write the averaging method into the order form, since a peak based count can run double the term average in an elastic estate.
- Agree the ephemeral ratios explicitly, covering how spot nodes and short lived containers convert to billable workloads, because that conversion is fixed in the order form rather than in documentation.
- Separate production from non production and negotiate the treatment before signature, since development environments can often license at reduced rates or stay out of scope entirely if asked.
- Purge decommission drift, because dead accounts and orphaned resources persist in scans long after they have left your bill and they are counted at full rate until somebody removes them.
The cloud security negotiation brief
The workload counting rules, the averaging clause, module scoping by risk, and the competitive anchors that move a CNAPP quote.
Get the white paper →Negotiating a category with no published price
Most enterprise software negotiations start from a list price that both sides agree is fictional but which nonetheless functions as a shared reference: the discount is measurable against it, peers can be compared through it, and a buyer can state a target as a percentage.
This category removes that entirely. There is no public rate card, every enterprise deal is a bespoke quote, and the consequence is that a buyer walking in with only a target discount has nothing to attach it to.
What fills the vacuum, if the buyer does not fill it deliberately, is the vendor's own count. That is why the counting rules function as the price list here.
A workload is a defined conversion of virtual machines, container hosts, serverless functions, and data resources at ratios written into the order form; the averaging window determines whether elastic infrastructure is billed at its peak or its typical state.
And the module stack decides how much of the estate carries the expensive components.
Move any of those three and the bill moves, without a single conversation about rate. Move the rate alone and you have discounted a number the vendor constructed. The practical sequence follows from that.
Build the count yourself from billing data across ninety days, separating production from non production and flagging everything ephemeral. Fix the averaging method in the order form as a written clause.
Scope the runtime and data modules to the accounts where the risk justifies the rate, then expand later at pre agreed rates rather than buying the expansion now.
And bring a live competing quote, which moved the rate 15 to 30 percent in our file even where the security team had already standardised, because in a category with no published price a competitor's number is the only external anchor that exists.
Finally, prefer a multi year rate lock over a deeper single year discount, since a fast moving price book reprices annually and the lock is worth more than the extra points. The adjacent secure access market sits in the Zscaler negotiation guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across cloud security engagements, 2024 to 2025
Across roughly 10 to 14 cloud security negotiations advised in 2024 and 2025, the workload definition rather than the unit rate decided the spend:
How far unverified workload counts in first proposals exceeded the measured average once autoscaling and ephemeral infrastructure were counted correctly.
Proposal reduction achieved by scoping runtime and data security to crown jewel accounts, with no coverage loss the buyers could name.
Three patterns recurred: unverified workload counts running 20 to 40 percent above the measured average once autoscaling and ephemeral infrastructure were counted correctly.
Buyers scoping runtime sensors and data security posture to crown jewel accounts rather than estate wide cutting the proposal 25 to 35 percent with no security coverage loss they could name; and a live competing quote moving the rate 15 to 30 percent even in accounts that had already standardised.
The buyer side move is to treat the counting rules as the price list, build the count from billing data, fix the averaging method in writing, and scope the expensive modules to the risk rather than to the estate.
Your first five moves
- Build the workload count from your cloud billing data across at least 90 days, not from a vendor connector scan, because the bill is the neutral record and the scan is a snapshot of a moment.
- Write the averaging method into the order form, since a peak based count can run double the term average in an elastic estate and one sentence of contract language outperforms two discount points.
- Agree the ephemeral conversion ratios explicitly, covering spot nodes and short lived containers, and negotiate non production treatment before signature rather than at true up.
- Scope runtime and data security to crown jewel accounts, then apply the test that worked: ask which coverage you actually surrendered, and widen the scope only if the answer is concrete.
- Bring a live competing quote and prefer a multi year rate lock, because the quote moved the rate 15 to 30 percent even post standardisation and the price book reprices annually. Vendor Shield runs the count with you.
Frequently asked questions
How does Wiz pricing work?
On billable workloads averaged over the term, where a workload is not a server: virtual machines, container hosts, serverless functions, and data resources each convert to the meter at ratios fixed in the order form.
There is no public rate card, so every enterprise deal is a custom quote and the counting rules function as the price list.
Why does the workload count need auditing?
Because the first proposal almost always counts more workloads than you run. Autoscaling groups, short lived containers, and abandoned development accounts inflate a vendor connector scan, and unverified counts ran 20 to 40 percent above the measured average in our file.
The inflation compounds at renewal because it becomes the baseline.
What is the averaging clause and why does it matter?
It fixes whether the count is a peak, a monthly average, or a term average. In an elastic estate a peak based count can run double the term average, so the method changes the bill materially.
It is one sentence of contract language and it is worth more than two discount points, yet it is routinely left unwritten.
Which modules should be scoped narrowly?
Runtime sensors, data security posture, and code security. Core posture management belongs estate wide; the expensive add ons rarely do.
Buyers who scoped them to crown jewel accounts cut the proposal 25 to 35 percent and, when asked, could not name any security coverage they had actually surrendered.
Does a competing quote help if we have already standardised?
Yes, by 15 to 30 percent on the rate in our engagements, including in accounts where the security team had already chosen the platform.
In a category with no published price, a competitor's number is the only external anchor available, which is why it works even when switching is not genuinely on the table.
Should development environments be in scope?
Often not, or not at full rate. Non production environments can frequently license at reduced rates or stay out of scope entirely if the question is raised before signature.
Raised at true up instead, it becomes a request for a concession rather than a term in the original deal, which is a much weaker position.
Is a multi year term worth it here?
Usually, because the price book moves quickly and single year deals reprice at renewal against a rising baseline. A multi year rate lock is unusually valuable in this category for that reason, and it tends to be worth more than the additional points available on a deeper one year discount.
