Average Volume

The frequency component of an application usage score. It measures how much activity is logged per user over a month, giving a sense of intensity rather than reach or consistency. A higher volume suggests deeper use, but it does not by itself prove broad adoption or sustained engagement.

Expanded Definition

Average volume describes the frequency component of an application usage score. It measures how much activity is logged per user over a month, so it captures intensity of use rather than reach or consistency. A score can show high volume even when adoption is narrow, which is why it should be read alongside other usage signals.

In practice, this term is often used to compare how heavily a product, feature, or workflow is used across a population. The key boundary is that volume is about quantity, not breadth. A small set of power users can create a high average volume without indicating that the wider user base depends on the system. That distinction matters when teams are evaluating adoption, entitlement fit, or operational load.

Because definitions vary across analytics vendors and internal reporting models, the exact formula may differ. Some teams normalise by active user, while others treat volume as one component inside a composite score. For a broader NHI governance context, NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in its Ultimate Guide to NHIs, which shows why raw usage numbers need context before they are treated as evidence of real operational reliance.

Examples and Use Cases

Average volume appears in usage analysis when teams need to understand how intensely an application or workflow is exercised, not just whether it is present in the environment.

• A SaaS owner reviews monthly log volume per active user to identify a feature that is heavily used by a small but critical cohort.
• An IAM team compares average volume across applications to spot systems that may create outsized authentication, API, or support load.
• A security program uses volume signals to distinguish routine service usage from low-frequency access paths that may be candidates for review.
• A product team measures whether a rollout changed user behavior by comparing pre- and post-launch average volume.
• An operations team checks whether a spike in average volume reflects genuine adoption or a temporary burst driven by automation, testing, or migration activity.

The tradeoff is that volume can be informative but misleading if it is interpreted without reach, tenure, or consistency. A high number may indicate deep engagement, but it may also reflect a narrow set of automated or unusually active users. When the metric is used in access or workload analysis, the interpretation should stay close to the underlying event source.

Security Implications

Average volume becomes security-relevant when organisations mistake activity intensity for healthy adoption or trustworthy usage. A high-volume pattern can hide concentration risk, where a few accounts or workloads drive most of the observed activity. That can mask over-privilege, automation sprawl, or dependency on a small set of identities that are hard to rotate or offboard cleanly.

When volume is used as a proxy for value, teams may under-review accounts that are noisy but structurally risky, especially in environments with service accounts, API keys, or other machine actors. In NHI-heavy environments, that is a practical blind spot because active usage does not mean the credential is well governed. NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which shows how operationally expensive weak control can become when usage outpaces governance.

Observable symptoms include persistent high activity from a small identity set, activity spikes that are not explained by business change, and access paths that remain busy long after their original purpose should have ended. These are often signals to investigate ownership, rotation, or entitlement scope rather than treating the metric as proof of legitimacy.

Domain and Governance Relevance

In governance terms, average volume is useful when it helps distinguish deeply embedded usage from superficial presence. That matters in portfolio review, access certification, and workload prioritisation because the control question is not only “is it used?” but also “how intensively is it relied on?” The answer changes how much operational disruption a revocation or redesign would cause.

For NHI and machine identity programs, volume can help identify which service accounts, tokens, or API clients sit on the critical path and therefore deserve stronger ownership, tighter review cadence, and better lifecycle controls. It should not, however, be used alone to justify trust. High usage can coexist with poor rotation discipline, broad privilege, or hard-coded credentials, so governance must pair the metric with identity provenance and control state.

That makes average volume a decision-support measure rather than a control in itself. Used well, it helps teams separate “popular” from “operationally embedded” and avoid removing or weakening a dependency without understanding the blast radius.

Related resources from NHI Mgmt Group

• How should security teams prioritize sensitive data findings without relying on volume alone?
• What is the difference between alert volume and effective DLP monitoring?
• Why do build pipelines become riskier when AI increases code volume?
• Should organisations prioritise simulation clarity or campaign volume first?