CRA technical documentation and the declaration of conformity

Scope: one product, file to signature · Who: the officer who owns the file · Prerequisites: a route decision and a dated risk assessment · First result: one element index

1. Why this exists (the failure mode it prevents)#

A technical file is not a document. It is a set of records with owners, produced by work that happened, and kept longer than most people stay in their jobs.

Five patterns recur. The file is assembled the week before assessment, from whatever the release folders hold. The risk assessment is a template with the product name changed. The declaration is signed by whoever holds the title, unread. The file is frozen at release while the product keeps shipping. Nothing survives the end of support, because nobody wrote down when the clock stops.

Each surfaces against a named provision. The documentation shows that the product and its processes meet the Annex I requirements, holding at least the Annex VII elements. It is drawn up before placing and kept current, at least through the support period. It and the declaration stay available to market surveillance authorities for ten years after placing, or the support period if longer. On a reasoned request an authority gets what it needs, in a language it understands ¹.

The penalty tiers state the stakes. Missing the Annex I requirements or the Article 13 and 14 obligations reaches EUR 15 000 000, or 2,5 % of worldwide annual turnover, whichever is higher. Missing Article 28, 30(1) to (4) or 31(1) to (4) reaches EUR 10 000 000 or 2 %, whichever is higher. Incorrect, incomplete or misleading information reaches EUR 5 000 000 or 1 %. That tier covers what a body or an authority is told in reply to a request ².

One loop, not three silos. Governance decides who owns each element and which role signs. Drawing up the declaration is how the manufacturer assumes responsibility for compliance ³. Risk supplies the instrument the file answers to: the documented assessment, which states whether and how the Part I requirements apply ⁴. Compliance assembles, keeps and produces. Governance ensures protection, compliance demonstrates it, and both exist to manage risk.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
Technical documentation	The records showing that the product and its processes meet the Annex I requirements, holding at least the Annex VII elements.	5
Cybersecurity risk assessment	The documented assessment behind design, development, production, delivery and maintenance, updated through support.	6
EU declaration of conformity	The statement that fulfilment of the applicable Annex I requirements has been demonstrated, in the Annex V structure.	7
CE marking	The marking by which a manufacturer indicates that the product and its processes conform to the Annex I requirements and to other Union law.	8
Retention	Keeping documentation and declaration available to authorities ten years after placing, or the support period if longer. Every module repeats it.	9
Work product	The result of a cybersecurity activity meeting one or more associated requirements. Identifiers run WP-nn-nn, the first number the clause.	10

Substantial modification is defined in choosing the CRA conformity route, which owns the change test.

3. The method — ten steps, each with input, activity, output and owner#

3.1 Start from the risk assessment, because every element answers to it#

• Input: intended purpose, reasonably foreseeable use, conditions of use, expected time in use.
• Activity: run and document the assessment; record a conclusion per Annex I requirement.
• Output: a dated assessment record, versioned to the product version.
• Owner: risk, with the product security lead accountable.

The manufacturer assesses cybersecurity risks and carries the outcome through planning, design, development, production, delivery and maintenance. The assessment is documented and updated during the support period. It covers intended purpose and reasonably foreseeable use, the conditions of use such as the operating environment or the assets protected, and the expected time in use. It states whether the Part I point (2) requirements apply, in what manner and how they are implemented, and how Part I point (1) and Part II are applied. It goes into the documentation at placing, and where a requirement does not apply a clear justification goes with it ¹¹.

The guidance closes the usual escape route. Residual risk is judged against the requirement that the product ensures an appropriate level of cybersecurity based on the risks, read through intended purpose and foreseeable use. Internal risk tolerance, commercial strategy and cost do not decide it ¹². Where a requirement cannot be met, for interoperability or because of the product's nature, the constraint is documented, the risk assessed and compensating measures taken. The file and the user information carry that ¹³.

ISO/SAE 21434:2021 defines the cybersecurity case at 3.1.11 as a structured argument backed by evidence. One is required for an item or a component, and its work products supply the evidence ¹⁴. Read the assessment as the argument and the file as its evidence, and the assembly order stops being arbitrary.

