Every funded programme, every platform team and every quarterly review produces indicators. The interesting question has never been how many you have. It is how many of them anyone has ever checked.
An indicator without a baseline and a target is not a metric. It is a sentence with a number in it. The difference matters because the second kind cannot be wrong, and something that cannot be wrong cannot inform a decision.
A recent audit of EU cybersecurity spending happens to contain an unusually clean set of examples, so the theory below comes with evidence attached.
Four tests
An indicator earns the name metric when it passes all four of these. Three out of four is not a pass.
- Baseline. What is the value today, measured before anything changes. Without it, improvement is unprovable in either direction.
- Target. What value counts as success, and by when. Without it, any result can be presented as progress.
- Measurability. Who computes it, from which data, and can they do it again next quarter and get a comparable number.
- Owner. A named person accountable for the figure being correct. Not the team. A person.
Anything failing one of these is decoration. It may still be worth collecting, but it should not appear on a slide next to a decision.
The counterexamples are better than the theory
The auditors reproduce two indicators verbatim, and both are instructive (Box 5).
The first: "at least 20 % improvement in staff preparedness". There is no baseline and no target value. Twenty per cent of what, measured how, against which starting point? The sentence sounds quantitative and cannot be evaluated at all.
The second: "final report at the end of the funding period" used as a performance indicator. That is a deliverable. It measures that the project ended, which it was going to do regardless of whether anything was achieved.
Around those two, the structural picture: milestones per project ranged from 8 to 39 and deliverables from 8 to 45, against instructions that asked for a limited number tied to the main outputs (para. 99). Seven projects defined 20 or more indicators. One defined 52 (para. 101).
More indicators, less measurement
Fifty-two indicators is not fifty-two times the insight. It is a reliable way to ensure that none of them is verified.
The reason is arithmetic rather than attitude. Every indicator carries a recurring cost: collect the data, compute the value, check that the computation was right. The budget for that work is roughly fixed, because it is somebody's Thursday afternoon. Past a certain count, adding an indicator does not add measurement, it dilutes it. The set grows and the verified share shrinks.
The audit shows the dilution directly. Of seven projects that were due to report programme indicators at mid-term, three did so. Of those three, two reported incorrectly: one used the wrong indicator, and the other reported target values in place of achieved results (para. 105).
Read that again as an engineer. The failure was not in the ambition or the design of the programme. It was that four projects did not report at all and two of the three that did got it wrong, and the framework had no way of noticing either.
Green is not a state, it is an absence of looking
The strongest finding in this part of the report is worth stating plainly.
Cybersecurity indicators for the DIGITAL programme were reported as on track for 2024. The auditors found that the data collected did not match the reported values, that it was unclear how the final figure had been calculated, and that they found no evidence anyone had verified whether it was correct (para. 106).
It is worth being precise about what that is and what it is not. Nobody needs to have lied for this to happen. It happens when verification is not written down as anyone's task. The number then travels from collection to dashboard without passing through a check, and it arrives looking exactly like a number that did.
This is the part that transfers. A dashboard reported as green tells you one of two things and does not distinguish between them: either the state is healthy, or nobody looked. From the outside the two are identical, and the second is more common because it is cheaper.
The same mistake you already recognise
Anyone who has run infrastructure knows this failure in another costume.
An alert that has never fired is assumed to be working. An indicator that has never been verified is assumed to be correct. Both are signals that are generated and delivered but never consumed, and in both cases the system looks healthy precisely because the component that would notice a problem is the one that is missing.
The practical consequence is the same in both cases too: you do not find out by looking at the dashboard. You find out by deliberately testing the path.
What to do instead
- Prefer few indicators you verify to many you do not. If you cannot name who checks an indicator and when, delete it. A smaller set that is actually audited is worth more than a comprehensive one that is not.
- Write the baseline down before you start. Retrospective baselines are reconstructions, and reconstructions drift towards whatever makes the result look reasonable.
- Separate deliverables from performance. "The report was delivered" belongs in a project plan. It does not belong in a performance framework.
- Put a name on every indicator. Ownership by committee means the verification step has no owner, which means it does not happen.
- Verify at least once before anyone makes a decision on the number. The first time an indicator is used to justify something is the worst possible moment to discover that nobody knows how it is computed.
None of this is sophisticated. It is the metric equivalent of restoring a backup to see whether the backup works. The reason it gets skipped is not that it is hard, it is that skipping it produces no visible consequence until the moment the number matters.
Source: European Court of Auditors, Special Report 19/2026, "Detecting and responding to cybersecurity incidents", adopted 16 June 2026. Available at eca.europa.eu under CC BY 4.0. Paragraph numbers in the text refer to the report so the findings can be checked.