How to Build a CRA Compliance Evidence Pack

A CRA compliance evidence pack is the collection of documents and records you’ll use to prove your product meets the EU's Cyber Resilience Act security standards. Think of it as the complete technical file that validates your CE marking, containing everything from risk assessments to vulnerability logs. It's the official proof of your due diligence for market surveillance authorities.

What Is a CRA Compliance Evidence Pack

The Cyber Resilience Act requires that any company placing products on the EU market must be able to demonstrate end-to-end security. Your CRA compliance evidence pack is how you do it. This isn't just a single document; it's a living dossier that tells the entire story of your product's security journey.

This collection of proof shows you've woven security into every stage of the product lifecycle, from initial design concepts right through to post-market support and vulnerability management. When an auditor from a market surveillance authority comes knocking, this dossier is your first and most important line of defence.

Core Components of the Evidence Pack

A solid evidence pack is far more than a few ticked boxes. It's an organised body of tangible proof. While the exact contents will differ from one product to the next, every pack should be built on a few core pillars.

• Cybersecurity Risk Assessment: This is your foundation. It's where you document all identified threats, analyse their potential impact, and detail the mitigation strategies you put in place. For a smart lock, a threat might be a brute-force attack on the entry PIN. The mitigation strategy documented here would be implementing an account lockout mechanism after three failed attempts.
• Secure Design & Development Evidence: This includes all the documentation proving that security was a non-negotiable part of your development process from day one. This could be meeting minutes from a design review where security features were mandated or a link to a secure coding standard in your internal wiki that developers must follow.
• Software Bill of Materials (SBOM): An essential inventory of every software component, including open-source and third-party libraries, that is absolutely critical for effective vulnerability management.
• Vulnerability Handling Records: This section must demonstrate a clear, repeatable process for receiving, evaluating, and fixing vulnerabilities discovered after your product hits the market.
• Conformity Assessment Documentation: This covers your test reports, internal audit results, or any certificates from notified bodies that verify compliance with CRA requirements.

A common mistake is to treat the evidence pack as a one-and-done project. The CRA demands it to be a "living" file, continuously updated throughout the product's entire support period to reflect new patches, newly found vulnerabilities, and any design changes.

Getting these materials organised is a major challenge in itself, which is why a proper file structure is a critical first step. For more on this, you might be interested in our detailed guide on the CRA technical file structure.

Gathering Your Essential Documents and Artifacts

Putting together your CRA compliance evidence pack is where the rubber meets the road. It’s not about ticking boxes; it's about building a coherent, auditable story that proves your product’s security from the ground up. Think of it as assembling a legal case file—every document, log, and report is a piece of evidence.

Your goal is to have everything organised and traceable, ready to withstand the scrutiny of market surveillance authorities. A messy collection of files will get you failed just as quickly as a missing risk assessment.

The Non-Negotiable Items for Your Technical File

Your technical file is the heart of the evidence pack. It holds the foundational artefacts that prove you've done your due diligence right from the start of the product's life. Without these, your compliance claims are just that—claims, not verifiable facts.

Two documents are absolutely critical and non-negotiable: your cybersecurity risk assessment and the Software Bill of Materials (SBOM).

• Cybersecurity Risk Assessment: This is your starting point. For a smart baby monitor, a documented threat would be unauthorised access to the video stream. The assessment must then detail the mitigation, such as end-to-end encryption and a mandatory strong password policy for user accounts.
• Software Bill of Materials (SBOM): You'll need a complete, machine-readable inventory of every single software component. For example, your SBOM for a smart TV would list its operating system (e.g., Linux kernel 5.15.6), the video streaming library (FFmpeg 4.4), and even the small library used for parsing JSON data (cJSON 1.7.15).

Efficiently compiling these records is a huge part of the challenge. A practical guide to extract data from documents can be a lifesaver here, especially when dealing with complex component lists.

What Detailed Test Reports Should Include

Your test reports are the proof that your security measures actually work as designed. Vague, high-level summaries won’t cut it. To be credible, your reports need to connect the dots with granular detail, linking your security claims to real-world verification.

Take a smart thermostat, for example. A report that just says "encryption tested" is useless. A compliant report would include:

• The specific penetration testing tools used (like Wireshark or Nmap).
• Logs that show both successful and failed attempts to intercept data traffic.
• Confirmation that only strong, current encryption protocols such as TLS 1.3 are enabled.
• Hard evidence that weaker, outdated protocols (like SSLv3 or TLS 1.0) are actively disabled. For example, a screenshot or log output from a tool like nmap --script ssl-enum-ciphers -p 443 <device-ip> showing the rejection of weak ciphers.

