CRA self-assessment for software vendors: build a defensible internal review

First distinguish the two meanings of self-assessment

An internal readiness review asks what work remains and whether the evidence is usable. It can be performed while the product is incomplete and even where a notified body will later be required. Its output is a work plan and an assessment record, not permission to bypass that external procedure.

Formal internal control is a conformity-assessment procedure described in Article 32 and Annex VIII of the CRA. It carries manufacturer responsibility for the relevant product and processes. Completing a questionnaire or accepting AI-generated answers does not perform all of that work.

Check whether the route is available

For default-category products, internal control is an available option. Important Class I has conditional routes depending on applicable standards, common specifications or certification and their coverage. Important Class II and critical products have stricter requirements. Special provisions can also apply, including the Article 32(5) route for qualifying free and open-source important products with public technical documentation.

Use the Commission's conformity-assessment guidance as an explanation, then verify the operative legal conditions for your product. Do not assume all Class I products require a notified body, or that every open-source commercial product can self-assess. Record the category, route basis and any required specialist review.

The standardisation work also needs careful treatment. A draft standard or familiar security certification is not automatically an applicable CRA harmonised standard. Verify the exact reference, legal status, coverage and actual application before relying on it for a route or presumption of conformity.

Define the product and freeze the assessment inputs

Identify the manufacturer, intended purpose, users, delivery model, connected functions and assessed version. Record the source or build references, component inventory and relevant documents. Separate commercial facts from technical observations. The scope of a downloaded application may differ from the scope of a related hosted service or agent.

Keep a stable assessment input set. If a test or SBOM is replaced while the review is underway, retain which version each conclusion used. This is a recommended engineering control for traceability, not a claim that the CRA prescribes a particular repository layout or software database.

Work from product risks to security evidence

Describe the assets, trust boundaries, foreseeable misuse and security consequences relevant to the product. Explain the controls chosen to address those risks and the tests that assess their operation. A generic list of cybersecurity requirements is a starting reference, not a product-specific risk assessment.

For an updater, for example, inspect how the product authenticates updates, handles interrupted installation and prevents an unauthorised package from being installed. Retain the test scope and build identity. A policy saying updates are secure does not establish those behaviours, and an automated source match cannot prove runtime effectiveness.

Record a conclusion for each applicable requirement

For every requirement in scope, state the conclusion, relevant evidence, limitations, responsible reviewer and unresolved actions. If a requirement is not applicable, explain why in the product context. If evidence is missing, preserve that uncertainty instead of filling the gap with an unsupported narrative.

Include the work after release

Review component maintenance, vulnerability intake, triage, security updates, support commitments and reporting escalation. A clean inventory check at one moment does not establish that the manufacturer can handle the next advisory. Assign owners and inspect the operational record, including what happens when information is unavailable.

Article 14 reporting readiness should be assessed separately from the completeness of the technical file. Use a clearly marked drill, verify the authorised submitter and deputy, and inspect the awareness-based clocks. The deadline-tracking guide covers the working case and distinct final-report rules.

Review the technical record before any declaration

Assemble the product description, risk work, design and test evidence, applicable specifications and other required technical information. The technical-documentation guide explains the Annex VII structure. Keep missing material visible and distinguish drafts from approved documents.

Have a reviewer inspect the conclusion and its supporting chain, ideally someone who did not author every item. Complete the applicable conformity procedure and any required external work before the manufacturer makes the declaration. A software-generated declaration template is only a drafting aid; an internal readiness exercise does not establish that it is ready to sign.

Repeat the review proportionately after changes

Use the next release to review changed functions, components, controls, tests and support assumptions. Reuse still-relevant evidence with an explanation. Keep previous records and identify which decisions require renewed approval. Whether a modification has a particular legal consequence is a separate assessment of the actual facts.

ConformOps can hold the source-to-document evidence chain and proposed findings while preserving human gates. It does not choose the final legal route for you or replace independent security testing. For routine maintenance of the process, pair this guide with readiness checks.