Teams starting on the Cyber Resilience Act usually meet it as a list of deliverables. A risk assessment, an essential requirements checklist, a technical file, a Declaration of Conformity, a CE mark, a user information sheet. Worked as independent documents, the list produces artifacts that quietly contradict each other, and contradictions are precisely what a market surveillance review is designed to find. The regulation's documents form a dependency chain in which each artifact consumes the output of the one before it.
This post maps that chain end to end. It builds on the technical documentation evidence requirements and the self-attestation methodology, which cover two links of the chain in depth.
Scope and classification set the frame
Everything starts with two determinations that never appear in a user-facing document but control all of them. First, whether the product is in scope at all under Article 2. Second, where it sits in the three-tier classification, default, important under Annex III, or critical under Annex IV. Classification is consumed immediately by Article 32, which converts it into your conformity assessment route. A default product can self-assess under Module A. An important product can self-assess only by applying harmonised standards in full, and otherwise involves a notified body. A critical product heads toward certification.
The classification decision and its justification belong in the technical file, because every downstream artifact silently depends on it. Get it wrong and the error propagates through the route, the assessment depth, the declaration and the mark.
The risk assessment decides what applies
The cybersecurity risk assessment required by Article 13(2) and (3) is the chain's engine. It is not a generic threat report. Its specific legal function is to determine which of the Annex I Part I essential requirements are applicable to your product, because the regulation applies those requirements based on the risks the assessment identifies. An assessment that does not map its findings to the Annex I requirements has produced analysis the chain cannot consume.
A workable structure runs threat modelling per component and data flow, scores likelihood and impact, and then records, for each Annex I Part I requirement, whether it applies and how the identified risks justify that position, including the positions where a requirement is not applicable and why. That applicability record is the interface between the assessment and everything downstream. The methodology in detail is its own post, but the structural point stands regardless of method. The assessment's output format is an applicability decision per requirement, with reasoning.
Evidence accumulates against the requirements
Once applicability is fixed, each applicable requirement needs evidence that it is met. Secure-by-default configuration gets a configuration reference and test results. Update mechanisms get design documentation and a signing procedure. Vulnerability handling requirements from Annex I Part II get the CVD policy, the intake channel and the handling process records. Each piece of evidence points back at the requirement it satisfies, which keeps the collection auditable and reveals gaps while they are still cheap to close.
This is the stage where the work actually lives, and it is worth structuring deliberately. Evidence that accumulates against requirements can be rolled up mechanically. Evidence that accumulates in folders by team produces a documentation archaeology project at file-assembly time.
The technical file rolls it up
The Annex VII technical documentation is not written so much as assembled. Its prescribed contents are the outputs of the preceding stages. The product description and intended purpose, the classification and route decision, the documented risk assessment, the applicability positions, the evidence per requirement, the vulnerability handling documentation, the support period determination with its reasoning, the standards applied, and the test results. The file must exist before the product is placed on the market and be kept at the disposal of authorities for ten years or the support period, whichever is longer.
Two properties make a file survive review. Completeness against Annex VII, which is a structural check, and internal consistency, which is the harder one. The identifiers, versions, standards lists and dates inside the file must agree with each other and with the public artifacts outside it.
The declaration asserts, the mark announces
The EU Declaration of Conformity per Annex V is a one-page assertion that the technical file supports. Its fields restate the product identifiers, the standards applied and the route taken, and its signature converts the file's contents into a legal undertaking under the manufacturer's sole responsibility. The CE marking then announces that assertion on the product itself, with a notified body number attached where the route involved one. Neither artifact adds new facts to the chain. Both fail if they disagree with the file, which is why drafting them is a transcription exercise from the file rather than a writing exercise.
Annex II is the chain's public slice. The user information sheet republishes selected facts, the vulnerability reporting contact, the support period end date, the identification, the secure use instructions, in language users can act on. Because it is generated from the same determinations, drift between the Annex II sheet and the file is a self-inflicted inconsistency and one of the first things a desk review catches.
Substantial modification re-runs the chain
The chain does not run once. A substantial modification, a change affecting the product's compliance with the essential requirements or its intended purpose, triggers a new conformity assessment, and the trigger cascades. The risk assessment gets updated, applicability positions get re-derived, new evidence lands, the file gets a new version, a new declaration is drawn up, and the marking position is re-confirmed. Security updates that only reduce risk do not by themselves constitute substantial modification, which is a deliberate design of the regulation so that patching is never penalised.
This is why point-in-time snapshots matter. For every unit you place on the market, an authority can ask which version of the file, the assessment and the declaration covered it. A compliance record that only exists as the current state of a wiki cannot answer that question. A record that snapshots the assessment and its generated artifacts at each release can, and the ten-year retention obligation is effectively a requirement to keep those snapshots retrievable.
What this means for manufacturers
Run the chain in order and store it as one linked record. The order is scope, classification and route, risk assessment, applicability, evidence, technical file, declaration, marking, user information, and the link structure is what turns six documents into one defensible position. Assign each stage an owner, generate the downstream artifacts from the upstream determinations instead of retyping them, and snapshot the whole chain at every release and substantial modification. The Annex VII explainer covers the file's required contents, and the Article 32 explainer covers the route logic the chain starts from. Manufacturers who work this way report the same thing. The first product is the expensive one, and every product after it inherits the structure.