3.2 Index the Annex VII elements, then give each one an owner and a record#

• Input: the Annex VII element list, the route decision, the release evidence store.
• Activity: open one row per element per product; name the record, location, role and status.
• Output: a documentation index, reviewed on a fixed cadence.
• Owner: product compliance holds the index; each element has its owner.

The workbook is at /templates/cra-technical-documentation-index.

Element	What Annex VII asks for	Record and owner
1	General description: intended purpose, software versions affecting compliance, illustrations for hardware, Annex II user information	Description sheet; product manager
2(a)	Design and development information, drawings and schemes where relevant, a system architecture description	Architecture record; lead architect
2(b)	Vulnerability handling: bill of materials, disclosure policy, contact-address evidence, secure update distribution	Handling record; product security lead
2(c)	Production and monitoring process information, and the validation of those processes	Control plan; quality lead
3	The Article 13 cybersecurity risk assessment, including how the Part I requirements apply	Assessment record; risk lead
4	The information taken into account to set the support period	Period rationale; product manager
5	Standards, specifications or schemes applied in full or in part, the parts identified, or the solutions adopted instead	Standards record; compliance
6	Test reports verifying the product against Part I and the processes against Part II	Test summary; verification lead
7	A copy of the EU declaration of conformity	The signed declaration; compliance
8	Where applicable, the bill of materials, on an authority's reasoned request	SBOM per version; product security lead

The list is verified as printed ¹⁵. Annex VII qualifies the set as applicable to the relevant product, so "not applicable" is legitimate, but not free. Where the element is out of scope because an essential requirement does not apply, the Article 13(4) justification sits beside it.

3.3 Treat elements 1, 2(a) and 2(c) as the evidence of Annex I Part I#

• Input: the architecture record, the release notes, the production control plan.
• Activity: write the description against what the assessment assumed; link design and production evidence to each Part I requirement.
• Output: a description-and-design set, cross-referenced to the assessment.
• Owner: the lead architect for design, the product manager for the description.

Part I requires products to be designed, developed and produced so that they ensure a level of cybersecurity appropriate to the risks. Its point (2) lists the properties following from the assessment ¹⁶. Core functionality has to be identifiable in the description, because that is what lets an authority check the conformity assessment regime applied ¹⁷.

Two omissions recur. Software versions affecting compliance are listed once and never updated, so the file describes a version nobody ships. Remote data processing goes unmentioned. The guidance asks each file to say whether the product has such a solution, or uses a third party's, and to describe it ¹⁸.

IEC 62443-4-1:2018 requirement SM-1 asks for a documented, enforced development process with configuration management under change control, requirements traceability, repeatable verification and validation, and review and approval of development records. Requirement SG-7 asks for a process closing errors and omissions in user manuals ¹⁹.

3.4 Treat element 2(b) as the evidence of Annex I Part II#

• Input: the vulnerability handling record, the disclosure policy, the update channel design.
• Activity: point the element at records the process already produces; do not restate the process.
• Output: an element 2(b) entry naming four records and their locations.
• Owner: the product security lead.

The element names four contents: the software bill of materials, the disclosure policy, proof of a reporting contact address, and a description of the technical solutions chosen for distributing updates securely. Element 8 adds the bill of materials itself, on a reasoned request ²⁰.

That process belongs to vulnerability handling and the SBOM under the CRA, and its records live in /templates/vulnerability-handling-record. The file's job is narrower: where each record sits, at which version, and who answers for it.

Element 4 comes from the same paragraph. The support period reflects the expected time in use, weighed against user expectations, the nature and intended purpose of the product, and Union law on lifetimes. It runs at least five years unless the product is used for less, and what was weighed goes into the documentation ²¹.

3.5 Add what the route adds, and no more#

• Input: the route decision record, the module, the body's engagement plan where there is one.
• Activity: map the chosen Annex VIII module onto the documents and retention duties it adds.
• Output: a route addendum to the index.
• Owner: product compliance.