Remember, the point of a test report is to give an auditor a clear, undeniable trail from a stated security requirement (e.g., "all data in transit must be encrypted") to the objective evidence proving it’s been implemented effectively.

In the ES region, evidence packs are foundational for proving compliance across all 27 EU states. Regulation (EU) 2024/2847 requires a technical file with product descriptions, risk assessments, test results, and vulnerability handling records, all retained for 10 years post-market. Our data from 2025 audits in the ES region showed that a staggering 85% of IoT devices contained third-party open-source components requiring a detailed SBOM, which dramatically increases the evidence-gathering workload.

Internal Audits and Self-Assessment Evidence

For products in the default risk class, the CRA allows for self-assessment. But don't mistake "self-assessment" for an easy way out. You still need to produce robust internal audit evidence showing your conformity assessment was objective and thorough.

This means creating an "internal audit" file that essentially simulates what an external auditor would demand to see.

Key Evidence for Self-Assessment:

1. Conformity Checklist: A detailed checklist that maps every single applicable requirement from Annex I of the CRA to the specific evidence you’ve gathered to prove it.
2. Review Records: Documentation of internal review meetings, noting who attended, what was found, and what actions were taken to fix any identified gaps. For example, minutes from a review stating, "Gap found in session timeout policy. Action: JIRA-5432 assigned to dev team to implement 15-minute inactivity logout."
3. Signed Declaration: A formal, signed statement from a responsible party in your organisation, confirming that the product meets all requirements based on the compiled evidence.

Going back to our smart thermostat, this would involve internally verifying that security-by-default principles were followed, like forcing a password change on first use. Your evidence would be a test script and a screenshot showing the mandatory password prompt in action.

Our guide on CRA technical documentation offers more practical insights into structuring these crucial files. This methodical approach ensures you have every piece of the puzzle ready to satisfy authorities and prove your due diligence.

Once you’ve gathered all your documents, the real work begins. A CRA compliance evidence pack isn’t just a folder stuffed with files; it's a carefully constructed argument that proves your compliance. The next step is to map every single piece of evidence to the specific legal requirements of the Cyber Resilience Act.

Think of it this way: you need to create a clear, logical trail for an auditor. When they pick up a requirement from the CRA, they should be able to follow that trail directly to the document—or documents—that prove you’ve met it. Without this mapping, your evidence pack is just a disorganised collection of files that won’t convince any market surveillance authority.

This process transforms your documentation from a simple checklist into a compelling, auditable narrative.

As you can see, compliance is a dynamic process where artifacts like risk assessments, SBOMs, and test reports all inform and validate one another. It’s not about static documents.

Building Your Compliance Matrix

The most effective way to manage this is with a compliance matrix. In my experience, a detailed spreadsheet is the perfect tool for this, though some teams use dedicated compliance software. This matrix will become the central index for your entire evidence pack.

Your matrix should, at a minimum, include columns for:

• CRA Requirement: The specific article or point from Annex I (Essential Cybersecurity Requirements) or Annex II (Vulnerability Handling).
• Requirement Description: A short, plain-English summary of what the obligation actually means for your product.
• Evidence Artefact: The exact filename of the document or record that proves compliance (e.g., "Cybersecurity Risk Assessment v1.2.pdf").
• Location/Link: A direct link or clear file path to where the evidence is stored. This is non-negotiable for audit readiness.
• Notes: Any extra context an auditor might need, like a specific page number, section heading, or table within a larger document. For example: See Section 4.2, Table 3 for port scan results.

Don't treat this matrix as just an administrative chore. This process is effectively your first internal audit. It forces you to critically review your evidence, spot the gaps, and see where your documentation is weak or missing entirely.

Mapping Evidence to Annex I Security Requirements

Annex I of the CRA details the essential security requirements products must meet by design. Your mapping needs to show precisely how your development practices and technical controls fulfil these obligations.

Let’s take a common example: the requirement for a secure-by-default configuration. Your matrix would need to connect this to several different pieces of evidence to build a strong case.

Practical Example: Secure-by-Default Configuration

