Self-assessment under Module A: what your technical documentation must contain
Most products are in the default class, where you declare conformity yourself — Module A (internal production control). The basis is the technical documentation, whose minimum content is set by Annex VII: eight points from a general product description through vulnerability handling (SBOM, CVD, contact, update distribution), a risk assessment and the support period, to a copy of the declaration of conformity. We go through them in order.
If you're in the default class (which is most vendors — more in the classes article), you declare CRA conformity yourself. It's called Module A (internal production control): no notified body, but full responsibility that your technical documentation holds together. Its minimum content isn't left to your imagination — it's set by Annex VII of Regulation (EU) 2024/2847. Let's walk through its eight points in a small company's language.
What Module A is
Module A means you assess the product against the essential requirements in Annex I, write documentation about it, issue an EU declaration of conformity and affix the CE marking — without involving a third party. It's the mildest regime, but not "no work": the documentation must exist and be available to a surveillance authority on request.
The eight points of Annex VII
Annex VII says the technical documentation contains at least these eight elements:
- A general description of the product — its intended purpose, the software versions affecting compliance, for hardware photos/drawings of the exterior and internal layout, and the user information and instructions per Annex II.
- A description of the design, development, production and vulnerability-handling processes — the architecture and how components fit together; and in particular the specification of the vulnerability-handling process: the SBOM, the CVD policy, evidence of a contact address for reporting vulnerabilities, and a description of the secure update-distribution solution.
- A cybersecurity risk assessment — the risks against which the product is designed, developed, delivered and maintained (the Article 13 risk assessment; it has its own practical article).
- Support-period inputs — the information on which you determined it (more in the support period article).
- A list of harmonised standards applied — those whose references have been published in the Official Journal (none yet — why, and what to do).
- Test reports verifying the conformity of the product and of the vulnerability-handling processes with the essential requirements.
- A copy of the EU declaration of conformity (its content is set by Annex V — more in the DoC and CE article).
- The SBOM — upon a reasoned request from a market surveillance authority.
Find out whether the CRA applies to you
Six questions, two minutes, no account. Get your product class and first steps.
How to approach it in practice
The list looks long, but much of it is things you need or have anyway. The SBOM, CVD policy and contact channel (point 2) are exactly what we recommend doing right away — and what the separate articles cover. The risk assessment (point 3) fits on two pages. The declaration of conformity (point 7) is a short form. Don't try to write everything at once and perfect; make a skeleton with eight headings and fill it in.
One thing matters: the documentation is kept for at least 10 years from placing the product on the market (or for the support period, if longer) — Art. 13(13). It's not a one-off document for a drawer — version it alongside the product.
Where small companies most often fall short
A few typical gaps that are easy to avoid:
- The documentation exists only "in someone's head". The process may genuinely work, but it isn't written down — when an authority asks, you have nothing to show. Module A stands or falls on the documentation being tangible and available.
- Point 2 is missing — the vulnerability-handling process. Companies often describe the product but forget the SBOM, CVD policy and reporting channel. Yet that's the core of Annex VII and also what applies to you earliest.
- The support-period decision isn't visible. Point 4 asks for the inputs on which you determined it — not just a number.
- The documentation isn't versioned. The product changes, the documentation doesn't → a year later it no longer matches. Version it alongside releases.
A practical tip: create a document with eight headings from Annex VII right at the start and fill it in as you go. An empty heading flags what's still missing, better than trying to recall everything at once just before a request.
When self-assessment isn't enough
Module A applies to the default class. For important class I, self-assessment is possible only with full application of harmonised standards (which aren't out yet) — or if the product holds a certificate under a European cybersecurity certification scheme at assurance level at least "substantial" (Art. 32(2)); otherwise a notified body steps in. Class II and critical always require a third party. If you're unsure of your class, the scope-checker determines it.
FAQ
- Must the documentation be in a specific language? The regulation requires it to be understandable to an authority; the language may be set by the Member State. To be safe, keep it in a language your surveillance authority accepts.
- How long to retain it? At least 10 years from placing on the market (or for the support period, if longer) — Art. 13(13).
- We're a micro-enterprise — is it simpler? Yes, the regulation provides for simplified documentation for micro and small enterprises, but Annex VII's eight areas must be covered.
- When is the declaration of conformity drawn up? Before placing on the market; it's point 7 of the documentation and also a standalone document (Annex V).
Where to start with a blank page
The best first step isn't to write from scratch but to gather what you already have: the SBOM, security.txt and CVD policy (point 2), the risk assessment (point 3), the support-period decision (point 4). A surprisingly large part of the documentation is things you do anyway — they just need writing down in one place with eight headings. Only then do you fill in what's missing (an architecture description, test reports). That turns a "big compliance task" into tidying up the existing.
Key point
For the default class you declare conformity yourself (Module A), and the basis is technical documentation whose minimum content is set by Annex VII — eight points, from a general product description, through the vulnerability-handling process (SBOM, CVD policy, contact channel, secure update distribution), the risk assessment and support-period basis, to the list of standards, test reports and a copy of the declaration of conformity. Much of that is things you do anyway — you just write them in one place under eight headings and keep adding. The documentation is kept for at least 10 years (Art. 13(13)) and versioned with the product. Module A applies to the default class; for important I, self-assessment is possible only with full application of standards (or a certificate under a scheme at level at least "substantial", Art. 32(2)), while class II and critical always require a third party.
How CRAguard helps
CRAguard holds most of point 2 for you: it generates and versions the SBOM, hosts the CVD channel and contact address, and keeps an audit trail that is evidence of a working process. It guides the rest of the documentation with templates, so none of Annex VII's eight points stays a blank page. Find out whether the CRA applies to you, or join the waitlist.
This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Annex VII, Art. 13, Art. 31, Module A) and the European Commission's guidance of 27 July 2026.
Find out whether the CRA applies to you
Six questions, two minutes, no account. Get your product class and first steps.