A team facing the CRA technical file for the first time usually reaches the same conclusion. There are dozens of required documents, the product has none of them, and someone needs to be assigned several months to write them. That reading produces a plan that is mostly wrong about where the work is. The evidence the file needs is largely sitting in the engineering organisation already, in architecture diagrams, test reports, release notes, user manuals and threat models. What does not exist is the demonstration that connects each of those to the requirement it satisfies. The technical file is a mapping deliverable before it is a writing deliverable, and getting that order wrong costs a team the most expensive thing it has, which is the time of the one person who understands both the product and the regulation.
This post covers what the regulation asks the file to demonstrate, why the mapping is harder than the writing, and why a gap list produced before existing evidence is mapped will send the team to rewrite documents it already owns. It builds on the technical documentation evidence requirements, which covers what the file must contain, and the artifact dependency chain, which covers how the documents feed each other.
The unit of assessment is the requirement
Annex VII sets out what the technical documentation must contain. A general description of the product, its design and development, the cybersecurity risk assessment, the list of harmonised standards applied, and reports of the tests carried out to verify conformity. Read as a packing list, it looks like a set of files to produce.
Article 31(2) supplies the framing that matters more. The documentation must contain the information necessary to demonstrate conformity with the essential requirements in Annex I. The load-bearing word is "demonstrate". A binder containing every document on the Annex VII list still fails if nothing in it establishes which requirement each document serves.
Annex I Part I(2) makes this concrete. The requirements at (a) through (m) apply on the basis of the risk assessment, which under Article 13(3) is the manufacturer's determination. Each one is either applicable, in which case the file needs an implementation reference, or not applicable, in which case the file needs a justification. Part I(1) and the whole of Part II apply in every case. An assessor works through that list one requirement at a time and asks the same question at each stop, which is where this is satisfied and by what. The technical file's job is to answer that question thirteen times over without the reader having to search.
This is why document count is a poor progress measure. Twenty uploaded files with no requirement mapping demonstrate nothing. Six mapped files can demonstrate a great deal.
Most of the inputs already exist
The structure of prEN 40000-1-2 makes the point clearly, because it separates artifacts into inputs and outputs.
The inputs are, for the most part, ordinary engineering documentation. Clause 6.2 alone asks for documentation on functional use cases, documentation on user types, documentation on market segments and comparable products, an architecture or data-flow diagram of the product including all its interfaces, and documentation of existing functions supported by product photos or other visual evidence where available. No manufacturer that has actually shipped a product lacks these. They exist as a Confluence space, a diagram checked into a repository, an onboarding deck, a product manual, a folder of photos from the certification lab.
The outputs are the artifacts that genuinely need to be produced. The product context documentation, the risk acceptance criteria, the applied methodology, the list of identified and evaluated risks, the treatment decisions with justification, the Annex I applicability table, the determined review regularity. These are the compliance work, and they depend on the inputs.
The catalogue runs to 88 artifacts across clause 6, clause 7 and the conformity set. Treating all 88 as blank at the start of a project is the error, because it inflates the apparent workload by counting evidence the company already holds and, worse, it directs the team to rewrite from scratch what it could have cited.
Why the mapping resists being done by hand
If mapping were a one-to-one lookup it would be clerical work and it would already be automated everywhere. Three things make it harder than that.
Documents rarely serve a single control. A combined architecture and threat-modelling document speaks to the interface documentation in clause 6.2, the documented cybersecurity architecture and design in clause 7.4, and parts of the asset and threat list feeding the risk assessment. Filing it against one control and moving on leaves the other two looking empty when they are not.
Coverage is graded rather than binary. A penetration test report covering the network interfaces of a device partially covers a verification control and leaves the local and physical interfaces untouched. Recording that as fully satisfied is the failure mode that stays invisible until an assessor pulls the thread, at which point the file's credibility on every other claim comes into question too. Partial coverage recorded as partial is a finding waiting to be closed. Partial coverage recorded as complete is a misrepresentation.
Volume compounds both. Reading a forty-page document against an 88-artifact catalogue and deciding, for each 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 conducting the risk assessment, and there are usually several dozen documents.
The determination itself has to stay with the manufacturer. Article 13(3) puts the risk-based judgment on the manufacturer and nowhere else. Anything that automates this can propose and rank, and the confirmation has to be a human act that is recorded as one.
How this works in CRA Portal
The evidence panel in the product workspace implements the mapping step ahead of the drafting step, on purpose.
Documents go in as a batch, up to five files of 5 MB each. PDFs are passed to the assessment model as file parts, text-like documents are decoded locally, and images in PNG, JPG, WEBP and GIF are sent as vision input. That last path is what makes an architecture diagram, a device rating label or a configuration screenshot usable as clause 6.2 evidence in the form it already exists, rather than something a person has to transcribe into prose first.
Each document comes back 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 explaining the match. The same pass extracts the product name or model the document describes and offers it as a single click to set the workspace's product name, which is a small thing that happens to be the first field a new workspace needs.
Nothing is written into the assessment at that point. The analysis is held on a draft record, presented for review per document, and only an administrator confirming a mapping creates the evidence rows. Unconfirmed drafts expire after 24 hours and are swept. The suggestion is the machine's, the assertion stays the manufacturer's, and the confirmation is audited.
Only once mapping is confirmed does the remaining set mean anything. From there the workspace can draft every missing clause 6 and 7 artifact in sequence, accepting each as it is generated and persisting after every one, skipping the artifacts that require manual input and listing them for the team. The run can be stopped with progress kept. Alongside it, a panel resolves what is left across all three dimensions of completeness, which are artifacts still to draft, acceptance criteria not yet passed, and controls with no audit-ready evidence behind them.
That ordering is the whole argument. A gap list computed before existing evidence is mapped measures the absence of filing rather than the absence of evidence, and every hour it sends the team to spend is an hour spent rewriting something the company already produced once. Map first, confirm the coverage accurately including where it is partial, and let the drafting work run at what is genuinely missing. The Annex VII explainer covers what the finished file has to contain, and the risk assessment methodology post covers how the outputs are built once the inputs are in place.