According to a 2025 ISACA study, 67% of European organisations believe their GRC maturity is higher than what their auditors observe. This gap in perception is not a tooling problem: it is a method problem. The most common maturity audits measure artefacts, not behaviours. They certify the existence of policies, not their operational effectiveness. Here are the four biases that turn a maturity audit into a communications exercise, and what to measure instead.
The context: why GRC maturity is structurally over-declared
The principle of a GRC maturity audit is appealing: place the organisation on a scale of 1 to 5 (CMMI, ISO 33001, or a proprietary model), identify gaps, prioritise efforts. In theory, it is a valuable steering tool. In practice, two dynamics systematically distort it.
The first is self-assessment. Most GRC maturity frameworks rely on questionnaires completed by the teams being assessed. These teams have an institutional interest in declaring a high level: towards their management, their partners and sometimes their regulators. The social pressure is real, even when it is unconscious.
The second is the confusion between artefact and effectiveness. Having a documented risk management policy is a necessary condition, not a sufficient one. What matters is that the policy is understood, applied and able to withstand a real situation. Yet this is precisely what standard maturity models do not measure, or do not measure well.
NIS2 and DORA have made the phenomenon worse: faced with formal compliance obligations, organisations have produced documentation in volume. Risk registers exist. Incident response plans exist. Access management policies exist. What is missing is the demonstration that these documents match operational reality.
Error 1: measuring the presence of documents, not their enforceability
The first error is the most widespread. A classic maturity audit checks the existence of policies, the coverage of frameworks, and the presence of validation signatures. These are indicators of documentary compliance, not of operational maturity.
What experienced auditors measure instead: the ability of teams to locate and apply a document without external help. Ask an operational manager to show you, in real time, the procedure to follow in the event of a security incident. If the answer takes more than two minutes, or involves contacting the CISO to find out where to look, the declared maturity level is artificial.
The common mistake to avoid: assessing maturity on the basis of prepared presentations. Organisations that know they will be audited prepare their answers. A genuinely mature organisation does not need to prepare: its processes are embedded in daily practice, not in archived files.
Practical application: introduce "unannounced discovery tests" into your audits, that is, ad hoc requests made to operational teams without notice. The response you get is your real maturity level.
Error 2: confusing control coverage with control effectiveness
Maturity frameworks generally ask: "Do you have a control for X?" The answer is almost always yes, in the sense that something exists that can be presented as a control. What the questionnaire does not ask: did this control work during the last three events for which it should have been triggered?
A documented example from a NIS2 audit in 2025: a mid-market organisation declared a control reviewing access to high-privilege accounts. The policy existed. The review schedule was documented. Maturity score: 4/5. Reality observed during the in-depth audit: the last effective review dated back 14 months. The control existed, but it did not work.
What experienced auditors measure instead: evidence of execution. Not the existence of the process, but the traces of its implementation. For each critical control, ask for the last three instances of its activation, with date, owner and result. DORA RTS Article 9 is explicit: controls must be tested periodically and the results documented.
Error 3: assessing maturity outside an incident context
The third error is perhaps the most costly: measuring maturity under normal conditions, not under degraded conditions. A mature GRC programme must demonstrate its value precisely when conditions are difficult: during a crisis, under pressure, with overstretched teams.
Yet maturity audits almost always take place in optimal conditions: prior preparation, available teams, documentation at hand. They measure the programme's maturity in its best possible configuration, not in the configuration where its maturity really matters.
The most costly incidents of recent years share a common feature: the affected organisations had reasonable GRC maturity scores. Their processes worked, until the moment they no longer did. The pressure of the incident revealed fragilities invisible under the normal conditions of assessment.
What experienced auditors measure instead: the resilience of processes under constraint. Organise exercises in which usual resources are artificially reduced: the CISO is unavailable, the ticketing system is down, access to documentation is temporarily cut off. How your team responds to this constraint is your real maturity.
Practical application: include an annual degraded-conditions simulation exercise in your GRC programme. The weaknesses identified in this exercise are the only ones that count.
Error 4: neglecting governance maturity in favour of technical maturity
GRC maturity models were historically built by technical specialists, for technical specialists. They measure the technical depth of controls well. They measure the quality of governance in the organisational sense poorly. Yet NIS2 (Article 20) and DORA (Article 5) are explicit: responsibility for managing ICT risk rests with the management body.
In concrete terms: does your Board of Directors or your Executive Committee receive ICT risk reporting with sufficient frequency and quality to take informed decisions? Are these decisions documented and traceable? Are risk trade-offs formally validated at the appropriate level of responsibility? A GRC programme that is technically mature but has no decision-making escalation to management is immature in the sense of NIS2 and DORA, whatever its scores on technical frameworks.
What experienced auditors measure instead: the decision cycle for risk. From the detection of a risk to its documented treatment, passing through its escalation to the right governance level: how long does it take? With what evidence? Is that evidence auditable?
Assessing your real maturity: three unfiltered questions
Ask an operational employee, without notice, to show you how they would report a security incident. If the answer involves searching for where the procedure is kept, your declared maturity is overestimated.
Ask your GRC team for the evidence of execution for the five NIS2/DORA controls you consider most critical, not the policies, the evidence. If this evidence is not available within 30 minutes, your control coverage is documentary, not operational.
Ask your executive management which ICT risk decision it has taken and documented in the last 90 days. If the answer is vague, your risk governance does not meet NIS2 and DORA requirements, regardless of your technical maturity score.
Presidio structures the collection of execution evidence, the traceability of risk decisions and the generation of management reporting in a single register, compliant with NIS2 and DORA: contact our team for a 30-minute diagnostic. Also read: IAM and NIS2/DORA: the access control your audit will flag first.
Conclusion
GRC maturity is measured under difficult conditions, not ideal ones. Organisations that reach genuine operational maturity share one characteristic: they treat maturity audits as improvement tools, not as communications exercises. They measure the effectiveness of their controls, not their existence. They test their processes under constraint, not in prepared conditions. In your context, what would the result of an unannounced discovery test on your most critical processes be?