On this page
- Map your existing records before choosing a platform.
- Keep product scope, inventory, security findings and legal decisions separate but connected.
- Pilot one product and one update before migrating the portfolio.
- Measure reliable retrieval and follow-through rather than a compliance score.
What belongs in CRA compliance management?
For a software team, the core job is to connect a product's identity and intended use to the security work, component information, decisions and documentation that support it. The Commission's manufacturer overview describes work before, at and after market placement. A purchasing project should account for that lifecycle instead of stopping at the first report.
This guide concerns adoption and migration. If you need a named vendor shortlist, use the 2026 tools comparison. If you need detailed questions for a sales demonstration, use the software buyer's guide. Start here when the question is how to make the new system part of everyday delivery.
Inventory the records before moving them
Take one product and list where its scope decision, release list, SBOMs, test outputs, support commitment, vulnerability investigations and technical documentation live. Identify the owner of each source. A spreadsheet cell saying complete is a status claim; it is not a substitute for the evidence that justified the status.
For every record, distinguish what it describes from when it was written. A policy updated yesterday may describe next quarter's process. A test executed last month may still be relevant to an unchanged component. Capture the relationship deliberately rather than using upload date as a proxy for validity.
| Existing record | Preserve during migration | Resolve before use |
|---|---|---|
| Product spreadsheet | Product identity, owner and rationale | Unsupported scope or category conclusions |
| SBOM folder | Document origin and release association | Unknown build coverage or duplicate versions |
| Security tickets | Investigation, evidence and decision history | Closed tickets without a product conclusion |
| Technical-file documents | Author, version, references and approval state | Drafts incorrectly labelled final |
Define the workflow before the integration
Agree who can propose product facts, investigate vulnerabilities, approve conclusions and publish a release. These may be different responsibilities held by the same person in a small team. The distinction still matters: submitting evidence should not silently count as approving its sufficiency.
Choose the system of record for each item. Keep source in source control and test execution in the build pipeline where those tools work well. The CRA platform should retain stable references or controlled copies and expose their scope. Avoid an integration that creates two editable versions of the same decision with no reconciliation rule.
Pilot classification, SBOM maintenance and monitoring
Begin with product classification and applicability assessment using the actual delivery model and core functions. Have the reviewer record unresolved facts. Do not accept a classification inferred from a repository language or a single dependency. Then supply the inventory for the same release and inspect what the tool can parse and correlate.
Test a later inventory update and a vulnerability investigation. Can the team distinguish a new advisory from a changed component? Does a failed lookup remain visible? Can an earlier not-affected decision be read with its original justification? Vulnerability monitoring is only useful when someone owns those follow-up questions.
Treat reporting readiness as an operational handoff
Article 14 reporting obligations apply from 11 September 2026; the wider CRA requirements apply from 11 December 2027. Keep reporting preparation visible in the adoption plan rather than waiting for the whole technical file. The Commission's reporting guidance explains the separate notification process.
Assign the person who submits, a deputy and the person who decides the reporting outcome. Verify access to the current official reporting channel. An internal deadline tracker does not establish that a notification was delivered. Run a drill with an awareness time earlier than case creation to check that the system does not reset the clock.
Migrate without inventing approval history
Import older records as historical material with their real provenance. If the spreadsheet does not identify who approved a conclusion, record approval as unknown and arrange review. Do not assign the migration operator as the original decision-maker or convert every completed task into legal satisfaction.
Keep the previous collection accessible until a second person can retrieve the pilot product's evidence from the new system. Confirm that exports include enough context to be useful after cancellation. Review retention, source access, AI processing and deletion terms before uploading more material.
Decide whether the pilot earned a wider rollout
Ask a colleague who did not configure the pilot to explain one requirement, one vulnerability decision and one changed release. Record where they need help. Measure unresolved owners, broken evidence links and time spent reconstructing the record. These are operating measures, not percentages of legal compliance.
Roll out to another product only after correcting the pilot's recurring problems. ConformOps is one option for the source-to-document evidence chain; its overview explains the implemented boundary. The right adoption decision is the one your team can sustain after the initial assessment.
Frequently asked questions
When should a team replace its CRA spreadsheet?
When maintaining release associations, decision history, evidence links and owners becomes unreliable or expensive. First identify the failure in the existing process, then pilot software against that problem.
Can old completed spreadsheet rows be imported as approvals?
Only retain the approval history the evidence actually supports. Missing approvers, dates or rationale should remain unknown and be reviewed, rather than invented during migration.
Should we replace our security scanners at the same time?
Not necessarily. Keep effective testing and build tools, and establish how their outputs connect to the product's evidence and decision record.