ENISA's CRA score needs an evidence backlog

A maturity score is useful for about five minutes. The durable part is the list of product-security work that somebody agrees to own after the score appears.

On 13 July, ENISA released a Cyber Resilience Act maturity model for small and medium-sized manufacturers. It divides product security into five domains, asks organisations to score practices from one to five and produces a basic, intermediate or advanced profile. The accompanying spreadsheet makes the exercise accessible. It also makes it dangerously easy to mistake a completed workbook for a completed security programme.

ENISA closes that escape route itself. Its guidance says scoring should rest on objective evidence rather than informal impressions, and that even an advanced profile is not proof of CRA compliance. The model is therefore best used as a backlog generator: each answer should point to a missing decision, record, control or test.

Start with one product

The assessment is not a general cyber-hygiene quiz. Its primary audience is an SME that manufactures and places a product with digital elements on the EU market. Importers, distributors, integrators and service providers can use the structure too, but the questions remain anchored in product security.

That boundary matters. A company-wide answer such as “we install patches quickly” is too vague when the real questions are which released products contain the vulnerable component, how long each product receives updates and which customers must be notified.

Before filling in the workbook, ENISA asks the organisation to identify products in CRA scope, determine their category and consider the applicable conformity-assessment route. The smallest workable starting set is one product record with:

• the commercial owner and technical owner;
• the current supported versions;
• the main third-party components and services;
• the declared security-support period;
• the channel for vulnerability reports;
• the person who can authorise an urgent release or customer notice.

Use the product with the nearest release or the largest installed base. A broad company score assembled from five different products will hide the exact gaps the exercise is meant to expose.

Five domains, five evidence folders

ENISA organises the model around governance and documentation; risk management and secure design; vulnerability and patch management; product life-cycle management; and awareness, competence and skills. Each domain contains five criteria, assessed from informal or absent practice at level one to governed and continuously improved practice at level five.

An SME does not need a new compliance platform to mirror that structure. Five folders or five headings in the existing work tracker are enough. The evidence should be ordinary operating material, not prose written only for an assessor.

ENISA domain	First evidence item	Useful owner
Governance and documentation	Product-security responsibility and management review note	Product lead
Risk and secure design	Product threat and misuse review linked to release decisions	Technical lead
Vulnerability and patches	Intake channel, component inventory and patch decision log	Engineering owner
Product life cycle	Supported-version list and end-of-support plan	Product owner
Awareness and skills	Role-specific training or review record	Team manager

Source: ENISA SME Cyber Resilience Maturity Assessment Model. Last verified 2026-07-14.

The column labelled “first evidence item” is deliberately singular. A small firm gains more from one maintained record per domain than from twenty templates created in a workshop and abandoned before the next release.

Score the evidence, not the confidence

The model’s five-point scale describes consistency, not ambition. Level two practices may exist but remain informal and dependent on individuals. At level three, practices are documented but not consistently applied. Levels four and five require repeatable use, review and improvement.

That distinction exposes a common scoring error. A founder who knows every dependency and personally handles every incident may feel advanced because the decisions are good. The process is still fragile if nobody else can find the product list, reproduce the decision or act during an absence.

For every answer above level one, attach or name the evidence before accepting the score. A policy alone does not establish that it is used. Better evidence includes a recent release checklist, a closed vulnerability ticket, a customer security notice, minutes from a risk review or a tested end-of-support decision.

Use a short evidence line:

Product / criterion / evidence link / owner / last used / next review

If the evidence cannot be found in ten minutes, lower the score or create the missing action. The purpose is not to defend the first answer. It is to make the next incident or assessment less dependent on memory.

Fix life cycle and incident work first

ENISA’s survey gives SMEs a useful priority signal. It covered 194 organisations in 31 countries, including 25 EU Member States. Sixty-six per cent had heard of the CRA, yet practical readiness lagged behind awareness. Medium-sized companies scored about one point higher than microcompanies across all five domains.

Incident response and product life-cycle management were the weakest areas, especially among microcompanies. More than 70% of respondents requested both technical-documentation templates and secure-development templates, while 142 respondents identified a need for financial support.

Templates can reduce blank-page work, but they do not decide who wakes up when an actively exploited vulnerability arrives. The CRA makes that concrete: Art. 14 reporting obligations apply from 11 September 2026, before most of the regulation applies on 11 December 2027.

An SME should therefore test one reporting-shaped incident now. Pick a supported product, introduce a credible severe security scenario and walk through four questions:

1. Who confirms that the affected component is present?
2. Who decides whether the event meets the reporting threshold?
3. Who can prepare the early warning and subsequent notification?
4. Who ships, verifies and communicates the fix?

Record the missing inputs and hand-offs. That exercise produces stronger evidence than raising a workbook score because a generic incident policy exists somewhere in the shared drive.

Build a 30-day backlog

The model will produce more gaps than a small team can close at once. Do not convert all of them into “high priority”. Rank the backlog by product exposure, deadline and dependency.

For each weak criterion, write one action in this form:

By [date], [owner] will produce or test [evidence] for [product].

Then choose no more than five actions for the first 30 days. A sensible first sequence is:

• confirm the product scope and supported versions;
• publish an internal vulnerability intake and escalation route;
• assign the person responsible for Art. 14 decisions;
• document one product-specific risk review;
• rehearse one vulnerability from discovery through patch and customer communication.

Repeat the ENISA assessment only after those actions have been used, not merely drafted. The next score should move because a release followed the secure-development check, a report reached the right owner or an end-of-support decision was communicated.

The workbook is a welcome piece of public infrastructure for firms that cannot absorb a heavyweight framework. Its best feature is not the automatic total. It is the way the questions reveal where product security still lives in one person’s head. Pick one product today, run the five domains against evidence and leave the meeting with owners rather than colours.