Which module applies is decided in choosing the CRA conformity route. All four repeat one floor: ten years after placing, or the support period if longer.

• Module A, internal control. The Annex VII documentation, plus the measures making design, development, production and vulnerability handling deliver compliance. The written declaration is kept with it ²².
• Module B, EU-type examination. An application to one body carrying the documentation with an adequate analysis and assessment of the risks. Supporting evidence names the documents used, in particular where standards were not applied in full. A copy of the certificate, its annexes and its additions is kept ²³.
• Module C, conformity to type. Production measures keep manufactured units conforming to the approved type. A written declaration is drawn up per product model ²⁴.
• Module H, full quality assurance. Documentation for one model of each product category, plus quality-system documentation recorded in an orderly way as written policies, procedures and instructions. Approved changes and the body's reports are kept ²⁵.

3.6 Draw up the declaration, and the CE marking that goes with it#

• Input: the completed conformity assessment, the index, the signatory named in the route decision.
• Activity: fill the Annex V structure, add what the module specifies, record where the marking goes.
• Output: a signed declaration and a CE-marking record, filed as element 7.
• Owner: governance names the signatory; product compliance drafts.

Governance decides which role signs and owns each element, risk owns the documented assessment the file answers to, and compliance produces that file to a market surveillance authority years later.

Article 13(12) fixes the sequence: draw up the documentation, carry out the chosen procedure or have it carried out, then draw up the declaration and affix the marking. The declaration states that fulfilment of the applicable Annex I requirements has been demonstrated, and takes the Annex V structure. It carries what the procedure specifies, is updated as appropriate, and is available in the languages the Member State requires ²⁶.

Annex V lists eight items ²⁷.

1. Name, type and identifying information.
2. The manufacturer's or authorised representative's name and address.
3. A statement of issue under the sole responsibility of the provider.
4. The object of the declaration, identified so it can be traced.
5. A statement of conformity with the relevant Union harmonisation legislation.
6. References to standards, specifications or certification relied on.
7. Where applicable, the notified body's name and number, the procedure performed and the certificate.
8. Additional information, place and date of issue, name, function and signature.

Item 3 says "provider" where the rest of the instrument says manufacturer. Reproduce the model's wording; do not tidy it.

Two rules save work later. Where more than one Union act requires a declaration, one covers them all and identifies those acts with their publication references ²⁸. Variants sharing architecture, security-relevant design, intended purpose and risks can take one risk assessment, one file and one conformity assessment. One declaration then covers them, identifying the variants ²⁹.

The marking has its own rules. Its general principles are those of Article 30 of Regulation (EC) No 765/2008. It is affixed visibly, legibly and indelibly to the product; where that is not possible or not warranted, to the packaging and to the accompanying declaration. For software it goes on the declaration or on the accompanying website, in a part consumers reach easily and directly. Its height may be under 5 mm if it stays visible and legible. It is affixed before placing, followed by the notified body's identification number under module H. Where other Union law also provides for it, the marking indicates conformity with that too ³⁰. Users get a copy of the declaration, or the simplified Annex VI form carrying the exact address of the full one ³¹.

3.7 Keep the file alive, then keep it after the product stops#

• Input: the release plan, the change decisions, the support-period record.
• Activity: put the file on the release gate and the schedule on the records calendar.
• Output: an updated file per release, and a retention schedule with dated ends.
• Owner: release engineering triggers; product compliance adjudicates.

The updating duty is continuous, not annual. The guidance removes the argument that only a substantial modification triggers it ³². Whether or not an update is one, the assessment and the documentation are kept accurate, complete and continuously up to date, under Articles 13(7) and 31(2). Series production carries a parallel duty, covering changes in the development or production process, in design or characteristics, and in the standards conformity was declared against ³³.

Three clocks run past the release, at different lengths. Documentation and declaration stay available to market surveillance authorities ten years after placing, or the support period if longer. Each security update issued during that period stays available ten years after issue, or for the remainder if longer. The support period's end date, at least the month and year, is stated clearly at purchase ³⁴.

