Audit-ready evidence for CRA: what to prepare and how to structure it

The short answer

CRA requires manufacturers to produce and maintain a defined set of technical evidence before placing a product with digital elements on the EU market. The core evidence set — technical documentation, SBOM, CVD policy, risk assessment, vulnerability log, and ENISA notification workflow — must be available to market surveillance authorities on request and retained for 10 years after the last product was placed on the market.

The core evidence set

| Artefact | CRA reference | Format / retention |

|---|---|---|

| Cybersecurity risk assessment | Art. 13(2), Annex I Part I §1 | Document; updated on significant change |

| Technical documentation | Art. 31, Annex VII | Document set; 10-year retention |

| Software Bill of Materials (SBOM) | Annex I Part II §1 | Machine-readable (SPDX/CycloneDX); updated each release |

| CVD policy | Annex I Part II §1 | Published document; operational by 11 Sep 2026 |

| Vulnerability log | Annex I Part II §2 | Tracked list; updated continuously |

| ENISA notification records | Art. 14 | Timestamped records; 10-year retention |

| EU declaration of conformity | Art. 28, Annex V | Signed document; 10-year retention |

| Conformity assessment record | Art. 32–36 | Certificate or self-assessment record |

| Post-market monitoring plan | Annex I Part II §2 | Document; reviewed annually |

1. Cybersecurity risk assessment

What it must cover (Annex I Part I §1):

Format: No mandated format. ENISA threat landscape methodology, ISO 27005, or NIST SP 800-30 are accepted approaches. The assessment must be product-specific — a generic framework application without product-specific mapping will not satisfy CRA.

Update trigger: Material change to the product (new feature, new connectivity, new deployment environment) or discovery of a significant new vulnerability.

• Identification of the product's intended use and operating environment
• Identification of threat actors, attack vectors, and vulnerabilities
• Assessment of the likelihood and impact of identified risks
• Selection and justification of security controls implemented
• Residual risk assessment

2. Technical documentation (Annex VII)

Technical documentation must be drawn up before placing the product on the market and must include:

Retention: 10 years after the last product unit was placed on the market.

• General description — product name, version, intended purpose, target markets
• Design and development documentation — architecture, component descriptions, design decisions
• List of harmonised standards applied — or description of solutions adopted where standards are not applied
• Description of cybersecurity solutions — how Annex I Part I requirements are addressed
• Test reports — security testing methodology, tools, results, remediation actions
• SBOM — or reference to a separately maintained SBOM
• Copy of EU declaration of conformity

3. Software Bill of Materials (SBOM)

See SBOM requirements under CRA for full guidance.

Audit expectations:

• Machine-readable format (SPDX 2.3+ or CycloneDX 1.5+)
• Full transitive dependencies (top-level minimum, transitive strongly recommended)
• PURL identifiers for each component
• VEX assertions for known vulnerabilities
• Version-controlled with release tags
• Dated — MSAs will check currency relative to the shipped version

4. CVD policy

What auditors check:

Operational by: 11 September 2026 (CRA Art. 14 early applicability).

• A published, publicly accessible CVD policy exists (web page or linked document)
• Policy contains: contact channel, acknowledgement timeline, triage timeline, disclosure timeline, safe harbour statement
• Policy is operational — the contact channel is monitored and responsive
• Internal process is documented (who receives reports, how they're triaged, who decides on disclosure)

5. Vulnerability log

Annex I Part II §2 requires manufacturers to "document and address vulnerabilities" on an ongoing basis. In practice, a vulnerability log must record:

| Field | Description |

|---|---|

| ID | CVE or internal identifier |

| Component affected | SBOM component reference |

| Discovery date | When the vulnerability was identified |

| Severity | CVSS v3.1 or v4.0 score and vector |

| Status | Open / In remediation / Resolved / Accepted risk |

| Resolution date | When patched or mitigated |

| ENISA notification | Whether Art. 14 notification was triggered and when |

| Patch / mitigation | Version in which the fix was released |

The log must be available to MSAs on request. It does not need to be public.

6. ENISA notification records

For every Art. 14 notification submitted, retain:

Retention: 10 years. These records are a primary audit artefact — MSAs will cross-reference notification records against the vulnerability log and SBOM.

• Timestamp of when the organisation became aware (start of 24h clock)
• Content of the 24h early warning submitted
• Content of the 72h intermediate report
• Content of the 14-day final report
• Recipient (national MSA name and contact)
• Acknowledgement received from MSA

7. EU declaration of conformity (Annex V)

The EU declaration of conformity (DoC) must be drawn up before CE marking is affixed and must contain:

• Name and address of the manufacturer
• Product description (name, model, batch or serial number)
• Statement that the DoC is issued under sole responsibility of the manufacturer
• Object of the declaration (product name, CRA article reference)
• Reference to harmonised standards applied or to the CRA essential requirements addressed
• Notified body name and certificate number (if third-party assessment was conducted)
• Place and date of issue, signature

Conformity assessment routes

| Product class | Route |

|---|---|

| Default (most products) | Self-assessment by manufacturer |

| Important Class I | Self-assessment using harmonised standard; or third-party if no harmonised standard |

| Important Class II | Third-party conformity assessment by EU-notified body |

| Critical (Annex IV) | European cybersecurity certification scheme or third-party |

The product's class determines whether the technical documentation is subject to manufacturer self-assessment or notified body review. In both cases, the documentation set is the same.

Common gaps at audit

1. Risk assessment is a generic template, not product-specific.

MSAs expect to see the specific threat model for your product's actual attack surface and deployment context.

2. SBOM is out of date relative to the shipped version.

An SBOM generated 6 months before the audit for an earlier version does not satisfy the requirement.

3. CVD policy exists but contact channel is unmonitored.

A CVD policy that lists a security@ address with no response is non-compliant. The policy must be operationally active.

4. Vulnerability log exists but ENISA notification records are missing.

If an actively exploited vulnerability appears in the log, MSAs will check whether Art. 14 notification was submitted. Missing records imply the notification was not made.

5. Technical documentation version does not match shipped product.

Documentation must correspond to the specific product version placed on the market. Version drift is a common finding.

How NexCyber helps

NexCyber's 144-obligation gap assessment maps your current evidence state against all CRA Annex I and Annex VII requirements. When your evidence is complete and reviewed, NexCyber issues a Machine-Readable Compliance Certificate (MRCC) — a cryptographically signed attestation of your readiness posture.

→ Start your CRA gap assessment

→ MRCC — Machine-Readable Compliance Certificate

→ CRA Scope Checker — confirm applicability

Further reading

This page provides regulatory guidance for informational purposes. It is not legal advice. CRA implementing acts, harmonised standards, and ENISA guidance are still being developed. For compliance decisions, consult the applicable market surveillance authority or a qualified legal adviser.

NexCyber — EU Market Access Compliance Platform

• SBOM requirements under CRA Annex I
• CRA Article 14 — vulnerability reporting workflow
• CRA penalties — maximum fines by violation type