On this page
- Choose one product and release before collecting files.
- A file can support a claim without proving the whole requirement.
- Give each missing answer an owner and a next action.
Begin with what you actually ship
Someone asks for CRA evidence and the obvious reaction is to collect everything: repositories, policies, test results and a folder of PDFs. That gets you a large folder. It does not necessarily get you an answer. A better starting point is a sentence describing the product, who uses it, where it runs and which release you are reviewing.
Suppose your team ships a desktop application with an update service. Record whether the service is needed for the application's functions and how the two are delivered. Keep an uncertain scope question visible. The guide to software and service boundaries can help you frame it before seeking advice.
Write down the release label and source revision next. A test result from last month's code might still be useful, but a reviewer needs to know why it applies to this release. The same is true of a dependency inventory and a risk assessment.
Gather a small, explainable starting set
Use the following list to locate existing material. It is a starting set for an evidence review, not an exhaustive CRA checklist. The manufacturer obligations summary describes the broader work around risk assessment, technical documentation and vulnerability handling.
| Material | Question it helps answer | What still needs checking |
|---|---|---|
| Product description and release identity | What are we reviewing? | Scope, intended use and delivery boundaries |
| Dependency manifests, lockfiles and supplied SBOM | Which components are recorded? | Whether the inventory describes what actually ships |
| Security policy and vulnerability intake instructions | How can someone report a problem? | Whether the process is operated and tested |
| Architecture notes, threat model and test records | How were security choices examined? | Coverage, results and unresolved risks |
| Update instructions and support commitment | How will users receive fixes? | Ownership, duration and the published information |
Turn one requirement into a question you can answer
Take vulnerability reporting as an example. Finding a security contact in SECURITY.md tells you that the repository describes a route for receiving reports. It does not tell you whether someone watches that inbox, how reports are triaged or who handles a serious incident. Those are separate questions with separate evidence.
Your next action might be as simple as asking the security owner for the intake procedure and the record of a recent exercise. Keep the file, the question and the action together. That gives the next person enough context to continue without repeating your investigation.
The CRA Software Evidence Map explains these limits of inference across the mapped requirements. Use it to understand what a record can support, rather than treating the existence of a document as an approval.
Use a worksheet before you upload anything
The evidence starter worksheet has columns for the release, the question, the material you found, its owner and what remains unknown. Open it in a spreadsheet and replace the prompts with your own references. It is an empty planning aid, not an assessment result.
Choose material you are authorised to process. Avoid uploading credentials or unrelated personal information. ConformOps filters and sanitizes accepted source content, but that is not a reason to send a complete drive or every document your organisation holds. The processing explanation sets out the separate optional AI boundary.
What a first ConformOps review gives you
The Free preview lets you work from focused files and inspect a limited result. It shows a sample of unresolved requirements alongside the full preview totals. It does not include the complete findings register or evidence exports. Start there to see whether the questions and source references are useful for your product.
When you need complete outputs for the accepted assessment scope, compare the paid options. A full result still needs manufacturer review. Missing evidence can mean that a process was not supplied, not that it does not exist. The practical goal of the first session is a clear next step, not a green score.
Frequently asked questions
Do I need an SBOM before starting a CRA evidence review?
You can begin reviewing available evidence before you have a usable supplied SBOM. A manifest derived inventory may help identify components, but it does not establish the completeness of the shipped product. Keep the inventory gap visible.
Can I upload policies instead of source code?
Policies can support process questions, while source and build records support different claims. Neither replaces the other. Choose evidence that addresses the actual requirement and check the service's accepted source scope.
Does uploading all the requested files mean I am CRA compliant?
No. File presence is not proof of effectiveness, completeness or conformity. The manufacturer must review the product facts, risk assessment, applicable requirements and conformity route.