The denominator behind
a security rate.

A security dashboard can show a rising incident percentage while every category of system improves. The arithmetic can be correct on both sides. What changed was the population behind the total.

That matters when a business acquires another operation, exposes more services to customers or moves work between environments. A comparison that ignores those changes can reward the wrong decision. It can also conceal a growing operational burden behind a reassuring adjusted score.

My 2017 doctoral thesis, The Quantification of Information Systems Risk: A Look at Quantitative Responses to Information Security Issues, connects human, system and software risks with statistical modelling, resource allocation and the distribution of costs and liability. The public university abstract describes that integrated programme. The calculation below is a separate, deliberately simple illustration of a measurement problem within it, not a result reported in the thesis.

Define who could enter the numerator

Suppose a business counts the proportion of eligible assets with at least one detected incident during a quarter. Each asset contributes once to the denominator and at most once to the numerator. Repeated alerts on one asset do not become additional affected assets.

For this hypothetical comparison, every eligible asset is observed for the whole quarter, the incident definition and detection procedure remain fixed, and each asset belongs to one of two pre-defined exposure classes. Those conditions make the arithmetic interpretable. They do not describe an audited organisation.

The first quarter contains 100 higher-exposure assets and 900 lower-exposure assets. Eight of the first group and eighteen of the second record an incident. The within-class proportions are 8% and 2%. Across the business, 26 of 1,000 assets are affected: 2.6%.

In the second quarter, the composition reverses. There are 900 higher-exposure assets and 100 lower-exposure assets. Sixty-three and one, respectively, record an incident. Both within-class proportions fall, to 7% and 1%. Yet the business now records 64 affected assets out of 1,000: 6.4%.

The aggregate percentage has risen by 3.8 percentage points while each within-class percentage has fallen by one percentage point. Higher-exposure assets account for 90% rather than 10% of the second quarter's denominator. No contradiction is involved.

Keep the weights beside the rates

The total is a weighted average. In the first quarter it is 0.1 × 8% + 0.9 × 2% = 2.6%. In the second it is 0.9 × 7% + 0.1 × 1% = 6.4%. Comparing the totals changes two things at once: the proportions affected within classes and the weights assigned to those classes.

A common reference mix separates one of those changes. With half the reference population in each class, the two standardised percentages are 5% and 4%. With the first quarter's 10:90 mix held fixed, they are 2.6% and 1.6%. Both comparisons show a one-percentage-point reduction because the reduction is identical in the two classes.

The level still depends on the chosen reference. A standardised percentage describes a specified comparison population. It should travel with those weights rather than acquire the authority of an unexplained headline number. If different classes improve by different amounts, the reference weights also affect the size of the reported change.

Reconcile the change in the workload

The case-mix exercise in the AI and institutions course already demonstrates how an aggregate comparison can reverse when the groups being served differ. Here the further question is how to reconcile a change in the affected-asset count with the two movements behind it.

Start with the first quarter's population and apply the second quarter's within-class percentages. That arithmetic benchmark gives 100 × 7% + 900 × 1% = 16 affected assets, ten fewer than the original 26. Next change the population to the second quarter's mix while holding those second-quarter percentages fixed. The benchmark rises from 16 to 64, an increase of 48. The two steps reconcile the observed increase: −10 + 48 = 38 affected assets.

The order and reference choices are explicit: first change the within-class percentages, then change the mix. In a more general case the allocation between the two steps can depend on that order. Here the common one-percentage-point reduction makes the alternative order give the same allocation. Either way, this is an arithmetic decomposition, not an estimate of how many incidents a particular control prevented.

Answer the operational question as well

The business still has 64 affected assets to investigate in the second quarter rather than 26. Standardisation does not remove that work. Nor does the increase in affected assets establish that a particular security team performed worse. The two descriptions answer different questions.

For staffing and response capacity, the actual workload matters, including repeated incidents, severity and time required. For a comparison of measured outcomes across a stable mix, the standardised result can be useful. For a claim that a control caused improvement, neither calculation is sufficient. Threat intensity, configuration, operator behaviour and unmeasured changes can still differ within the declared classes.

Deciding which assets enter the calculation is itself consequential. A newly discovered unmanaged server should not quietly disappear because it lacks a complete monitoring history. Its exclusion, observation period and reason for missing data belong in the report. A fleet count at the end of the quarter is not automatically a valid denominator for events collected throughout it.

Make the measurement reproducible

NIST's December 2024 measurement guide, section 3.1.4, warns that incident records drawn from only some organisational units, or from inconsistent reporting processes, undermine data validity. Its guidance on documentation and reporting puts scope and context alongside the measure. The practical implication is to preserve enough of the measurement process for another analyst to reconstruct the comparison.

I would retain the eligible population, observation window, affected-asset count, exposure class, detection coverage and reasons for exclusion. The class definitions should be established before inspecting which classification makes the result attractive. The report should show the observed total and the within-class values, with a separately labelled reference-mix calculation where that comparison serves a decision.

A useful check is to hold the class-specific percentages fixed and vary only the mix. A second holds the mix fixed and varies the percentages. These small tests reveal what a dashboard is capable of confusing before anyone uses it to assess a supplier or allocate a budget.

Preserve what the number cannot settle

The example uses exact invented counts. Real comparisons need uncertainty estimates appropriate to their sampling, repeated observations and dependence. More assets do not necessarily supply proportionally more independent evidence when one campaign or shared component affects many of them.

Detection remains a separate boundary, examined in The time before discovery. Better visibility can raise the recorded percentage without raising the underlying incidence. The present illustration holds that boundary still to isolate composition. A sound operational analysis would examine both.

A useful security measure needs an account of its population, its observation process and the decision it is meant to inform. Keeping those three visible makes a percentage more valuable than simply giving it another decimal place.