ISO/SAE 21434:2021 keeps the configuration information needed to maintain a fielded product's cybersecurity available until its cybersecurity support ends ³⁵. The records discipline is Annex A / ISO/IEC 27002:2022 control 5.33 Protection of records ³⁶. It asks for a retention schedule, and for storage letting records be identified and destroyed once the period ends.

3.8 Be able to produce it, in the form and the language asked for#

• Input: the index, the retention schedule, the storage locations.
• Activity: rehearse it: pull one product's whole file, check completeness and language, time it.
• Output: a production rehearsal record, with gaps logged as findings.
• Owner: product compliance.

On a reasoned request the manufacturer gives the market surveillance authority what it needs to see conformity of the product and its processes with the Annex I requirements. It comes on paper or electronically, in a language the authority readily understands, with cooperation on measures removing the risks ³⁷. Where a notified body is involved, the documentation and the correspondence on the procedure are drawn up in an official language of that body's Member State. A language the body accepts also works ³⁸.

One request follows its own path. Authorities may ask for bills of materials so the administrative cooperation group can assess Union-wide dependence on software components ³⁹. That reaches a category of products, not a suspected defect. The rehearsal measure is elapsed time to a complete, readable set.

3.9 Run the file as a management-system record, not a project deliverable#

• Input: the index, the document control rules, the storage and access model.
• Activity: bring the file under the same document control as the management system.
• Output: version control, review dates and access rules for every element.
• Owner: the management-system owner, with product compliance as custodian.

ISO/IEC 27001:2022 splits documented information into 7.5.1 General, 7.5.2 Creating and updating, and 7.5.3 Control of documented information ⁴⁰. Creation rules and controlled distribution are what most technical files lack. The analogue is Annex A / ISO/IEC 27002:2022 control 5.37 Documented operating procedures: documented, available to those who need them, reviewed and updated, with changes authorised ⁴¹.

ISO/SAE 21434:2021 clause 5.4.4 asks for a quality management system supporting cybersecurity engineering that addresses change, documentation, configuration and requirements management. Work products named in the cybersecurity plan sit under those disciplines, and stay accurate through to the post-development release ⁴².

IEC 62443-4-1:2018 requirement SM-12 asks for a process verifying, before release, that the applicable security-related processes were completed, with records documenting each. Requirement SM-6 asks for an integrity verification mechanism for the files shipped with a product ⁴³. The frame is product CSMS as a management system; the evidence-per-owner habit is control ownership and the control catalogue.

3.10 Measure four things, monthly#

• Input: the index, the assessment records, the declarations, the retention schedule.
• Activity: compute four counts with denominators; take exceptions to the governance forum.
• Output: a one-page file position.
• Owner: product compliance reports; governance decides.

Element completeness. Elements at status complete, over elements applicable, per product. Assessment currency. Products whose assessment predates their newest shipped version. Declaration currency. Products whose declaration names a version no longer shipping. Retention coverage. Records with a dated end and a named location. Targets are organisational choices; the denominators are not.

4. Deliverables#

Deliverable	Format	Template	Retention
Documentation index, one row per element per product	xlsx	/templates/cra-technical-documentation-index	Product life plus the floor
Cybersecurity risk assessment record	mixed	template pending	Placing plus ten years, or the support period
EU declaration of conformity, signed	document	Index workbook, Declaration sheet	Placing plus ten years, or the support period
CE-marking record: where affixed, when, which version	markdown	template pending	As the declaration
Retention schedule for file and updates	xlsx	Index workbook, Retention sheet	Current version plus one

The index is the pointer layer, not a fifth copy of the evidence.

5. What the authority or the notified body will ask#

6. Failure modes and how they surface#

All four share a root: the file is treated as a deliverable due on a date, not a record set.

7. Mapping the elements to the instruments#

Requirements are paraphrased, identifiers as printed ^{44 45}. The 27001 clauses are those logged for their titles ⁴⁶.

