On this page
- Assign one accountable product owner and one incident escalation path.
- Generate evidence from normal release automation.
- Prioritise scope, risk assessment, support period, vulnerability handling, and reporting readiness.
- Use external legal or conformity expertise for product-specific conclusions.
What operating model should a 5–30 person software company actually use?
For a 5-30 person software company, we recommend five responsibilities: engineering implements security and fixes; one accountable product/security owner makes decisions; security tooling supplies component and vulnerability data; a CRA evidence system connects requirements, evidence and history; and an external specialist helps with classification and difficult conformity questions. These are responsibilities, not five new hires.
This is ConformOps's recommended operating model, not an ENISA-prescribed organisation chart. One person can hold several roles, but name a deputy for urgent decisions and record who can approve what. Start with a product-specific scope review; team size alone does not determine whether the CRA applies.
Why practical implementation deserves the attention
ENISA's July 2026 summary of SME CRA readiness describes resource, expertise and implementation constraints for smaller organisations. Its February-March 2026 survey received 194 responses from 31 countries. Incident response and product life cycle management was the weakest area overall, particularly for microcompanies. Technical-documentation templates and secure-development templates were each requested by more than 70% of respondents. These are findings about the surveyed SMEs, not a measurement of every small software company.
Our practical response is to make the handoffs repeatable: give engineers a release-evidence template, give the decision owner a record for decisions and their rationale, and rehearse the reporting handoff with a deputy. ENISA also provides a free SME Cyber Resilience Maturity Assessment Model to identify improvement areas; its maturity scores are not evidence of legal compliance.
A lean ownership model
Name an accountable manufacturer representative, an engineering evidence owner, and an incident/reporting decision group - the people who own the Article 14 clocks from 11 September 2026. In a small company those may be the same people, but the decisions and backups should be explicit.
How the model works between releases and incidents
Use the following as a suggested working rhythm, adjusted to the product's risk and support needs. A scheduled review must never delay an urgent vulnerability or incident decision.
Reuse the delivery system
A good preparation programme turns existing repository, build, dependency, release, and issue-tracking information into controlled evidence. Add only the missing approvals and product-level explanations.
Know where to ask for help
Automation cannot decide final scope and classification, substantial modification, conformity route, harmonised-standard use, legal privilege, or reporting thresholds. Budget specialist review around those decisions instead of outsourcing the whole evidence system.
Frequently asked questions
Does a small software company need a dedicated CRA team?
Our recommended model separates responsibilities without requiring five new hires. Engineering supplies controls and fixes, a named product/security owner records decisions, security tooling supplies SBOM and vulnerability data, and an evidence system preserves the release history. Use external specialists for product-specific legal and conformity questions, and name a deputy for urgent reporting decisions.
Is there an SME exemption?
The CRA includes proportionality and targeted support, but commercial software from SMEs is not generally exempt. Product scope and specific provisions still require review.
Can one evidence system cover several products?
Shared policies and controls can be reused, but risk assessment, support period, release evidence, findings, SBOM, and market documentation should remain traceable to each product.