- Typical repository evidence / where it lives
- README.md; docs/product-scope.md; architecture diagrams; licence and distribution notes.
- Other evidence / where to look
- Commercial supply terms, EU distribution records and a manufacturer-approved product boundary.
- Observable evidence / what it establishes
- The snapshot describes intended functions, interfaces and stated distribution assumptions.
- Strong supporting evidence
- A dated scope decision tied to the release, actual supply model and remote processing dependencies, with evidence for any exclusion.
- Partial evidence
- An architecture diagram or README describing only one repository in a larger product.
- Insufficient by itself
- An open-source licence or a README saying the CRA does not apply.
- What cannot be inferred
- Whether the product is made available on the EU market, whether an exclusion applies, or which legal role an organisation actually holds.
- Human assertion/decision needed? Yes
- Confirm the product boundary, market facts, role and any exclusion rationale.
- Annex VII connection
- 1(a) intended purpose; 2(a) architecture. These support scope analysis, not a legal scope determination.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA resources / Research
CRA Software Evidence Map
What evidence can a software repository actually provide for the Cyber Resilience Act?
A repository can support a claim. It cannot make the manufacturer’s decision.
Trace each mapped requirement from the legal text to the records a software team might hold, the Annex VII technical file, and the conclusions those records cannot support on their own.
From a requirement to a defensible record.
These are the 16 grouped requirements ConformOps currently maps, not every individual CRA provision. The first 15 map binding law; the final row is a non-binding editorial convention. Every evidence example and Annex VII connection is ConformOps’ interpretation, not an official acceptance criterion.
The table is a reading index. Follow any requirement to its full record below, with all dataset fields visible without expanding a control. On smaller screens the table scrolls horizontally.
| Requirement / CRA reference | Typical repository evidence | Automatically observable? | What cannot be inferred |
|---|---|---|---|
| Establish product scope and economic-operator roleArticles 2 and 3 | README.md; docs/product-scope.md; architecture diagrams; licence and distribution notes. | Partial | Whether the product is made available on the EU market, whether an exclusion applies, or which legal role an organisation actually holds. |
| Determine category and conformity-assessment routeArticles 7, 8, 27 and 32; Annexes III, IV and VIII | docs/classification.md; functional specifications; architecture decisions; standards mapping. | Partial | The final category, full application of a harmonised standard, entitlement to a conformity presumption or completion of the selected route. |
| Compare core functions with binding technical category descriptionsCRA Articles 7(4) and 8(2); Implementing Regulation (EU) 2025/2392 Article 2, Annexes I and II | docs/category-rationale.md; feature specifications; system-boundary diagrams. | Partial | That a product belongs to a category merely because its source contains similar terminology or imports a related component. |
| Document and maintain a product cybersecurity risk assessmentArticle 13(2)-(4); Annex VII(3) | docs/threat-model.md; risk-register.csv; security architecture decisions; release risk reviews. | Partial | That all material risks were identified, a likelihood estimate is justified, or residual risk is acceptable to the manufacturer. |
| Build risk-based security into the product and release defaultsArticle 13(1)-(4); Annex I Part I(1), (2)(a)-(b); Part II(3) | Secure coding guidance; default configuration; tests/security/; .github/workflows/ security and release checks. | Partial | That all known exploitable vulnerabilities are absent, tests cover every risk, or repository defaults match the distributed product. |
| Protect access, confidentiality and integrityAnnex I Part I(2)(d)-(f); Article 13(2)-(4) | Authentication and authorisation code; TLS and encryption settings; integrity checks; negative access tests. | Partial | That controls cannot be bypassed, secrets are managed safely in operation, or deployed data is protected end to end. |
| Minimise data and attack surface, and limit disruption and incident impactAnnex I Part I(2)(g)-(l); Article 13(2)-(4) | Data-flow inventories; retention settings; rate limits; service and privilege configuration; resilience tests; logging policies. | Partial | That deployed interfaces match source, collected data is necessary, recovery works, or connected systems remain available during an attack. |
| Operate vulnerability handling and coordinated disclosureArticle 13(6)-(8), (17); Annex I Part II(2)-(6) | SECURITY.md; security.txt source; disclosure policy; triage runbook; advisory templates and remediation history. | Partial | That the contact is monitored, the policy is enforced, reports are handled without delay or affected users received advisories. |
| Identify release components and document an SBOMAnnex I Part II(1); Article 13(5) | packages.lock.json; package-lock.json; pom.xml; other manifests and lockfiles; supplied CycloneDX or SPDX JSON. | Partial | That all shipped components are present, a supplied SBOM is accurate, or the product has no vulnerabilities. Presence, structural usability and completeness are different claims. |
| Justify the support period and securely deliver security updatesArticle 13(8), (9), (19); Annex I Part I(2)(c), Part II(2), (7)-(8) | SUPPORT.md; end-of-support policy; release workflow; signing and update verification code; update-user guidance. | Partial | That the chosen duration is justified, users can obtain and install updates, signing keys are controlled, or updates remain available for the required period. |
| Prepare and make required actively exploited vulnerability reportsArticle 14(1)-(2), (8); Article 16 | Article 14 runbook; reporting templates; escalation and backup-owner records; drill notes. | No | That this product is actively exploited, when awareness arose, whether reporting is required, or whether the authority received a timely report. |
| Prepare and make required severe-incident reportsArticle 14(3)-(5), (8); Article 16 | Incident reporting runbook; severity criteria; report templates; escalation roster; drill results. | No | That an incident meets the legal severity threshold, deadlines were met, or a final report was received by the reporting platform. |
| Prepare, maintain and retain technical documentationArticles 13(12)-(13) and 31; Annex VII | docs/technical-file/; architecture and design records; standards register; test reports; release-document index. | Partial | That the technical file is complete, current, authentic, retained for the required period or sufficient for a conformity assessment. |
| Provide product and security information to usersArticle 13(18)-(20); Annex II | User manual source; secure installation and configuration guides; update and decommissioning instructions; support and contact pages. | Partial | That the instructions reach users, are understandable in the required language, or accurately describe the distributed product and its support arrangements. |
| Complete conformity assessment, declaration and CE markingArticle 13(12); Articles 28-30 and 32; Annex V | Declaration draft; conformity-procedure index; CE artwork; references to certificates and sign-off records. | No | That the manufacturer has completed conformity assessment, an authorised person signed, the certificate covers this release or CE marking was correctly affixed. |
| Distinguish binding law from explanatory guidanceEditorial convention, not a separate CRA obligation. Legal context: Article 31 and Annex VII.Non-binding convention | Source register; citations with authority labels and review dates; methodology documentation. | Yes | That guidance changes the Regulation, creates an additional obligation or validates a legal conclusion. This row is an editorial safeguard, not a compliance requirement. |
Five terms. Five different claims.
- Observable evidence
- A bounded fact directly inspectable in a particular source revision or retained artifact, such as a declared dependency or a configured test. Presence is not proof of effectiveness.
- Supporting evidence
- A record that helps substantiate a claim when its provenance, release relevance and scope are checked, such as a test report linked to a shipped build.
- Partial evidence
- Relevant information that leaves material parts of the claim unverified, such as a manifest without a build inventory.
- Human assertion/decision
- An attributed statement or accountable choice, such as product scope, risk acceptance or the support-period rationale. Storing it in Git does not turn it into an independently verified fact.
- Not observable from a repository
- A fact requiring evidence outside the source snapshot, such as whether a report was submitted, an inbox is monitored or a conformity procedure was completed.
These labels describe the role of evidence, not a ranking or percentage. An observable fact can still be only partial support for a wider legal requirement. Strong evidence below means stronger support after provenance and scope checks, never automatic satisfaction.
What to look for. What it leaves open.
Example paths describe where teams commonly keep records. They are not required filenames or a promise that a scanner can read every format. Each record has a stable link for citation.
CRA-CLASS-001 · Permalink
Determine category and conformity-assessment route
Articles 7, 8, 27 and 32; Annexes III, IV and VIII
- Typical repository evidence / where it lives
- docs/classification.md; functional specifications; architecture decisions; standards mapping.
- Other evidence / where to look
- Applicable Official Journal standards references, certification scope and external conformity-assessment records where required.
- Observable evidence / what it establishes
- Documented product functions and a proposed category or standards mapping.
- Strong supporting evidence
- An approved comparison of actual core functions to legal categories, with a justified route and verified scope of applied standards or certification.
- Partial evidence
- A functional specification naming security features without the complete product context.
- Insufficient by itself
- A dependency on a cryptography library, a security badge or an unsupported claim of Class I status.
- What cannot be inferred
- The final category, full application of a harmonised standard, entitlement to a conformity presumption or completion of the selected route.
- Human assertion/decision needed? Yes
- Approve classification and the applicable route; obtain the external assessment or certification when required.
- Annex VII connection
- 1(a), 2(a) product functions and architecture; 5 standards and solutions; 7 declaration.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-CLASS-002 · Permalink
Compare core functions with binding technical category descriptions
CRA Articles 7(4) and 8(2); Implementing Regulation (EU) 2025/2392 Article 2, Annexes I and II
- Typical repository evidence / where it lives
- docs/category-rationale.md; feature specifications; system-boundary diagrams.
- Other evidence / where to look
- Product demonstrations, hardware specifications and the accountable classification review.
- Observable evidence / what it establishes
- Descriptions of implemented functions that can be compared with the implementing act.
- Strong supporting evidence
- A function-by-function comparison to the relevant technical description, supported by product evidence and an approved rationale.
- Partial evidence
- An architecture document naming a firewall or identity feature without establishing the product's core functionality.
- Insufficient by itself
- A keyword match to a category name or a vendor's marketing label.
- What cannot be inferred
- That a product belongs to a category merely because its source contains similar terminology or imports a related component.
- Human assertion/decision needed? Yes
- Judge the actual core functionality against the binding category descriptions.
- Annex VII connection
- 1(a) intended purpose and 2(a) architecture support the category rationale.
CRA-RISK-001 · Permalink
Document and maintain a product cybersecurity risk assessment
Article 13(2)-(4); Annex VII(3)
- Typical repository evidence / where it lives
- docs/threat-model.md; risk-register.csv; security architecture decisions; release risk reviews.
- Other evidence / where to look
- Operational context, user and misuse evidence, signed residual-risk decisions and external test findings.
- Observable evidence / what it establishes
- Named assets, threats, assumptions, proposed treatments and recorded review history.
- Strong supporting evidence
- A release-specific assessment linking realistic use and misuse cases to controls, test evidence, applicability decisions and accountable risk acceptance.
- Partial evidence
- A threat model for one service without the product's other components or operating environment.
- Insufficient by itself
- An empty risk-register template or a vulnerability scanner's numerical score.
- What cannot be inferred
- That all material risks were identified, a likelihood estimate is justified, or residual risk is acceptable to the manufacturer.
- Human assertion/decision needed? Yes
- Approve assumptions, requirement applicability, treatment and residual-risk acceptance.
- Annex VII connection
- 3 risk assessment; 2(a) design context; 6 test reports.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-ESS-001 · Permalink
Build risk-based security into the product and release defaults
Article 13(1)-(4); Annex I Part I(1), (2)(a)-(b); Part II(3)
- Typical repository evidence / where it lives
- Secure coding guidance; default configuration; tests/security/; .github/workflows/ security and release checks.
- Other evidence / where to look
- Release-bound security test reports, exploitable-vulnerability review and evidence of enforced release controls.
- Observable evidence / what it establishes
- Configured checks, security-related implementation and defaults in the inspected revision.
- Strong supporting evidence
- Risk-linked security tests run against the shipped build, reviewed findings, verified secure defaults and a recorded release decision.
- Partial evidence
- A configured SAST workflow without execution results or proof that release gates are enforced.
- Insufficient by itself
- A green build badge, a passing unit test suite or zero scanner matches.
- What cannot be inferred
- That all known exploitable vulnerabilities are absent, tests cover every risk, or repository defaults match the distributed product.
- Human assertion/decision needed? Yes
- Review test scope, exploitability, exceptions and whether release security criteria are met.
- Annex VII connection
- 2(a), 2(c) design and validated production processes; 3 risks; 6 tests.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-ESS-002 · Permalink
Protect access, confidentiality and integrity
Annex I Part I(2)(d)-(f); Article 13(2)-(4)
- Typical repository evidence / where it lives
- Authentication and authorisation code; TLS and encryption settings; integrity checks; negative access tests.
- Other evidence / where to look
- Deployed configuration evidence, key-management records and penetration-test results against the relevant release.
- Observable evidence / what it establishes
- Specific access checks, cryptographic calls, integrity controls and test cases present in source.
- Strong supporting evidence
- Threat-linked access and tampering tests on the released product, with verified deployment settings and reviewed key lifecycle controls.
- Partial evidence
- An authentication middleware implementation without proof that every protected entry point uses it.
- Insufficient by itself
- An encryption dependency or a README claiming enterprise-grade security.
- What cannot be inferred
- That controls cannot be bypassed, secrets are managed safely in operation, or deployed data is protected end to end.
- Human assertion/decision needed? Yes
- Determine risk-appropriate controls and assess the completeness of implementation and verification.
- Annex VII connection
- 2(a) architecture and controls; 3 risk-based applicability; 6 verification reports.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-ESS-003 · Permalink
Minimise data and attack surface, and limit disruption and incident impact
Annex I Part I(2)(g)-(l); Article 13(2)-(4)
- Typical repository evidence / where it lives
- Data-flow inventories; retention settings; rate limits; service and privilege configuration; resilience tests; logging policies.
- Other evidence / where to look
- Live exposure reviews, recovery exercises, traffic and failure testing, and operational data-retention verification.
- Observable evidence / what it establishes
- Declared data use, exposed interfaces, mitigation code and configured logging or resilience mechanisms.
- Strong supporting evidence
- A release-bound data and interface inventory with justified necessity, least-privilege review, failure testing and verified incident-containment behaviour.
- Partial evidence
- A rate-limit configuration or backup script without a demonstrated recovery or load test.
- Insufficient by itself
- A statement that only necessary data is collected, or that backups exist.
- What cannot be inferred
- That deployed interfaces match source, collected data is necessary, recovery works, or connected systems remain available during an attack.
- Human assertion/decision needed? Yes
- Justify data necessity and applicability; review resilience, exposure and incident-impact evidence.
- Annex VII connection
- 2(a), 2(c) architecture and monitoring; 3 risk assessment; 6 tests.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-VULN-001 · Permalink
Operate vulnerability handling and coordinated disclosure
Article 13(6)-(8), (17); Annex I Part II(2)-(6)
- Typical repository evidence / where it lives
- SECURITY.md; security.txt source; disclosure policy; triage runbook; advisory templates and remediation history.
- Other evidence / where to look
- Published contact and policy, monitored inbox records, case timelines, upstream notifications and user advisories.
- Observable evidence / what it establishes
- A stated reporting channel, policy, handling steps and any retained issue or advisory records.
- Strong supporting evidence
- A published CVD policy and usable contact, with attributable case records showing triage, remediation, upstream coordination and justified disclosure timing.
- Partial evidence
- SECURITY.md names a contact and response target but has no evidence of actual handling.
- Insufficient by itself
- A security email address or a policy template copied into the repository.
- What cannot be inferred
- That the contact is monitored, the policy is enforced, reports are handled without delay or affected users received advisories.
- Human assertion/decision needed? Yes
- Assign operational ownership, assess reports and approve remediation and disclosure decisions.
- Annex VII connection
- 2(b) vulnerability processes, CVD policy and contact evidence; 6 process tests.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-SBOM-001 · Permalink
Identify release components and document an SBOM
Annex I Part II(1); Article 13(5)
- Typical repository evidence / where it lives
- packages.lock.json; package-lock.json; pom.xml; other manifests and lockfiles; supplied CycloneDX or SPDX JSON.
- Other evidence / where to look
- Build output, SCA-generated SBOM, artifact digests and supplier component records.
- Observable evidence / what it establishes
- Declared or locked dependencies and the contents and structural usability of a supplied SBOM.
- Strong supporting evidence
- A release-bound CycloneDX or SPDX SBOM generated from the shipped build, with verified artifact identity and a reviewed inventory including at least top-level dependencies.
- Partial evidence
- A dependency manifest: ranges do not identify shipped versions, and even a lockfile may include development-only components.
- Insufficient by itself
- A README saying we track dependencies, or an empty generated SBOM.
- What cannot be inferred
- That all shipped components are present, a supplied SBOM is accurate, or the product has no vulnerabilities. Presence, structural usability and completeness are different claims.
- Human assertion/decision needed? Yes
- Confirm release linkage and inventory completeness, investigate divergences and assess component vulnerabilities.
- Annex VII connection
- 2(b) SBOM within vulnerability-process documentation; 8 supply to authorities where applicable following a reasoned request. This is not a general duty to publish the SBOM.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-UPDATE-001 · Permalink
Justify the support period and securely deliver security updates
Article 13(8), (9), (19); Annex I Part I(2)(c), Part II(2), (7)-(8)
- Typical repository evidence / where it lives
- SUPPORT.md; end-of-support policy; release workflow; signing and update verification code; update-user guidance.
- Other evidence / where to look
- Expected-use and lifecycle evidence, support commitments, signed release artifacts, delivery tests and update availability records.
- Observable evidence / what it establishes
- A proposed support end date, configured update mechanisms and stated distribution process.
- Strong supporting evidence
- An approved support-period rationale tied to expected product use, with authenticated release artifacts, tested distribution and retained availability evidence.
- Partial evidence
- A release-signing workflow or end-of-support date without execution, delivery or lifecycle evidence.
- Insufficient by itself
- A promise of lifetime updates or a signed Git tag without a verified update chain.
- What cannot be inferred
- That the chosen duration is justified, users can obtain and install updates, signing keys are controlled, or updates remain available for the required period.
- Human assertion/decision needed? Yes
- Approve the support rationale, applicable exceptions and the adequacy of delivery and retention arrangements.
- Annex VII connection
- 2(b) secure update distribution; 4 support-period rationale; 1(d) user instructions.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-REPORT-001 · Permalink
Prepare and make required actively exploited vulnerability reports
Article 14(1)-(2), (8); Article 16
- Typical repository evidence / where it lives
- Article 14 runbook; reporting templates; escalation and backup-owner records; drill notes.
- Other evidence / where to look
- Awareness timestamps, exploitation and affectedness evidence, submission receipts and affected-user communications.
- Observable evidence / what it establishes
- The presence of a runbook or retained drill record can be inspected; an actual reporting obligation and submission require external facts.
- Strong supporting evidence
- An accountable case decision and timestamped reports with platform receipts linked to the relevant vulnerability, plus user-notification records where applicable.
- Partial evidence
- A rehearsed runbook with named owners and the 24-hour, 72-hour and applicable final-report steps.
- Insufficient by itself
- A CVE or KEV match, an internal issue marked reported, or a successful drill presented as a real submission.
- What cannot be inferred
- That this product is actively exploited, when awareness arose, whether reporting is required, or whether the authority received a timely report.
- Human assertion/decision needed? Yes
- Assess the reporting trigger and awareness facts; make and record required reports and user communications.
- Annex VII connection
- 2(b) related vulnerability-handling process context. Annex VII documentation is not an Article 14 submission.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-REPORT-002 · Permalink
Prepare and make required severe-incident reports
Article 14(3)-(5), (8); Article 16
- Typical repository evidence / where it lives
- Incident reporting runbook; severity criteria; report templates; escalation roster; drill results.
- Other evidence / where to look
- Incident impact and awareness records, accountable severity decisions, platform receipts and affected-user notices.
- Observable evidence / what it establishes
- A written process can be inspected, but actual incident severity and reporting performance require incident and submission evidence.
- Strong supporting evidence
- A documented severity assessment, awareness timeline and retained receipts for the early warning, incident notification and applicable final report.
- Partial evidence
- A drill demonstrating the reporting process and backup ownership without a real incident record.
- Insufficient by itself
- A generic incident policy or an internal severity label without the Article 14 threshold analysis.
- What cannot be inferred
- That an incident meets the legal severity threshold, deadlines were met, or a final report was received by the reporting platform.
- Human assertion/decision needed? Yes
- Assess severity and awareness, own submissions, and determine affected-user communications.
- Annex VII connection
- 2(b), 2(c) related handling and monitoring process context; does not replace Article 14 reporting.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-TECH-001 · Permalink
Prepare, maintain and retain technical documentation
Articles 13(12)-(13) and 31; Annex VII
- Typical repository evidence / where it lives
- docs/technical-file/; architecture and design records; standards register; test reports; release-document index.
- Other evidence / where to look
- Controlled technical-file package, production-validation records, approved risk and support rationale, signed declaration and retention controls.
- Observable evidence / what it establishes
- Available documentation sections, named versions and links to retained supporting records.
- Strong supporting evidence
- A controlled release-specific file covering all applicable Annex VII elements, with traceable sources, responsible review, retained tests and a copy of the declaration.
- Partial evidence
- An architecture document and generated technical-file draft with missing production, testing or approval records.
- Insufficient by itself
- An Annex VII folder, a populated template or a generated export labelled complete.
- What cannot be inferred
- That the technical file is complete, current, authentic, retained for the required period or sufficient for a conformity assessment.
- Human assertion/decision needed? Yes
- Review every applicable section and its evidence, resolve omissions and control release and retention of the file.
- Annex VII connection
- 1 product and instructions; 2 design, production and vulnerability processes; 3 risks; 4 support rationale; 5 standards; 6 tests; 7 declaration; 8 SBOM on qualifying authority request.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-INFO-001 · Permalink
Provide product and security information to users
Article 13(18)-(20); Annex II
- Typical repository evidence / where it lives
- User manual source; secure installation and configuration guides; update and decommissioning instructions; support and contact pages.
- Other evidence / where to look
- The instructions actually supplied with the release, language and accessibility review, and publication or distribution evidence.
- Observable evidence / what it establishes
- Written instructions, stated security properties and contact or support details in the snapshot.
- Strong supporting evidence
- Release-matched instructions checked against the product and Annex II, delivered in the required form and language with verified contact and support information.
- Partial evidence
- A developer README with installation steps but no user-specific security or decommissioning guidance.
- Insufficient by itself
- A documentation URL or a statement that users should configure the product securely.
- What cannot be inferred
- That the instructions reach users, are understandable in the required language, or accurately describe the distributed product and its support arrangements.
- Human assertion/decision needed? Yes
- Review accuracy, audience, language and delivery for the relevant market and release.
- Annex VII connection
- 1(d) information and instructions required by Annex II.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-DOC-001 · Permalink
Complete conformity assessment, declaration and CE marking
Article 13(12); Articles 28-30 and 32; Annex V
- Typical repository evidence / where it lives
- Declaration draft; conformity-procedure index; CE artwork; references to certificates and sign-off records.
- Other evidence / where to look
- An authorised signed declaration, completed conformity-assessment records, valid external certificates where required and marking evidence.
- Observable evidence / what it establishes
- A declaration file or marking asset can be found, but authority, route completion and actual marking require verification beyond source.
- Strong supporting evidence
- An authenticated signed declaration identifying the product and applicable legislation, backed by the completed route and verified marking on the distributed product as applicable.
- Partial evidence
- A filled Annex V working draft or a certificate reference without scope and validity checks.
- Insufficient by itself
- A generated declaration, a CE logo in the repository or a passing evidence check.
- What cannot be inferred
- That the manufacturer has completed conformity assessment, an authorised person signed, the certificate covers this release or CE marking was correctly affixed.
- Human assertion/decision needed? Yes
- Complete the applicable procedure; an authorised signatory issues the declaration and the manufacturer controls marking.
- Annex VII connection
- 7 copy of the EU declaration; 5 standards and specifications; 6 test reports.
- Official source
- EUR-Lex: Regulation (EU) 2024/2847
CRA-GUIDE-001 · Permalink
Distinguish binding law from explanatory guidance
Editorial convention, not a separate CRA obligation. Legal context: Article 31 and Annex VII.
- Typical repository evidence / where it lives
- Source register; citations with authority labels and review dates; methodology documentation.
- Other evidence / where to look
- Current official publications and an editorial review of any interpretation drawn from them.
- Observable evidence / what it establishes
- Whether source entries contain a URL, date and binding or non-binding label.
- Strong supporting evidence
- A reviewed source register linking legal propositions to EUR-Lex and separately labelling Commission or ENISA explanatory material.
- Partial evidence
- A useful guidance link without a date or distinction between explanation and legal text.
- Insufficient by itself
- A Commission or ENISA logo, or a statement that guidance is legally binding.
- What cannot be inferred
- That guidance changes the Regulation, creates an additional obligation or validates a legal conclusion. This row is an editorial safeguard, not a compliance requirement.
- Human assertion/decision needed? No
- No separate legal approval is created by this convention; an editor still checks source status and interpretation.
- Annex VII connection
- No standalone Annex VII requirement to use this labelling convention; source traceability supports documentation review.
How this map was built.
Maintained by ConformOps. Dataset version 1.0.0; catalogue baseline cra-eu-2024-2847@2026-09-01.1; source review 2026-09-07.
- Scope: one editorial row for each of the 16 ConformOps requirement IDs in the named ruleset. These are grouped product mappings, not the number of legal obligations and not an exhaustive clause-by-clause CRA checklist. Fifteen rows map binding law; one documents a non-binding source-handling convention.
- Method: compare each mapped subject with the cited legal text, identify plausible software-team records, then separate what can be inspected from what requires operational evidence or an accountable decision. Examples are illustrative, not observations from a sample of repositories or a list of files ConformOps necessarily parses.
- Legal references are editorially checked against the English EUR-Lex texts on the review date. They describe the subject of this public row and may refine the assessment catalogue's broader locators. Annex VII connections are our crosswalk, not extra obligations. Commission and ENISA explanatory guidance is non-binding; implementing regulations are binding law. No ENISA guidance supplies an additional requirement in this version.
- Automatically observable means inspectable from a repository snapshot: Yes means the bounded fact can be inspected directly; Partial means only supporting records or implementation clues are visible; No means the decisive fact requires external verification. It never means automatically satisfied. A repository may retain an external record without proving its authenticity or current validity.
- Strong evidence means comparatively stronger support for the stated claim after checking authenticity, date, product scope, release or build identity, completeness and reviewer authority. It is not a legal safe harbour. Missing evidence in a snapshot means unknown, not absent in the organisation; a successful scan or build is not proof of compliance.
- Human decision needed concerns the substantive manufacturer or reviewer judgment described in this dataset. It is separate from whether ConformOps implements a mandatory approval gate for that rule. A No on the editorial source-handling row means no separate legal decision is created by that convention.
- Maintenance: review legal sources and catalogue coverage before each release; increment the dataset version and review date for content changes, list affected IDs and reasons in the changelog, and retain prior released data files. These are dated editorial findings, not a promise of continuous legal monitoring. Corrections can be sent to help@conformops.eu with the row ID and supporting source.
Coverage limits: grouped rows are not a complete decomposition of Annex I. For example, permanent data removal and secure transfer in Part I(2)(m) need their own implementation evidence; user decommissioning instructions alone do not establish that behaviour. Hardware-specific evidence and product-specific sector rules need additional analysis.
Law versus guidance: Regulation (EU) 2024/2847 and Implementing Regulation (EU) 2025/2392 are binding legislation. The Commission policy overview is non-binding explanation. Commission and ENISA guidance cannot replace the legal text. The CRA-GUIDE-001 row is not an additional statutory duty.
Timing: Article 71 provides for main application from 11 December 2027 and Article 14 reporting from 11 September 2026. The map describes evidence needs, not a claim that every duty already applies to every product. Read the reporting timeline and the cited legal text for the relevant dates and conditions.
Download, cite and build on it.
Reuse the original dataset under Creative Commons Attribution 4.0 International (CC BY 4.0). Credit ConformOps, link the licence and indicate any changes. ConformOps' original mapping, commentary and dataset structure. Third-party legal texts and guidance remain subject to their own reuse terms; no ownership of them or official endorsement is claimed.
CSV contains one row per requirement, with version, licence and methodology retained in each row. JSON includes the same records with a dataset-level vocabulary, methodology and changelog.
Suggested citation
ConformOps, CRA Software Evidence Map, version 1.0.0 (2026-09-07), https://conformops.eu/research/cra-software-evidence-map. CC BY 4.0. Indicate changes when adapting.
For a specific claim, append its requirement ID and permalink, for example CRA-SBOM-001. Cite the underlying legal text for legal requirements and this map for its evidence analysis.
Fixed release files: version 1.0.0 CSV and version 1.0.0 JSON. These preserve this edition when the current map changes.
Found an omission or a better evidence example? Send a correction with the requirement ID and a supporting source.
Changelog
Version 1.0.0 ·
Initial publication of all 16 mapped requirement IDs, with independently checked legal locators, evidence boundaries, Annex VII connections, methodology and CC BY 4.0 downloads. No repository sampling or compliance scoring is performed.