Element or duty	CRA	21434 or 62443-4-1	27001 or Annex A	Evidence
1 General description	Annex VII 1; Art. 13(18)	SR-1: Product security context	clause 7.5.2	Description sheet
2(a), 2(c) Design, production	Annex VII 2(a), 2(c)	SD-3: Security design review; SM-12: Process verification	clause 8.1	Architecture, validation
2(b) Vulnerability handling	Annex VII 2(b)	SUM-2: Security update documentation	Annex A control 5.37	Handling record
3 Risk assessment	Art. 13(2) to 13(4)	[WP-06-02] cybersecurity case	clause 6.1.2	Assessment record
4 Support period	Art. 13(8), 13(19)	[RQ-05-12] configuration information	Annex A control 5.33	Period rationale
5 Standards applied	Annex VII 5; Art. 27	SM-3: Identification of applicability	clause 6.1.3	Standards record
6 Test reports	Annex VII 6	SVV-1 to SVV-5	clause 9.1	Test summary
7 Declaration copy	Art. 28; Annex V	[WP-06-04] release for post-development report	clause 5.3	Signed declaration
8 Bill of materials	Annex VII 8; Art. 13(25)	SM-9: Security requirements for externally provided components	Annex A control 5.33	SBOM per version
Keeping and producing	Art. 13(13), 13(22), 31(2)	21434 clause 5.4.4	clause 7.5.3	Retention schedule

A mapping row is an aid to assembly, not evidence: no clause on the right discharges a duty on the left.

8. Checklist#

Each item is observable. A dated row, a signed file or a stored record counts; "documented" does not.

• Every product in scope has an index, one row per Annex VII element, each naming an owning role.
• Every element carries a record name and a location that resolves outside the producing team, and any element out of scope because an essential requirement does not apply carries the Article 13(4) justification.
• The risk assessment names the intended purpose, conditions of use and expected time in use, and states per Annex I Part I requirement whether it applies and how.
• The support-period rationale records what was taken into account, and the end date is stated at purchase.
• Element 2(b) points at the bill of materials, the disclosure policy, the contact-address evidence and the update distribution.
• Where the product has a remote data processing solution, or uses a third party's, the file describes it.
• The standards list identifies which parts were applied, and the solutions adopted where none was.
• The declaration follows the Annex V structure, names the version it covers, and cites any other Union act requiring one.
• The CE-marking record names where the marking is affixed, on what date, and for software the reachable address.
• A release cannot close until the file version and the declaration version match the shipped version.
• The retention schedule holds the placing date, the support-period end, the derived end, the location and the owner, and a production rehearsal has been run in the last twelve months.

Related#

• Choosing the CRA conformity route — the route decision this file is assembled under.
• Vulnerability handling and the SBOM under the CRA — the process behind element 2(b).
• CRA obligations by product class — scope, class and operator roles.
• Product CSMS as a management system — the operating system the file records.
• /radar#cra-commission-guidance — the dated entry for the guidance cited here.

References#

Primary sources only. Identifiers and printed titles are as printed; requirements are paraphrased.

1. European Parliament and Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). OJ L, 2024/2847, 20.11.2024. Read at https://publications.europa.eu/resource/celex/32024R2847 ⁴⁷
2. European Commission. Commission guidance on the application of the Cyber Resilience Act, annex to C(2026) 5252, 27.7.2026. Read at https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation ⁴⁸
3. ISO and SAE International. Road vehicles — Cybersecurity engineering. ISO/SAE 21434:2021. Introduction and clauses 3.1.11 to 6.5, licensed copy; https://www.iso.org/standard/70918.html ⁴⁹
4. IEC. Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements. IEC 62443-4-1:2018. Requirements SM-1 to SG-7, licensed copy; https://webstore.iec.ch/en/publication/33615 ⁵⁰
5. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Controls 5.33 and 5.37, licensed copy; https://www.iso.org/standard/75652.html ⁵¹
6. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Clause titles at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁵²
7. European Parliament and Council. Regulation (EC) No 765/2008, cited by Article 29 for the marking's general principles. https://eur-lex.europa.eu/eli/reg/2008/765/oj/eng ⁵³

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, SAE International or any other standards body.