A restatement is the formal correction of a figure that has already been reported. The term comes from financial reporting, where the discipline around it is mature and the consequences of getting it wrong are well understood. Security measurement borrows the concept and rarely borrows the discipline.
An error is found in the calculation.
A definition changes materially and history is recomputed under the new formula.
Data that was missing arrives and materially changes a closed period.
A scope change means a previously reported population was wrong.
The common thread: a number that someone acted on, or presented, turns out to be different from what the record now says.
Three things have to happen together, and organizations routinely do the first without the other two.
Correct the value.
Preserve the original, with the reason for the change and the date it was made.
Tell the audience that received the original figure.
Skipping the second destroys the audit trail, since there is then no record that anything was reported differently. Skipping the third is worse, because someone who took a decision on the old number is still operating on it.
Not every correction is a restatement. A figure moving from 87.3 to 87.4 percent does not need a committee.
Set a materiality threshold in advance, expressed in terms that relate to how the metric is used. A change that would move the metric across a threshold band is material by definition. A change that would alter the direction of a reported trend is material regardless of size.
Deciding materiality after finding the error is how thresholds end up conveniently placed.
Finance restates and survives. It is treated as evidence that controls detected an error, not as evidence that the function is unreliable.
Security teams tend to hide corrections, which converts a manageable disclosure into a credibility problem when it surfaces later. A programme that has never restated anything in five years has either extraordinary data quality or a detection problem.
From the blog