Home › Articles › Sentinel event and data volume audit considerations
ArcSight & Security · Track 03

Sentinel event and data volume audit considerations

When an OpenText audit turns to Sentinel, the number that drives the finding is volume: events ingested, data collected, and the rate at which both move through the platform. The dispute is almost never whether you collect security data. It is whether the vendor is allowed to price you on a volume reading that includes everything your system absorbed rather than the load it was sized for. Sentinel event and data volume audit considerations decide where that finding lands.

NetIQ Sentinel is licensed against event and data volume metrics that look objective but rest on definitions that an audit can stretch. Event volume can be measured as a rate, a daily total, or a cumulative figure. Data volume can be counted before or after normalisation, and with or without the duplicate, test, and machine generated noise that a security platform necessarily takes in. A finding built on the largest available reading of those metrics will overstate consumption against the operating profile the agreement was meant to cover.

What Sentinel meters, and the definitions that move the number

The first question in any Sentinel engagement is what the agreement actually meters and over what window. An event volume measured as a peak rate is a different quantity from the same volume measured as a sustained daily average, and the gap between the two can be large on a platform that absorbs scan storms and backup windows. A data volume counted at raw ingestion includes parsing overhead and duplicate events that a normalised count would collapse. Where the contract is silent on which reading governs, the vendor measurement defaults to the larger one. The same burst versus sustained logic that drives an EPS dispute applies here, which is why these notes sit alongside our work on ArcSight GB per day versus EPS metric models.

The mechanic

A Sentinel deployment sized for a steady daily volume can record a far larger figure on a day that includes a vulnerability scan, a patch rollout, and a chatty log source looping duplicates. Pricing the gap between that spike and entitlement at list, then adding back maintenance and audit cost, builds a finding on data the platform was designed to absorb and clear.

The data that should come out of the volume

When we reconstruct a Sentinel position, several categories reduce the billable volume. Duplicate events from misconfigured or overlapping sources are noise, not distinct security telemetry. Non production and lab data collected for testing is not production load. Machine generated bursts from scans, backups, and one time incidents are transients the architecture tolerates by design, the same way we treat them when we show how ArcSight data volume metrics inflate a finding. And data from sources that were later decommissioned should not be counted against a forward looking entitlement.

How the four operations apply to a Sentinel finding

We respond first, taking over the channel during the seven day notice window so no raw volume export reaches the vendor unmanaged. We reconstruct the volume profile from Sentinel's own ingestion and collection statistics, building a distribution rather than accepting a single maximum. We rebut by isolating duplicates, non production data, and transient bursts, and by reading the entitlement to determine which volume measurement the contract supports. We resolve on a defensible figure and convert forward with the metric defined so the same ambiguity cannot be reused.

Why volume is bursty by design

Security telemetry is uneven by nature. A quiet hour produces a fraction of the volume of an hour that includes an attack, a scan, or a deployment. A platform engineered only for its average volume would drop data the moment anything interesting happened, defeating the purpose of security monitoring. So the headroom Sentinel carries is not spare licensing you quietly consumed; it is the resilience the product was sold with. A peak volume is evidence the platform did its job under load, not evidence you operated at a higher licensed tier. We make that point explicitly, because it reframes what the number describes.

A representative pattern

In a recent engagement, a security volume finding rested on a raw ingestion figure that bundled duplicate events and a scan window into the billable total. Once the duplicates were collapsed and the transient isolated, the defensible volume fell well below the headline, and the discussion moved to a number the contract actually supported. The shape echoes our anonymised banking matter, case file E-03, where a $6.0M ArcSight finding settled at $1.8M, a 70 percent reduction, after the measurement basis was corrected.

The questions that decide a Sentinel volume dispute

Answering those with Sentinel's own statistics is how a volume finding comes down to the load the platform was actually licensed to carry.

Why the volume remedy is worth contesting in full

A Sentinel volume overclaim is expensive for the same reason every OpenText finding is expensive: the remedy stacks. A deemed shortfall is priced at the then current list price, back maintenance and support are added, a first year of maintenance on the newly deemed licences follows, and the cost of the audit is reimbursed. So a daily volume figure that is overstated by duplicates and transients does not inflate one charge; it inflates the whole stack. Every gigabyte of duplicate or non production data removed from the billable total reduces list price, back support, and forward maintenance together.

That arithmetic is the reason we reconstruct the volume profile before the vendor fixes a number rather than after. Once a raw figure is recorded in a report it anchors the entire remedy calculation, and walking it back means arguing against the vendor's own measurement. Establishing the normalised, deduplicated, production only volume first means the stack is built on a defensible base from the outset.

Have a Sentinel volume finding on the table?

A volume finding priced on raw ingestion is among the most reducible security overclaims we see. We reconstruct the volume profile before any vendor script runs, then challenge the finding line by line through our ArcSight and Security audit defense. To put a defense team between you and the vendor, open a case or download the ArcSight and security defense briefing.

Get The Number Down →

Related field notes

These notes from the ArcSight and Security cluster go deeper on the volume and metric questions above. 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.