On this page
- Write acceptance conditions before the sales demonstration.
- Record demonstrated, documented, promised and unverified separately.
- Treat failed evidence, reporting or permission checks as explicit blockers where your workflow depends on them.
- Keep the decision record and the tested product sample.
Use this checklist after defining the job
The existing software buyer's guide provides 15 detailed vendor questions. This article is the acceptance record to use alongside that conversation. It helps you decide what counts as satisfactory evidence and what should block purchase for your particular workflow.
Choose a product sample you are authorised to share, with two releases, a real SBOM, a missing document and a known security finding. Ask vendors to work with the same materials. Mark any unavailable feature as unverified or outside scope; do not assume that a missing demonstration proves the capability does not exist.
Record an outcome for each essential workflow
Use demonstrated when you observed the behaviour, documented when a current document supports it, promised for a future commitment, and unverified when evidence is missing. These are procurement labels. None means the software product has achieved legal conformity.
| Area | Acceptance evidence to request | Reason to leave the decision open |
|---|---|---|
| Product classification | Product facts, cited basis and accountable approval | A category is accepted without rationale |
| SBOM management | Parsed inventory, origin, release and quality limits | Upload success is presented as completeness |
| Vulnerability monitoring | Coverage, feed health and investigation history | An outage is displayed as no findings |
| Technical documentation | A readable export with references and draft state | A generated file is labelled legal approval |
| Release traceability | Earlier inputs and decisions survive a new run | The current view overwrites historical meaning |
| Article 14 readiness | Awareness-based clocks and submission handoff | Case creation resets the legal start time |
| Permissions and exit | Role demonstration and usable retained exports | Access and retention are only verbal assurances |
Inspect classification and inventory separately
Ask the vendor to change a product fact that could affect scope or category. Inspect the explanation and approval path. A library list should not automatically determine the classification of the containing product. Use the Commission's conformity-assessment guidance to frame the question, then verify the relevant legal route.
For the SBOM, inspect the parsed fields and unresolved identities. Introduce a discrepancy between the supplied document and repository evidence. Ask how the difference is retained and which inventory is used for matching. Confirm your actual formats and ecosystems, not just the presence of an SBOM button.
Test a failure before trusting a success
A feed outage, failed rerun or incomplete import reveals how honestly the platform presents uncertainty. Start with a completed baseline and a known finding. Then request a controlled failure demonstration. Check whether the older evidence remains accessible and whether the new failed state is visible in both the dashboard and export.
Select an ordinary contributor account and attempt an approval. Verify that the platform enforces the promised responsibility model. Do not perform disruptive tests against a vendor's live service without authorisation; a vendor-controlled demonstration or isolated trial is sufficient for this exercise.
Inspect the reporting clock and delivery boundary
Use a fictional drill where awareness precedes data entry. Verify the initial deadlines against that earlier timestamp. Then inspect the distinct final-report rules for an actively exploited vulnerability and a severe incident. A single generic incident timer is not enough evidence of correct Article 14 handling.
Ask whether the tool submits externally or only prepares and records. If it submits, request evidence of the supported channel, authorisation and receipts. If it does not, record the human handoff as a required operating step. Use the tracking guide for a worked example.
Compare cost and exit on the same assumptions
Request terms for your product count, supported releases, users, integrations and retention needs. Include implementation work and any external review still required. A lower subscription can still leave more work with your team; a larger bundle may include capabilities you will not use.
Export the sample before signing. Ask a colleague to reconstruct the assessment using that export alone and identify what remains dependent on the vendor. Check cancellation, historical access and deletion provisions. Keep the accepted terms and unresolved exceptions with the procurement decision.
Make the purchase decision explicit
Record the selected tool, the job it will own, the workflows retained elsewhere, the evidence reviewed and the person accepting remaining limitations. Do not average a failed critical check into a passing numerical score. If reporting tracking is the reason for the purchase, an unresolved clock error is a blocker even if the document editor is excellent.
ConformOps publishes this checklist and should be evaluated against it. The named-tools comparison helps build a shortlist; this acceptance record helps decide whether any candidate actually fits your team.
Frequently asked questions
Should we score CRA vendors numerically?
A score can hide a failed essential workflow. Record evidence and unresolved conditions for each area, and define which failures block purchase for your specific use case.
Is a roadmap promise acceptable evidence?
It is evidence of a promise, not of an available feature. Record availability, contractual commitments and a fallback before depending on it.
What should be kept after the vendor demo?
Retain the sample scope, observed outcomes, exports, supporting documents, commercial assumptions and unresolved questions, with the accountable purchasing decision.