Filling in a maturity score takes about 4 seconds. You look at the control, you think about how things are probably set up, you pick a number between one and five.
Defending that number when someone asks where it came from takes considerably longer. Usually because the honest answer is that three people were interviewed and their perceptions were averaged.
That is the state of most maturity assessments, and it is the reason board reporting on security still feels like an opinion piece. This is about what changes when the evidence behind a score is collected automatically instead of assembled by hand.
The subjective maturity assessment
The traditional method is straightforward enough. You ask several users how a particular system is implemented, and they give you their perspective.
The problem is not that people lie. It is that a perspective is not a measurement. Someone describes how a control was designed, or how it worked the last time they looked at it, or how they assume a colleague configured it. All of those are reasonable answers. None of them are data.
"You ask several people how something is implemented, and they give you their perspective."
By the time that report reaches the management table, it describes a situation that may already have changed. And when the auditor asks the follow-up question, there is nothing underneath the number to point at.
What CyFun actually asks for
NIS2 itself does not prescribe how you score a control. CyFun, the Belgian interpretation of NIS2 maintained by the CCB, does: it asks for two separate scores per requirement, a documentation score and an implementation score. If you are in scope for NIS2 in Belgium, CyFun is the framework you will be measured against, which makes that split your working reality.
That split is not administrative tidiness. It is the whole diagnostic value of the framework.
A domain scoring poorly on documentation and a domain scoring poorly on implementation look identical in a single averaged number. They are entirely different problems. One means the policy does not describe what the standard requires. The other means the technology does not do what the policy describes. Different fix, different owner, different timeline.
Frameworks typically carry between one hundred and two hundred controls. Scoring each of them twice, honestly, with evidence, is exactly the volume of work that pushes organisations towards estimating.
When evidence attaches itself to the right control
This is where the manual effort actually sits. Not in deciding the score, but in gathering the proof and mapping it to the correct control.
Cyfora inverts that. The analyses that have already run, the technology best practice checks and the policy analysis, are treated as evidence and mapped automatically to the controls they support.
Open a sub-requirement and you get the guidance first: what the standard is looking for, in detail. Then the documentation score and the implementation score side by side. Then the evidence, already attached. In the demo environment, the documentation evidence for one requirement shows 85% maturity, pulled from the policy analysis rather than assembled by a compliance officer.
From there, scoring becomes a judgement supported by data rather than a guess dressed as one. You look at the evidence, conclude this is at least a four out of five, open manage, set the score, add a comment, attach anything else you consider relevant, and submit. The score updates and the reasoning travels with it.
"A score you can defend, not one you had to assume."
The difference in effort is significant, but the difference in confidence matters more. You are no longer working through every policy document to establish what is described and what is missing. That analysis already happened.
Same weak score, two different owners
Take a domain scoring below target. Asset management, for instance, where one requirement sits at 3.5 and clears the threshold in green, while the one above it sits at 2.8 and does not.
The useful question is not "why is 2.8 low". It is "which half of 2.8 is low".
The spider chart answers this directly. Switch to a function level view for a board audience, then filter on documentation maturity and see how the picture changes. Filter on implementation and watch it change again. Domains that look equally weak in the combined view often separate sharply the moment you split them.
That filter is a work allocation tool. Documentation weakness goes to the policy owner. Implementation weakness goes to the engineering team. Sending both to the same person, which is what an averaged score effectively does, guarantees that one of the two problems gets ignored.
Why history matters as much as the score
A board asks a deceptively simple question: were our controls in order?
The tense is the trap. Most reporting answers "were they in order at the point of the last assessment", which for an annual cycle can mean eleven months ago.
Every time a maturity score changes, Cyfora retains the data behind both states: the previous situation and the new one, with the detailed report for each. That turns a score into a timeline.
For troubleshooting, that timeline tells you when something moved and what it looked like before. For an audit, it demonstrates something stronger than a good score: it demonstrates that you were watching. A control that dipped and recovered, with the evidence for both, is a better story than a control that has read four out of five on every annual report since 2023.
From assumption to demonstrable control
Compliance is not the same thing as security, and a score is not the same thing as proof. The organisations that get caught out are rarely the ones with low scores. They are the ones whose high scores turned out to rest on nothing in particular.
Cyfora attaches the evidence to the control automatically, keeps documentation and implementation separate the way CyFun prescribes, and retains the history behind every change. What you present to your board or your auditor is a position you can substantiate.
Want to see what your own controls would score with the evidence attached?
