Home › Articles › ArcSight ESM versus Logger licensing compared
ArcSight & Security · Track 03

ArcSight ESM versus Logger licensing compared

ArcSight ESM and ArcSight Logger are often deployed side by side, but they are licensed on different principles, and an audit that blurs the two will price you on the wrong metric. Comparing ArcSight ESM versus Logger licensing is not an academic exercise; it is the difference between defending the right number and conceding the wrong one. When a finding mixes the two, the first defensive move is to separate them.

ArcSight Enterprise Security Manager is the correlation and analytics engine, the platform that takes in normalised events and applies rules, dashboards, and use cases. ArcSight Logger is the log retention and search platform, built to store and query large volumes of event data over time. Because both ingest events, both have a volume dimension, and an audit can conflate the throughput of one with the entitlement of the other. Understanding which product is metered on what is the foundation of a clean defense.

What ESM is licensed on

ESM is typically licensed against an events per second entitlement, the sustained rate of correlated events the platform is authorised to process. The familiar burst versus sustained dispute lives here, and we treat it the same way we do in ArcSight EPS burst versus sustained measurement. The trap is that ESM EPS is sometimes confused with raw ingestion at the connector layer, when the metric that matters is the correlated event rate the agreement describes.

What Logger is licensed on

Logger is generally licensed against a data volume metric, commonly a daily ingestion figure expressed in gigabytes per day, which is exactly the model we examine in ArcSight GB per day versus EPS metric models. The trap on Logger is raw versus normalised volume and the inclusion of duplicate or non production data, the same pattern we describe when we show how ArcSight data volume metrics inflate a finding. A daily volume measured at raw ingestion overstates what a normalised count would show.

The mechanic

A finding that applies an EPS gap to ESM and a volume gap to Logger, but draws both numbers from the same raw connector throughput, can count the same events twice: once as a correlated rate and once as retained volume. Separating the two products and their distinct metrics removes the double count.

Why conflating the two inflates the finding

When an audit treats ESM and Logger as a single security platform with a single volume, it tends to apply the most expensive reading to the combined figure. Events that flow to Logger for retention may never be correlated by ESM, yet a blended measurement can price them against both entitlements. The defense is to map the data path: which events reach ESM for correlation, which reach Logger for storage, and which reach both, so each product is measured only against the load it actually carries.

How the four operations apply to an ESM versus Logger finding

We respond by taking over the channel during the seven day notice window so no blended export reaches the vendor unmanaged. We reconstruct the data path and the separate ESM and Logger profiles from the platform's own statistics. We rebut by assigning each metric to its correct product, removing double counted events, and applying the sustained rate to ESM and the normalised volume to Logger. We resolve on figures that reflect each product's real load and convert forward with the two metrics defined distinctly.

A representative pattern

In a recent engagement, a security finding had blended ESM correlation throughput and Logger retention volume into a single overclaim. Separating the products, and showing that a large share of retained events were never correlated, removed a substantial double count before settlement. The shape is consistent with our anonymised banking matter, case file E-03, where a $6.0M ArcSight finding settled at $1.8M, a 70 percent reduction, once the measurement basis was corrected.

The questions that decide an ESM versus Logger dispute

Mapping the data path before the vendor does

The practical work that separates an ESM finding from a Logger finding is mapping the data path: tracing which events are correlated by ESM, which are retained by Logger, and which pass through both. That map is built from the platform's own configuration and statistics, not from a vendor estimate, and it is the evidence that prevents a single event stream from being priced against two entitlements. Without it, an audit can treat the whole security platform as one metered quantity and apply the most expensive reading to the total.

Doing this before any measurement script runs is the same discipline we bring to every security engagement, because the remedy stacks the same way: a deemed shortfall is priced at list, with back maintenance, a first year of forward maintenance, and audit costs added on top. A double counted event therefore inflates two stacks at once. Separating ESM from Logger at the data path level removes that overlap at its source, which is far more durable than arguing the combined number down after it has been fixed in a report.

There is a forward looking benefit too. When the two products are documented as separate metered quantities with a clear data path between them, the conversion that follows a finding can carry that separation into the new agreement. An OpenPass framework that defines the ESM rate and the Logger volume distinctly, rather than as a single blended security entitlement, denies the next audit the same ambiguity this one exploited, and stops a buyer paying twice for one flow of data in every year that follows.

Have a blended ESM and Logger finding?

A finding that mixes ESM and Logger metrics almost always double counts somewhere. We separate the products and the metrics before any vendor script runs, through our ArcSight and Security audit defense. To put a defense team between you and the vendor, open a case or download the ArcSight EPS defense briefing.

Get The Number Down →

Related field notes

These notes from the ArcSight and Security cluster go deeper on the metrics behind ESM and Logger. Each links back to the complete OpenText audit defense playbook for 2026.

If you have received an OpenText or Micro Focus audit notice, the first seven days shape every week that follows. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, cut the average finding by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.