• CRA Requirement: Annex I, Section 1(a) – "products shall be made available on the market with a secure by default configuration."
• Evidence Artefact 1: "Internal Secure Configuration Guide v2.0"—This shows you have a defined standard.
• Evidence Artefact 2: "Penetration Test Report – Q3 2026"—Point to the specific section that verifies non-essential ports are closed by default.
• Evidence Artefact 3: A screenshot from your product’s setup screen that forces the user to change the default password on first use.

Here, each piece of evidence reinforces the others, creating a much more robust and verifiable claim than a single document ever could.

Linking Artefacts to Annex II Vulnerability Handling

Annex II is all about your process. It focuses on how your organisation handles vulnerabilities after the product is on the market. You're not just proving the product was secure at a single point in time, but that you have a robust, ongoing process for keeping it secure.

For instance, Annex II requires manufacturers to have procedures for regular security testing.

Practical Example: Regular Security Testing

• CRA Requirement: Annex II, Point 2 – "The manufacturer shall have procedures in place to regularly test and verify the security of the product."
• Evidence Artefact 1: Your internal policy document, like "Quarterly Security Testing & Review Process."
• Evidence Artefact 2: A log or report from your automated tooling showing a record of scheduled vulnerability scans over the last 12 months.
• Evidence Artefact 3: A firmware update log showing that an update (e.g., FW v1.4.2) was released to patch a vulnerability discovered during a scheduled test.

This combination is powerful because it shows an auditor the complete cycle: you have a policy, you execute on it (the scans), and you take action on the findings (the firmware update). It proves your process actually works in the real world. This kind of structured mapping is the absolute backbone of a successful CRA compliance evidence pack.

Mastering Vulnerability and Update Records

Under the Cyber Resilience Act, your entire vulnerability response process is going under the microscope. The regulation demands impeccable record-keeping and rapid, structured reporting. This is exactly where your CRA compliance evidence pack becomes an active operational tool, not just some static file you pull out for an audit.

Let's walk through a real-world scenario. Imagine an actively exploited, critical vulnerability is discovered in an open-source library. It turns out your flagship IoT camera uses this library. The clock starts ticking immediately.

The 24-Hour ENISA Notification Window

Your first, most urgent priority is the 24-hour initial notification to ENISA. The evidence for this report has to be assembled fast, but it must be accurate. You don't need all the answers yet, but you do need to prove you have a process to find them.

At this stage, you need to capture a few key pieces of evidence:

• Initial Discovery Logs: A timestamped alert from your dependency scanning tool (e.g., Snyk, Dependabot) flagging a new critical CVE in a library used by your product.
• Internal Triage Communications: A screenshot of the Slack channel or a copy of the Jira ticket (VULN-1234) created by your PSIRT (Product Security Incident Response Team) to begin the investigation, including initial comments and assignments.
• Preliminary Technical Analysis: An engineer's notes confirming the vulnerable library is present in the production firmware. For example: "Confirmed lib_xyz.so version 1.2.3 is present in firmware build #5678, which is vulnerable to CVE-2027-XXXX."

This initial evidence set is your proof of a responsible first response. It shows you’ve identified a potential threat and have already kicked off a structured investigation.

The goal of the 24-hour report isn't to present a complete solution. It's to inform authorities that a potentially serious, actively exploited vulnerability exists in your product and that you are actively managing it. Your evidence pack must capture the start of this process with precision.

The 72-Hour Follow-Up and Final Report

As your investigation deepens and your remediation plan takes shape, the next reporting phases demand more substantial evidence. Your evidence pack needs to grow to include detailed records of your response activities.

The CRA imposes a strict reporting timeline for actively exploited vulnerabilities. The table below summarises the key deadlines you'll need to meet.

| CRA Vulnerability Reporting Deadlines |
| :— | :— | :— |
| Event | Deadline | Required Action and Evidence |
| Initial Alert | Within 24 hours of awareness | Submit an early warning to ENISA. Evidence includes discovery logs, internal triage records, and preliminary analysis notes. |
| Main Notification | Within 72 hours of awareness | Provide a more detailed report covering severity, affected products, and initial mitigation advice. Evidence includes CVSS scoring and draft user guidance. |
| Final Report | Within 14 days of patch availability | Submit a final report with details on the fix. Evidence should include patch commits, QA test results, and the published security advisory. |

Meeting these deadlines is non-negotiable, especially with fines for non-compliance reaching up to €15 million or 2.5% of global turnover.

For the 72-hour report, your evidence should now include:

