ENISA — Where do SMEs stand in preparing for the Cyber Resilience Act?
The value of a maturity model is not in the score
ENISA published a cyber resilience maturity assessment model aimed at micro, small and medium-sized businesses, in the context of their preparation for the Cyber Resilience Act. The model can serve to start a conversation, but it does not replace a technical decision, an audit or a legal evaluation.
The useful question is not just “what level we have”, but what products and services are within scope, what risks affect users and operations, what controls actually exist and what evidence allows us to verify that they work.
1. Set the scope before evaluating
Start with a specific list: your own software, web applications, integrations, third-party components, cloud services and update processes. It is not advisable to evaluate “the company” as an abstract block: risk and responsiveness can be different between a customer portal, an API and an internal tool.
- Functional and technical manager.
- Supported data and operations.
- Dependencies and suppliers.
- Deployment, update and exhibition.
- Available evidence and known gaps.
2. Turn the assessment into testable questions
A self-assessment improves when each response can be contrasted. Ask if there are security criteria before accepting a feature, if dependencies are reviewed before releasing, if there is separation between development and production, if vulnerabilities are logged, and if backups and recovery are tested.
Classify each answer as implemented, partial, not implemented o not applicable with justification. "Not applicable" must explain who decided it and what evidence supports it.
3. Separate control, evidence and result
“There is a procedure” describes a documented control. “The procedure was applied in these versions” describes evidence of execution. “The test showed that the control works for this risk” describes a validation result. Separating these phrases prevents the documentation from appearing more mature than can be demonstrated.
4. Prioritize by risk and capacity for change
Not every gap must be resolved at once. It combines possible impact, exposure, known ease of abuse, dependence on third parties, detection capacity, mitigation effort and actual ability of the team to maintain control.
The result must be converted into a backlog with responsible person, priority and observable completion condition. For example: inventory dependencies of an application, record the severity and target date of each open vulnerability, or run a test restore and fix the flaw found.
Relationship with Blue Moon services
This approach can be connected to a secure development diagnosis, AppSec, risk management, evidence preparation or ISMS improvement. Technical support should clarify scope, decisions, evidence and next steps; It does not convert the model into a certificate nor does it itself determine the legal applicability of the Cyber Resilience Act.
Do you want to turn the evaluation into a verifiable plan?
We can help you review scope, prioritize risks, and define maintainable evidence for your product, application, or digital process.
Request diagnosis