Every manufacturer we scope arrives with the same estimate of the problem. Dozens of required documents, none of them written, several months of someone's life. That estimate is usually wrong in an expensive direction. The evidence is largely in the building already. What is missing is the line connecting each essential requirement to the thing that satisfies it.
Demonstrate is the operative word
Annex VII of Regulation (EU) 2024/2847 reads like a packing list. A general description of the product, the design and development information, the cybersecurity risk assessment, the list of harmonised standards applied, the reports of tests carried out. Teams read it as a set of files to produce and plan accordingly.
Article 31(2) supplies the sentence that actually governs the work. The documentation must contain the information necessary to demonstrate conformity with the essential requirements in Annex I. A binder holding one of every item on the Annex VII list still fails that test if nothing inside it establishes which requirement each document serves.
Annex I Part I(2) is where this becomes mechanical. Requirements (a) through (m) apply on the basis of the risk assessment, which Article 13(3) places squarely on the manufacturer. Each is either applicable, needing an implementation reference, or not applicable, needing a written justification. Part I(1) and the whole of Part II apply unconditionally. An assessor walks that list one entry at a time and asks the same question at each stop, which is where this is satisfied and by what.
The practical consequence is that document count measures nothing. Twenty uploaded files with no requirement mapping demonstrate zero requirements. Six mapped files can demonstrate a great many.
Inputs you have, outputs you owe
The artifact structure in prEN 40000-1-2 makes the split visible, because it separates every clause into inputs and outputs. The inputs are, in the main, ordinary engineering documentation that predates anyone at the company having heard of the CRA.
| Artifact | Required input | Where it usually already lives |
|---|---|---|
| C6.2-IN-01 | Functional use cases, user stories | Backlog, product requirements docs |
| C6.2-IN-02 | User types | Personas deck, onboarding material |
| C6.2-IN-03 | Market segments and comparable products, state of the art | Competitive analysis, sales material |
| C6.2-IN-04 | Architecture or data-flow diagram including all interfaces | Diagram in the repo, an architecture wiki page |
| C6.2-IN-05 | Existing functions with product photos or visual evidence | User manual, certification lab photos |
| C7.4-OUT-01 | Documented cybersecurity architecture and design | Threat model, security design review notes |
The outputs are the genuine compliance deliverables. The product context documentation, the risk acceptance criteria, the applied methodology, the identified and evaluated risk lists, the treatment decisions with justification, the Annex I applicability table, the determined review regularity. These have to be produced, and they depend on the inputs above.
The full catalogue runs to 88 artifacts across clause 6, clause 7 and the conformity set. Treating all 88 as blank at kickoff inflates the apparent workload by counting evidence the company already holds, and then sends a team to rewrite from scratch what it could have cited. Our 48-document analysis prices the full documentary set. This piece is about the step that comes before pricing it, which is working out how much of it you are already holding.
Why mapping resists hand work
If this were a lookup it would be clerical and it would already be solved everywhere. Four things make it harder.
Documents rarely serve one control
A combined architecture and threat-modelling document speaks to the interface documentation in clause 6.2, the cybersecurity architecture and design in clause 7.4, and parts of the asset and threat list feeding the risk assessment. File it against one control and the other two look empty when they are not.
Coverage is graded on a scale
A penetration test covering a device's network interfaces partially covers a verification control and leaves the local and physical interfaces untouched. Logging that as fully satisfied is the failure mode that stays invisible until an assessor pulls the thread, and the credibility cost then lands on every other claim in the file. Partial coverage recorded as partial is an open item. Partial coverage recorded as complete is a misrepresentation.
Volume compounds both
Reading a forty-page document against an 88-artifact catalogue and deciding, per control it touches, how far it goes is most of a working day. The person qualified to do it is the same person who should be running the risk assessment, and there are typically several dozen documents.
The judgment cannot be delegated
Article 13(3) puts the risk-based determination on the manufacturer and nowhere else. Any tool touching this can propose and rank. The confirmation has to be a human act, and it has to be recorded as one.
What we built
The evidence panel in the CRA workspace runs the mapping step ahead of the drafting step, which is the whole design decision.
IngestStep 1
Up to five documents per batch, 5 MB each. PDFs go to the assessment model as file parts, text-like documents are decoded locally, and images in PNG, JPG, WEBP and GIF go in as vision input. That last path is what lets an architecture diagram, a device rating label or a configuration screenshot count as clause 6.2 evidence in the form it already exists, instead of being transcribed into prose first.
Map and reviewStep 2
Each document returns mapped to every control it plausibly serves, with a confidence score, a coverage verdict of satisfied or partial, and a one-sentence rationale per control. The same pass extracts the product name or model the document describes and offers it as a single click to name the workspace. Nothing is written to the assessment yet.
ConfirmStep 3
The analysis sits on a draft record until an administrator confirms it, per document. Confirmation creates the evidence rows and is audited. Unconfirmed drafts expire after 24 hours. The suggestion belongs to the machine, the assertion stays with the manufacturer.
Only after that does the remaining set mean anything. From there the workspace drafts every missing clause 6 and 7 artifact in sequence, persisting after each one, skipping the artifacts that need manual input and listing them for the team. A panel resolves what is left across the three dimensions that matter, which are artifacts still to draft, acceptance criteria not yet passed, and controls with no audit-ready evidence behind them.
The ordering is the point
A gap list computed before existing evidence is mapped measures the absence of filing rather than the absence of evidence. Every hour it generates is an hour spent reproducing something the company already paid to produce once. Map first, record partial coverage as partial, and point the drafting effort at what is genuinely missing.
11 September 2026. Article 14 reporting starts. Twenty-four hours for an early warning on an actively exploited vulnerability, counted from awareness.
11 December 2027. The CRA applies in full to every new product placed on the EU market. The technical file, the risk assessment, the SBOM, the support period commitment. Teams that start by inventorying what they already hold reach that date with a shorter list than they expected.
Artifact identifiers and clause references follow prEN 40000-1-2. Regulation references are to Regulation (EU) 2024/2847. A longer treatment of the same argument, aimed at compliance teams, is on the CVD Portal blog as Your CRA technical file is mostly written already. This article is informational and is not legal advice.