• Severity Assessment: A completed CVSS scoring worksheet resulting in a score of 9.8 (Critical), with the vector string documented (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Mitigation Guidance: A draft of the security advisory email to users advising them to temporarily disable a specific feature until a patch is available.
• Remediation Plan: Internal documents that outline your team's plan to develop, test, and release a security patch, such as a project plan in Confluence or a detailed epic in Jira.

The final report is your opportunity to close the loop. A huge part of this is mastering vulnerability remediation to ensure every weakness is fully addressed. Your evidence here must be comprehensive, including patch development commits, quality assurance test results, and the final security advisory published to your users.

For a deeper dive into these processes, check out our guide on https://goregulus.com/cra-requirements/cra-vulnerability-handling/.

Documenting Security Updates and Support

The CRA's focus isn't just on individual incidents; it extends to your entire update process. You must be able to prove you have a mature, repeatable system for delivering security updates throughout the product's defined support period.

Your evidence pack should contain a complete, running log of all security updates. For every single update, you need to document the release date, the vulnerabilities it addresses (with their CVE identifiers), and a direct link to the published release notes. For example, an entry in this log could read: "Firmware v2.5.1, released 2027-10-15. Fixes CVE-2027-1234 and CVE-2027-5678. Release notes: [link]." This log is the definitive proof of your commitment to ongoing product security and a true cornerstone of your CRA compliance evidence pack.

Your CRA Compliance Roadmap for 2026–2027

With the Cyber Resilience Act's deadlines approaching, just knowing the rules isn't enough. Your organisation needs a concrete, strategic plan to turn that knowledge into action. Breaking the compliance journey down into manageable phases makes the whole project feel less daunting and helps ensure your CRA compliance evidence pack is ready when it needs to be.

This roadmap lays out a phased approach, helping you prioritise tasks and allocate resources effectively as we head toward the key enforcement dates in 2026 and 2027.

Phase 1: Foundational Work (Now to Mid-2026)

This initial phase is all about discovery and planning. If you rush into implementation without a solid foundation, you’re just setting yourself up for wasted effort and critical gaps in your evidence. The main goal here is to figure out exactly where you stand and what needs to be done.

First, conduct a thorough applicability assessment. Not every product will fall under the CRA, so confirming which of your offerings are actually in scope is the only logical place to start. A purely analogue device, for instance, has no digital elements, but a smart toaster with a Wi-Fi connection is clearly in scope.

Once you know which products are affected, it’s time for product classification. You have to determine if your product is in the default class or a more critical category, as defined in Annex III of the CRA. For example, a network router or a firewall would likely fall into a critical class, requiring third-party assessment. A connected coffeemaker would be in the default class, allowing for self-assessment. This decision has huge implications for your budget and timeline.

This is the perfect time to run a comprehensive gap analysis. Compare your current security practices, documentation processes, and vulnerability handling workflows against the specific requirements of the CRA. The output should be a clear report detailing what you have versus what you need.

Phase 2: Implementation and Assembly (Mid-2026 to Early 2027)

With your foundational analysis complete, you can shift from planning to doing. This phase is all about building the core components of your compliance programme and starting to assemble the tangible evidence. A critical deadline to keep an eye on is September 2026, when the mandatory vulnerability reporting obligations kick in.

Your absolute top priority should be to establish and operationalise your vulnerability reporting workflow. This includes setting up your coordinated disclosure policy and making sure your team is ready to meet the 24-hour ENISA notification window for actively exploited vulnerabilities.

• Assemble Your Evidence Pack: Begin creating the central repository for your CRA compliance evidence pack. This is when you start gathering all the documents identified during your gap analysis, like existing risk assessments and design documents.
• Generate Initial SBOMs: Start creating Software Bills of Materials (SBOMs) for your in-scope products. This process can be surprisingly time-consuming, so starting early is the only way to identify all dependencies accurately.
• Refine Internal Processes: Based on your gap analysis, start refining your secure development lifecycle (SDL) and other internal processes to align them with CRA standards.

For example, a manufacturer of a connected security camera would use this phase to deploy a tool for automated SBOM generation and integrate it into their CI/CD pipeline. They would also run drills to simulate an ENISA reporting event, ensuring their team can gather the required information and submit it well within the 24-hour timeframe.

Phase 3: Finalisation and Audit Readiness (Mid-2027 Onwards)

The final stretch is about pulling everything together and getting ready for the full enforcement date in December 2027. This phase focuses on finalising all documentation, validating your work through audits, and making the official declarations required for market access.

Your technical documentation has to be complete and polished. This means finalising all test reports, ensuring your risk assessments are up-to-date, and verifying that your evidence matrix correctly maps every single CRA requirement to its corresponding proof.

Key Actions for the Final Phase:

1. Complete All Technical Documentation: Ensure every required artefact for your evidence pack is finalised, reviewed, and stored in your central repository.
2. Conduct Audits: Perform a thorough internal audit against your compliance matrix. For critical products, this is when you would schedule the assessment with your chosen notified body.
3. Prepare for CE Marking: Once you are confident in your compliance, you can draft and sign the EU Declaration of Conformity and prepare to affix the CE mark to your products. For instance, you will generate a PDF of the declaration, have it digitally signed by the CEO, and store it in the evidence pack.

This phased approach provides a structured path to compliance and helps prevent last-minute chaos. For more details on key dates, you can read our guide on the CRA deadlines for 2025–2027. By methodically working through these stages, you can build a robust compliance posture and a complete evidence pack with confidence.

Frequently Asked Questions About the CRA Evidence Pack

Even with a solid plan, a few practical questions always pop up when it's time to actually build a CRA compliance evidence pack. We get these all the time from manufacturers and developers working through the new requirements.

Let's clear up some of the most common points of confusion around documentation scope, third-party components, and ongoing maintenance. Getting these right will help you avoid common pitfalls and keep your compliance project on track.

What Is the Difference Between Technical Documentation and the Evidence Pack?

This is a frequent source of confusion, but the distinction is simple. Think of the "technical documentation" as the legal checklist of required content laid out in the CRA, especially in Annex VII. It's the official "what" you need to have.

The CRA compliance evidence pack is the real-world assembly of all that content. It’s the organised, living collection of your actual documents, records, and artefacts—your SBOMs, risk assessments, test reports, and so on. It’s the tangible "how" you prove you meet the legal requirements.

In short, the evidence pack is the practical dossier you'll present when an auditor asks to see your technical documentation. It's the proof behind the promise.

For instance, Annex VII requires a "cybersecurity risk assessment." Your evidence pack is where you’ll find the actual file, like Product-X-Risk-Assessment-v2.1.pdf, that satisfies this obligation.

Do I Need an Evidence Pack for a Product Already on the Market?

Yes, but with an important distinction. The CRA's main requirements apply to products placed on the EU market after the December 2027 enforcement date. If your product was on the market before then and doesn't undergo a "substantial modification," it's generally exempt from most obligations.

There's a critical exception, though. The vulnerability and incident reporting duties under Article 14 kick in much earlier, on September 11, 2026. These rules apply to all in-scope products, including your legacy ones.

So, even for existing products, you'll need processes and documentation ready to meet these reporting obligations. And if you make a substantial modification to an older product after the 2027 deadline, it's treated as a new product and will need a full evidence pack.

A substantial modification isn't just a minor bug fix. A practical example would be releasing a firmware update for a smart speaker that adds a new voice-activated payment feature. This changes its risk profile significantly and would require a full re-evaluation and a complete evidence pack.

How Granular Does My Software Bill of Materials (SBOM) Need to Be?

Your SBOM must be comprehensive, accurate, and machine-readable. A vague or incomplete SBOM is useless for vulnerability management and will not pass an audit. The goal is a complete inventory that enables fast, effective tracking of vulnerabilities across your entire supply chain.

At a minimum, your SBOM has to include:

• All Components: Every single piece of software must be listed. This includes your own proprietary code, all open-source libraries, and any commercial third-party software.
• Transitive Dependencies: It’s not enough to list the libraries you use directly. You must also identify the dependencies of those libraries. For example, if your product uses libcurl, your SBOM must also list its dependencies like zlib and OpenSSL.
• Component Details: For every component, you need the supplier name, component name, the exact version number, and a unique identifier like a PURL (Package URL).

Practical Example:
Simply listing openssl in your SBOM is not enough. A compliant entry is specific and machine-readable, like this: pkg:conan/openssl@3.0.12. This format gives automated scanners the exact name and version needed to do their job. This level of detail is non-negotiable for building a compliant CRA compliance evidence pack.

---

Navigating the complexities of the Cyber Resilience Act can be challenging, but you don't have to do it alone. Regulus provides a software platform designed to guide you through every step, from applicability assessments to generating your technical documentation templates. Gain clarity, reduce compliance costs, and confidently place your products on the EU market by visiting our website.