Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.

Wie das Beispiel-Artefakt im anderen Tab entsteht: Auslöser, Eingaben, Schritte und was "fertig" bedeutet. Orientierung auf Basis des CRA-Texts — ein Ausgangspunkt für Ihren eigenen Prozess, keine Rechtsberatung.

How it is created — REG-REC-021 Conformity Assessment Route Decision

Produces	REG-REC-021 — Conformity Assessment Route Decision (one per product)
Type	Regulatory record with project-planning consequences
Owner	Product Manager with the Product Security Lead
Approves	Managing Director (it can commit a five-figure budget and months of lead time)
Trigger	Immediately after the classification determination, during pre-development
CRA reference	Art. 32 and Annex VIII — Module A (internal control), Module B+C (type examination plus conformity to type), Module H (full quality assurance)

1. What this decides

The classification says which routes are available; this record says which one you will actually run, and what that obliges you to have in place before the product is placed on the market. It is short, but it is the document that turns compliance from an abstract duty into scheduled work.

2. Inputs

The classification determination and its sensitivity note.
The launch date and the project milestone plan.
The availability of harmonised standards or a European cybersecurity certification scheme relevant to your product — for important class I products this is what keeps self-assessment available.
Current Notified Body lead times, if there is any chance you will need one.

3. Steps

Write the decision logic as a table — classification against available routes — and mark your case. Anyone re-reading the record later should see the rule, not just the outcome.
State the selected route and the reason in one paragraph.
Translate the route into obligations you can schedule. For Module A that is: technical documentation per Annex VII complete before placing on the market, development conformity with Annex I Part I evidenced through your SDL and release dossier, vulnerability handling per Annex I Part II operational at launch — not after the first report — and a signed EU Declaration of Conformity plus CE marking.
Plan the contingency even when it does not apply today. If the sensitivity note in the classification can fire, record what happens then: whether a harmonised standard would keep Module A available, what a Notified Body procedure would cost, and how long booking one takes. Observed lead times of several months are the reason this belongs in pre-development.
Put a decision gate in the project plan. A milestone at the end of pre-development that re-confirms classification, with the rule that any later reclassification triggers an immediate Notified Body pre-booking to protect the launch date.
Record a budget placeholder in the project risk register for the contingency scenario.
Name the deliverable templates you will use: Declaration of Conformity per Annex V, the simplified declaration accompanying the product per Annex VI, technical documentation per Annex VII assembled continuously rather than at the end.

4. Done when

The route is named, reasoned and approved.
Each Module obligation appears as scheduled work in the project plan, with an owner.
The vulnerability-handling process is confirmed to cover this product from first shipment.
The contingency has a trigger, a lead time and a budget line.

5. Common mistakes

Treating self-assessment as "no work". Assembling the technical documentation in the last sprint before launch. Assuming a harmonised standard will be available in time — check its status, and record what you do if it is not.

6. In TRA Studio

The obligations you list in step 3 are exactly what belongs in your Secure Lifecycle as release-gate activities. Model them once and they apply to every product taking the same route, with the coverage view showing whether anything is still unowned.