Skip to content
Notifications
Clear all

Did you see the new pricing model? It's per 'user seat' now, not data volume.

1 Posts
1 Users
0 Reactions
0 Views
(@emilyr)
Estimable Member
Joined: 1 week ago
Posts: 92
Topic starter   [#10246]

I've been conducting a thorough analysis of Anomali's newly announced pricing model shift, moving from a data-ingestion volume basis to a per-user-seat subscription. This is a significant strategic pivot that warrants a detailed breakdown of its operational and financial implications, particularly for larger enterprises with complex Security Operations Center (SOC) structures.

From an observability and cost optimization perspective, this change fundamentally alters the Total Cost of Ownership (TCO) calculation. Previously, cost scaling was somewhat predictable and tied directly to infrastructure output: more logs, more telemetry, higher cost. The new model shifts the cost driver to human capital.

**Key considerations and potential pitfalls I've identified:**

* **User Definition Ambiguity:** The critical question is how Anomali defines a "user seat." Is it:
* A named user with a dedicated login?
* A concurrent user (floating license)?
* Does it include "read-only" users, such as managers or auditors who need dashboard access but don't perform investigations?
* How are API service accounts treated? If a SOAR platform or custom script uses the Anomali API to query threats, does that consume a seat?

* **Cost Predictability vs. Scalability:** While this model offers predictable annual costs, it may disincentivize broadening platform access within the organization. Under the old model, adding a new junior analyst or onboarding a new department had negligible direct cost impact. Now, each addition has a direct, recurring license fee. This could lead to inefficient sharing of credentials or access gaps.

* **Impact on Incident Response & SRE Practices:** In a high-severity incident, you might need to temporarily bring in additional personnel from other teams (network, cloud, applications) to assist with threat hunting and log analysis. Under a strict per-seat model, this flexible, elastic response becomes either logistically difficult or unexpectedly expensive if temporary seats must be procured.

This model appears advantageous for smaller teams with a fixed number of primary users, as it decouples cost from potential data spikes during incidents. However, for a large-scale organization with a tiered SOC, a 24/7 shift model (where multiple people share responsibility for a single role), and extensive integration requirements, the financial calculus has changed dramatically. I am particularly interested in how this interacts with data retention periods and advanced analytics features. Are those now all-inclusive, or are there still usage-based overages?

I would like to gather data points from other community members to benchmark this shift. Specifically:

* For those who have received quotes under the new model, what is the precise definition of a "seat" in your contract?
* Have you observed any changes in the included features or data limits alongside this pricing change?
* How does your per-seat cost compare to your previous data-ingestion costs, normalized per primary user?



   
Quote