CRA evidence management: what to keep, for how long, and how to keep it provable
CRA evidence management means keeping, for at least ten years after a product is placed on the market, the records that show how each obligation was met: technical documentation, the EU declaration of conformity, SBOMs, vulnerability-handling decisions, test reports, advisories, reporting submissions and update history — each attributable to a person and a time, unchanged since it was created, linked to the product and requirement it evidences, and retrievable on request.
By the Vellaci teamPublished Updated 5 min readOperational guidance, not legal advice
Key facts
- Retention
- Technical documentation and the declaration of conformity: at least ten years after placing on the market or the support period, whichever is longer (Art. 13(13); Art. 31)
- Who asks
- Market surveillance authorities (Art. 52), notified bodies (Art. 32), customers in procurement, auditors
- What makes it count
- Provenance (who, when), integrity (unchanged), linkage (which product, which requirement), retrievability (on request)
- Where it fails
- Shared drives, chat threads and ticket comments — findable today, unprovable in 2031
The problem this solves
Most of the work the CRA requires already happens in some form: dependencies are updated, tests are run, incidents are handled. What is missing is proof — in the form an authority or a customer's security review will accept, years later, from people who may no longer be at the company. A statement of compliance without records is an assertion; a record without provenance, integrity and linkage is a file.
What must be evidenced
| Obligation | Records | Typical source |
|---|---|---|
| Technical documentation (Art. 31, Annex VII) | Product description, risk assessment, design and vulnerability-handling information, test reports, standards applied, declaration of conformity | Documentation workspace per product |
| Vulnerability handling (Annex I Part II) | SBOM per version, triage decisions with reasons, remediation records, VEX statements, advisories, update logs | Pipeline, vulnerability workflow, release process |
| Reporting (Art. 14) | Awareness confirmation and rule, reportability review with rationale, submitted content, ENISA platform receipts, user communications, final report | Reporting case records |
| Support period (Art. 13(8)) | Determination with rationale per product, public statement | Product registry |
| Secure development (Annex I Part I) | Threat models, security requirements, test plans and results, release gates | Engineering process |
| Disclosure (Annex I Part II(5)–(6)) | Policy versions, security.txt history, intake log with response times | PSIRT / security mailbox |
| Conformity (Art. 32) | Procedure decision, notified-body correspondence, certificates, declaration, CE marking | Compliance function |
Four properties of a record that counts
- Provenance: who created or decided it and when, captured by the system rather than typed into a document.
- Integrity: a checksum at creation and an append-only history, so a record can be shown to be unchanged — or every change shown.
- Linkage: the product, the version, the requirement and, where relevant, the finding or case the record evidences.
- Retrievability: findable by product and requirement, exportable with an index and integrity manifest, within days of a request — not weeks of archaeology.
Retention in practice
Ten years is longer than most tools, contracts and employees last. Plan for it explicitly: a retention category per record kind (regulatory minimum, contractual, internal), a policy that enforces the minimum rather than a default deletion, legal hold for anything tied to an open case or dispute, and a complete export that does not depend on the vendor still existing. A read-only, exportable workspace after a subscription ends is part of that plan — evidence that disappears with an invoice is not evidence.
An operating routine
- Decide the evidence set per requirement once (the table above is a starting point) and assign an owner to each.
- File evidence as a by-product of the workflow — the SBOM when it is ingested, the decision when it is made, the receipt when the notification is submitted — not in a quarterly clean-up.
- Classify each record (public, internal, confidential, restricted) and set a review date for documents that go stale (policies, risk assessments).
- Run a retrieval drill twice a year: pick a product and a requirement, and time how long it takes to produce the evidence pack.
- Export the complete set at least yearly and store the manifest outside the platform.
What Vellaci does — and what it leaves to you
Vellaci's evidence vault stores private, checksummed files and links tied to products, versions, requirements, findings, incidents and reporting cases, with classification, review dates, retention categories with regulatory minimums, legal hold and an append-only, hash-chained audit log. Reporting submissions are frozen, signed snapshots; awareness times keep every revision. A complete organisation export — JSON per table, audit CSV, evidence index, integrity manifest — is available at any time, and a lapsed subscription keeps the workspace readable and exportable. What counts as sufficient evidence for a given obligation, and whether a record is legally adequate, remain judgements for your organisation and its advisers.
Where to start
The free assessment on this site asks how decisions, SBOMs, tests and updates are retained today and returns, for every gap, the evidence a manufacturer would need to produce. Teams usually begin with the two record sets that are already being generated but not kept — SBOMs per release and triage decisions — and add the reporting runbook and documentation structure next.
Frequently asked questions
- Is a spreadsheet or a shared drive acceptable evidence?
- It can be, if you can show who changed what and when, that the content is unchanged since, and that it links to the product and requirement. In practice that is hard to demonstrate for a shared drive years later; systems that capture provenance and integrity automatically make the same records defensible.
- Do we need to keep evidence for products we no longer sell?
- Yes, for at least ten years after each product was placed on the market (or for the support period if longer). Retention is per product, and the obligation outlives the sales period.
- What does an authority actually ask for?
- Market surveillance authorities can request the technical documentation, the declaration of conformity and information demonstrating conformity — in practice the risk assessment, vulnerability-handling records, test reports and, for reportable events, the reporting history. Being able to produce a coherent pack quickly is itself part of the impression you make.
- How does this relate to ISO 27001 or SOC 2 evidence?
- Those frameworks evidence the organisation's information security management; the CRA evidences the product's cybersecurity and the manufacturer's handling processes. Records overlap (policies, testing), but CRA evidence must be linked to specific products and versions, which management-system evidence usually is not.