Skip to content
Notifications
Clear all

Procurement question: What should I nail down in the contract to avoid surprise costs?

3 Posts
3 Users
0 Reactions
2 Views
(@charlie9)
Trusted Member
Joined: 7 days ago
Posts: 59
Topic starter   [#9055]

Everyone's going to tell you to watch the per-unit pricing and get a discount. That's the easy part. The real surprise costs with a platform like Anomali come from the assumptions they make about how you'll operate, and what they quietly consider an "add-on."

Here's what you need to lock down in ink. First, define "usage" in a way that can't be creatively interpreted. Is it per event? Per gigabyte ingested? Per monitored asset? Per user querying the system? Get the exact metric and the thresholds for each pricing tier. If they say "unlimited," make them define the "fair use" policy that inevitably accompanies it.

Second, nail down the data retention and egress costs. Your historical data is a hostage situation waiting to happen. Contractually specify the included retention period (e.g., 90 days hot, 1 year cold) and the exact cost to extend it. More importantly, get the cost to get your own data *out* in a usable format if you switch later. That's often an astronomical line item they spring on you.

Finally, force clarity on integration and support. "Standard support" usually means business hours and a 48-hour SLA. If you need 24/7 for an IR tool, that's a 30% premium. Ask if their API calls for automated ingestion or orchestration have rate limits, and if exceeding those limits requires a more expensive "enterprise" API tier. Assume every feature demoed that isn't in the core data sheet is a future charge.

Don't let them bundle "professional services" into the deal to hide the true platform cost. Get a fixed-price statement of work for implementation, separate from the subscription. Otherwise, you'll be on the hook when their "standard" 40-hour setup ballooned to 200 hours because your environment wasn't "standard."

/charlie


Show me the TCO.


   
Quote
(@data_pipeline_tinker)
Estimable Member
Joined: 3 months ago
Posts: 122
 

Absolutely right about defining "usage." I'd push for the contract to include a real-world example calculation in an appendix. For instance, a sample monthly invoice based on your projected volume. That forces concrete definitions for every variable.

Your point on data egress is critical, but also check the format. "Usable format" can mean raw logs in compressed archives, which are useless without the platform's parsing logic. You need the cost and feasibility of extracting *enriched* data or the transformation logic itself, especially if you've built custom parsers.

One more area: API call limits and costs. If you're syncing alerts to a SIEM or pulling data into a warehouse for historical analysis, those programmatic accesses often fall outside "user queries" and into a separate metered bucket.


Extract, transform, trust


   
ReplyQuote
(@johnd)
Trusted Member
Joined: 7 days ago
Posts: 52
 

Forcing them to provide a sample invoice is smart. I've seen those examples get watered down with tiny asterisks referencing other sections. You need to bind them: the example calculation is the *primary* definition of terms, and the contract text is just backup.

On the "enriched data" extraction point, that's where the real lock-in lives. They'll quote you a fortune for the parsed data, far above the raw log egress. It's a strategic choice - pay their tax to leave or stay hostage.

Agreed on API calls. They'll call it "system integration" and price it like a whole new module. Get the call limits, the overage rate, and a guarantee the rate card won't change for the term.


—Skeptic


   
ReplyQuote