On this page
- Inspect the platform's product and release model.
- Distinguish evidence, investigation, approval and submission states.
- Check what becomes stale when facts or source material change.
- Evaluate exports and permissions as part of the core workflow.
A CRA platform is not a regulatory approval
The term CRA platform is a market description, not a status awarded by the regulation. Products sold under that label may focus on questionnaires, vulnerability analysis, document generation or evidence operations. Understand the actual coverage before treating two platforms as interchangeable.
Regulation (EU) 2024/2847 establishes product and economic-operator duties. It does not make a platform's score the measure of conformity. A system can help a manufacturer organise the work while still leaving security testing, legal judgment and external assessment to other people or services.
Look for a product model, not just a company checklist
A publisher may sell a desktop application, an endpoint agent and a hosted service under one brand. Those offerings can have different functions, dependencies and supply arrangements. The platform needs to distinguish them before an organisation-wide policy is used as evidence for each product.
Within a product, releases may remain supported in parallel. Ask how the platform identifies a version, its input material and the assessment performed on that material. A single editable current SBOM is a weak foundation for answering questions about an older release.
Understand the records behind the dashboard
A practical model keeps several connected records. Product facts explain the scope being assessed. Component records describe the inventory. Findings identify missing evidence or security issues. Decisions record accountable judgments. Artifacts collect the output for a specific assessment. The exact database design is less important than preserving those distinctions.
| Record | Question it answers | What it does not establish |
|---|---|---|
| Classification proposal | Which category appears relevant? | Final legal acceptance |
| SBOM | Which components are documented? | Complete shipped inventory by itself |
| Vulnerability match | Which advisory correlates with an identity? | Product exploitation or reportability |
| Approval decision | Who accepted which conclusion and why? | Approval of every future release |
| Reporting receipt | What submission was acknowledged? | Completion of all later reporting stages |
Ask what a changed input invalidates
A platform should explain what happens after a product fact, source snapshot or supplied document changes. Does an earlier decision remain visible? Is a new review required? Does the newest failed attempt obscure the last completed result? These behaviours matter more than how quickly the first dashboard fills up.
Ask the same questions about vulnerability intelligence. A successful lookup with no matches, an unsupported package and an unavailable feed are three different outcomes. They should not all become a green indicator. Historical findings should remain interpretable when current intelligence changes.
Keep permissions close to the decisions
Separate evidence contribution from accountable approval. A developer may upload a test result and resolve an engineering task without having authority to approve the product's classification. Reviewers also need access appropriate to their role: an external assessor may need a controlled package, not unrestricted repository access.
Inspect audit history, export permissions, account removal and retention after subscription changes. These questions concern the continuity and confidentiality of your own record. A platform's security badge or location claim does not answer them; request the relevant contracts and technical disclosures.
Choose the platform layer that is missing
If the team already maintains reliable product decisions and documentation, it may need only stronger SBOM management or vulnerability analysis. If the evidence exists but no one can reconstruct a release, it may need an evidence system. If the unresolved question is legal scope, specialist advice may be the first step.
Use the adoption guide to plan the transition and the acceptance checklist to test a shortlist. ConformOps publishes this guide; apply these questions to it as well as to every alternative.
Frequently asked questions
Is CRA platform a certification category?
No. It is a description used for software supporting CRA-related work. Evaluate the platform's actual functions and evidence boundaries rather than treating the label as regulatory approval.
Can a general GRC platform support CRA work?
It may support policies, ownership and evidence records. Check how it handles individual products, parallel releases, component inventories and product-specific decisions before relying on it for the whole workflow.
What is the most useful platform demonstration?
Ask the vendor to explain one release, change a relevant input and retrieve the old record. That reveals how evidence, decisions and history behave together.