sota.io
2026-04-19·14 min read·

CRA Art.22: Technical Documentation Requirements — Annex V Contents, 10-Year Retention & Conformity Assessment Preparation (Developer Guide 2026)

Post #468 in the sota.io EU Cyber Compliance Series

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") does not merely require products to be secure — it requires manufacturers to prove their products are secure through structured technical documentation. Article 22 creates the documentation obligation that underpins the entire conformity assessment system in Chapter IV of the CRA.

Technical documentation under Art.22 is the evidence dossier that demonstrates compliance with the essential requirements in Annex I. Without it, a manufacturer cannot complete the EU Declaration of Conformity under Art.23, cannot affix the CE marking under Art.24, and cannot undergo any conformity assessment procedure under Art.32–36. Technical documentation is therefore the prerequisite for market access, not an administrative afterthought.

Critical deadline: 11 June 2026. Chapter IV of the CRA — which includes the conformity assessment framework and bodies — applies from that date. While the full product compliance obligations apply from 11 December 2027, manufacturers who want to use notified bodies or third-party conformity assessment procedures must understand the documentation requirements now. Notified bodies will need to be engaged months in advance, and technical documentation takes time to prepare correctly.

What Is Technical Documentation Under the CRA?

Art.22(1) defines the core obligation: "Before placing a product with digital elements on the market, manufacturers shall draw up the technical documentation referred to in Annex V."

Three elements stand out:

  1. Before market placement — documentation must exist before the product is sold, not prepared retroactively when an MSA asks for it
  2. The manufacturer bears the obligation — importers, distributors, and authorised representatives do not draw up technical documentation; they rely on the manufacturer's documentation
  3. Annex V defines the contents — the documentation must contain what Annex V specifies, not merely what the manufacturer thinks is relevant

Art.22(2) adds the continuity requirement: technical documentation shall be kept up to date throughout the product lifecycle. A documentation dossier prepared at launch and never updated is non-compliant the moment the product's security profile changes — a new version, a patched vulnerability, a changed component.

Art.22(3) establishes the retention period: technical documentation and the EU Declaration of Conformity shall be kept for ten years after the last product of the type has been placed on the market or the support period, whichever is longer.

Who Needs Technical Documentation?

Art.22 applies to all manufacturers of products with digital elements, as defined in Art.3(1):

The CRA carves out certain categories (Art.2(2)): products already covered by medical devices regulation (Regulation (EU) 2017/745), in vitro diagnostic devices, civil aviation equipment, and maritime equipment. These are not exempt from security requirements — they are subject to sector-specific rules that fulfil equivalent objectives.

Open-source software components that are not placed on the market in commercial contexts fall outside the CRA's scope (Recital 18), but open-source software stewards under Art.8 have their own lighter documentation obligations when they fulfil a supporting function for products that are placed on the market.

The Annex V Content Requirements

Annex V of the CRA specifies what technical documentation must contain. For the default category of products (those not falling into Class I or Class II under Annex III), manufacturers self-certify using the internal production control procedure under Annex VIII. Annex V applies to all such products. For Class I and Class II products requiring third-party assessment, Annex VI supplements Annex V with additional requirements.

Element 1: General Description of the Product

The documentation must contain a general description of the product with digital elements, including:

For software products, "version number" is non-trivial. The technical documentation must specify whether it covers a single version, a version range, or a product family. Version-specific documentation is required when a new release materially changes the security profile.

Element 2: Design, Development, and Production Information

This element requires manufacturers to document the security architecture of the product:

The Commission Guidance published March 3, 2026 (interpreting Art.26(1)) clarified that for software products, "design information" means documentation that enables an auditor to assess whether Annex I Part I security requirements have been met — not a full design specification in the sense of hardware manufacturing. This is particularly relevant for SaaS and cloud-delivered products where "production" is continuous deployment rather than physical manufacturing.

Element 3: Vulnerability Handling Procedures and Policy

Technical documentation must include the vulnerability handling policies and procedures established under Art.13 and Annex I Part II. This includes:

Annex I Part II specifies that the SBOM must be machine-readable and, at minimum, include top-level dependencies. The technical documentation must reference or incorporate the SBOM.

Element 4: Applied Harmonised Standards and Common Specifications

Where manufacturers have applied harmonised European standards (or, where harmonised standards don't exist, common specifications established by the Commission under Art.27), the technical documentation must identify:

EN 18031-1 (network-facing devices), EN 18031-2 (internet-connected devices), and EN 18031-3 (critical infrastructure devices) are the primary harmonised standards expected to emerge for the CRA. ETSI EN 303 645 (consumer IoT security) may provide an interim path for consumer devices. For software products, IEC 62443-4-1 (secure development lifecycle) may be relevant.

Manufacturers are not required to apply harmonised standards — they may demonstrate compliance by other means — but failing to apply applicable harmonised standards means forgoing the presumption of conformity under Art.26.

Element 5: EU Declaration of Conformity Reference

The technical documentation must contain, or provide a reference to, the EU Declaration of Conformity drawn up under Art.23. In practice, the technical documentation dossier typically contains a copy of the signed EU DoC, with the DoC referencing back to the dossier.

The EU DoC under Art.23 must state that the product meets the essential requirements in Annex I, identify the manufacturer, the product, the conformity assessment procedure used, and be signed by the manufacturer's authorised signatory.

Element 6: Conformity Assessment Procedure

The technical documentation must identify which conformity assessment procedure the manufacturer followed:

For the majority of software products — particularly SaaS, cloud, and enterprise software — Annex VIII internal production control applies. This means the manufacturer conducts the conformity assessment themselves, prepares the technical documentation, issues the EU DoC, and affixes the CE marking without notified body involvement.

Element 7: Security Incident Response Contacts

Technical documentation must include the contact points for reporting security vulnerabilities and incidents as required under Art.13(1)(g) and Art.15 (incident reporting). This connects the documentation dossier to the operational vulnerability response infrastructure.

Annex VI: Extended Requirements for Third-Party Assessment

For Class I products where the manufacturer opts for third-party examination, and for all Class II products, Annex VI extends the documentation requirements beyond Annex V. The additional elements include:

Technical risk assessment: a structured assessment of the cybersecurity risks associated with the product's intended use, foreseeable misuse scenarios, and operating environment.

Testing methodology: a more detailed description of the testing approach, including test cases mapped to specific Annex I requirements, testing environments, and results.

Documentation of harmonised standard gaps: where harmonised standards do not fully cover the requirements, documentation of the alternative compliance methods applied.

Evaluation of supply chain risks: for products incorporating third-party software components, an assessment of the supply chain risks and how they are managed.

Notified bodies under Art.35 and Art.36 will require Annex VI documentation for their examination processes. Manufacturers targeting Class I voluntary third-party assessment or Class II mandatory certification should begin preparing Annex VI documentation now — notified body queues will fill quickly as the December 2027 deadline approaches.

Class I and Class II: Which Products Require Third-Party Assessment?

Annex III of the CRA lists the product categories that fall into Class I (requiring conformity based on harmonised standards or third-party involvement for certain procedures) and Class II (requiring mandatory third-party assessment):

Class I products include: identity management software and privileged access management software, standalone browsers, password managers, software with a dedicated security function (anti-malware products, VPNs), network management software, and security information and event management (SIEM) systems.

Class II products include: hypervisors and container runtime environments used in critical infrastructure, firewalls and intrusion detection/prevention systems for industrial use, tamper-resistant microprocessors, hardware security modules (HSMs), smartcard IC chips, industrial automation and control systems (IACS), and connected devices for CNI use.

For manufacturers of Class II products, notified body involvement is mandatory. There is no self-certification path for Class II products under CRA.

For the vast majority of software products — particularly developer tools, SaaS applications, mobile apps, and most B2B software — neither Class I nor Class II applies, and Annex VIII internal production control (self-certification) is the path.

The 10-Year Retention Obligation

Art.22(3) requires that technical documentation and the EU DoC be kept for ten years after the last product of the type has been placed on the market or the support period ends, whichever is longer.

This creates a retention architecture challenge:

ScenarioRetention TriggerRetention Period
Software product, 5yr support periodLast product placed on market10 years
Hardware product, 3yr support periodLast product placed on market10 years
Software product, 12yr support periodEnd of support period12 years (longer)
Continuous update product (SaaS)Last subscription soldMinimum 10 years

For SaaS products, "last product placed on market" likely corresponds to the last customer subscription — which could extend retention obligations indefinitely for products with large customer bases.

The documentation must be available to MSAs on request throughout the retention period. This means not merely storing the documentation, but ensuring it remains retrievable, accessible, and readable after years of system changes.

Storage jurisdiction matters: Technical documentation stored on US-hosted cloud infrastructure is subject to CLOUD Act compelled disclosure, which could expose proprietary security architecture to non-EU government access. Manufacturers storing documentation on EU-native infrastructure — single legal order, no US parent entity — eliminate this risk. This is particularly relevant for Class I and Class II products where documentation contains sensitive security architecture details.

Commission Guidance March 2026: Key Clarifications

The Commission published guidance on March 3, 2026 interpreting Art.26(1) (presumption of conformity) and related provisions. Several clarifications are directly relevant to technical documentation:

Clarification 1: Software documentation is functional, not formal. The guidance confirmed that for software products, Annex V element 2 (design and development information) should describe the security architecture at a level that enables assessment of Annex I compliance — not reproduce formal hardware manufacturing specifications. Descriptions of threat modelling processes, secure coding standards, security testing pipelines, and dependency management practices satisfy this requirement.

Clarification 2: Living documentation is acceptable. Manufacturers may maintain technical documentation as a version-controlled living document, provided each major version has a snapshot that can be produced in response to an MSA request. This accommodates CI/CD development models where security architecture evolves continuously.

Clarification 3: SBOM as core documentation. The guidance confirmed that the SBOM required under Annex I Part II(2) forms part of the technical documentation under Annex V. An up-to-date SBOM that meets the machine-readable format requirement is both an Annex I Part II obligation and an Annex V documentation element.

Clarification 4: Self-assessment for most software. The guidance confirmed that software products not listed in Annex III Class I or Class II qualify for Annex VIII internal production control, regardless of complexity or market size. Enterprise SaaS, developer tools, and cloud services are self-certifiable under the CRA.

Connection to Art.23, Art.24, and Art.32

Technical documentation under Art.22 is the evidence base for three downstream compliance steps:

Art.23 — EU Declaration of Conformity: The EU DoC is the formal declaration that the product meets Annex I requirements. It cannot be drawn up without the technical documentation to substantiate the claim.

Art.24 — CE Marking: The CE marking can only be affixed after the EU DoC is signed. CE marking without a properly prepared technical documentation dossier is a compliance violation subject to Art.64 enforcement.

Art.32 — Conformity Assessment Procedures: The conformity assessment procedure chosen by the manufacturer (or required for Class I/II products) determines whether technical documentation is assessed by the manufacturer alone (Annex VIII) or submitted to a notified body (Annexes IX/X).

Manufacturers should develop their documentation, assessment procedure, and DoC in parallel, rather than sequentially — the three instruments cross-reference each other.

Python Implementation: CRATechnicalDocumentationKit

from dataclasses import dataclass, field
from datetime import date, datetime
from enum import Enum
from typing import Optional

class ProductClass(str, Enum):
    DEFAULT = "default"  # Annex VIII self-assessment
    CLASS_I = "class_i"  # Annex III Class I — voluntary or required third-party
    CLASS_II = "class_ii"  # Annex III Class II — mandatory third-party

class ConformityProcedure(str, Enum):
    ANNEX_VIII = "annex_viii_internal_production_control"
    ANNEX_IX = "annex_ix_eu_type_examination"
    ANNEX_X = "annex_x_full_quality_assurance"

@dataclass
class AnnexVElement:
    element_number: int
    element_name: str
    is_present: bool
    document_reference: str
    last_updated: date
    notes: str = ""

@dataclass
class CRATechnicalDocumentationDossier:
    product_name: str
    product_version: str
    manufacturer_name: str
    manufacturer_address: str
    product_class: ProductClass
    conformity_procedure: ConformityProcedure
    first_placed_on_market: date
    last_placed_on_market: Optional[date]
    support_period_end: Optional[date]
    annex_v_elements: list[AnnexVElement] = field(default_factory=list)
    authorised_representative: Optional[str] = None
    eu_doc_reference: Optional[str] = None
    sbom_reference: Optional[str] = None

    def retention_deadline(self) -> date:
        """Calculate 10-year retention deadline per Art.22(3)."""
        if self.last_placed_on_market is None:
            return date.max  # Still on market
        ten_year = date(
            self.last_placed_on_market.year + 10,
            self.last_placed_on_market.month,
            self.last_placed_on_market.day
        )
        if self.support_period_end and self.support_period_end > ten_year:
            return self.support_period_end
        return ten_year

    def days_to_retention_deadline(self) -> Optional[int]:
        deadline = self.retention_deadline()
        if deadline == date.max:
            return None
        return (deadline - date.today()).days

    def is_class_i_or_ii(self) -> bool:
        return self.product_class in (ProductClass.CLASS_I, ProductClass.CLASS_II)

    def requires_notified_body(self) -> bool:
        return (
            self.product_class == ProductClass.CLASS_II
            or (
                self.product_class == ProductClass.CLASS_I
                and self.conformity_procedure != ConformityProcedure.ANNEX_VIII
            )
        )

    def check_annex_v_completeness(self) -> dict:
        required = {1, 2, 3, 4, 5, 6, 7}
        present = {e.element_number for e in self.annex_v_elements if e.is_present}
        missing = required - present
        return {
            "complete": len(missing) == 0,
            "missing_elements": sorted(missing),
            "present_elements": sorted(present),
            "completeness_pct": round(len(present) / len(required) * 100, 1),
        }

    def compliance_summary(self) -> dict:
        annex_v = self.check_annex_v_completeness()
        return {
            "product": f"{self.product_name} v{self.product_version}",
            "class": self.product_class.value,
            "conformity_procedure": self.conformity_procedure.value,
            "annex_v_complete": annex_v["complete"],
            "annex_v_missing": annex_v["missing_elements"],
            "requires_notified_body": self.requires_notified_body(),
            "eu_doc_signed": self.eu_doc_reference is not None,
            "sbom_present": self.sbom_reference is not None,
            "retention_deadline": str(self.retention_deadline()),
            "days_to_retention_deadline": self.days_to_retention_deadline(),
        }


def build_annex_v_template(product_name: str) -> list[AnnexVElement]:
    """Generate a blank Annex V checklist for a new product dossier."""
    today = date.today()
    return [
        AnnexVElement(1, "General product description (name, version, intended purpose, manufacturer)", False, "", today),
        AnnexVElement(2, "Design and development information (architecture, components, test results)", False, "", today),
        AnnexVElement(3, "Vulnerability handling procedures and CVD policy (Annex I Part II)", False, "", today),
        AnnexVElement(4, "Applied harmonised standards / common specifications (Art.26)", False, "", today),
        AnnexVElement(5, "EU Declaration of Conformity (Art.23) — copy or reference", False, "", today),
        AnnexVElement(6, "Conformity assessment procedure identification (Annex VIII/IX/X)", False, "", today),
        AnnexVElement(7, "Security incident response contacts (Art.13(1)(g) + Art.15)", False, "", today),
    ]


# Example usage
dossier = CRATechnicalDocumentationDossier(
    product_name="MySaaS Platform",
    product_version="3.1.0",
    manufacturer_name="ExampleCo GmbH",
    manufacturer_address="Musterstraße 1, 10115 Berlin, Germany",
    product_class=ProductClass.DEFAULT,
    conformity_procedure=ConformityProcedure.ANNEX_VIII,
    first_placed_on_market=date(2025, 1, 15),
    last_placed_on_market=None,  # Still on market
    support_period_end=None,
    annex_v_elements=build_annex_v_template("MySaaS Platform"),
    sbom_reference="sbom/mysaas-3.1.0-spdx.json",
)
print(dossier.compliance_summary())

30-Item Technical Documentation Compliance Checklist

Annex V Elements (7 items)

Conformity Assessment Preparation (8 items)

EU DoC and CE Marking (5 items)

Retention and Storage (5 items)

Lifecycle Maintenance (5 items)

The sota.io Advantage: EU-Native Documentation Storage

Technical documentation under Art.22 contains sensitive security architecture information — component inventories, vulnerability handling processes, penetration test results, architectural diagrams. For manufacturers storing this on US-hyperscaler infrastructure, the CLOUD Act creates a risk: US government compelled disclosure orders can require US-controlled cloud providers to produce data regardless of where it is physically stored.

For EU manufacturers and any operator placing products on the EU market, storing technical documentation on EU-native, CLOUD Act-free infrastructure — like sota.io (German hosting, no US parent entity, single EU legal order) — means:

The intersection of Art.22 documentation obligations and infrastructure jurisdiction is directly relevant to high-security and critical infrastructure products in Class I and Class II. For manufacturers producing documentation that will be reviewed by notified bodies, the jurisdiction of storage is an increasing due diligence consideration.

What Comes Next in Chapter IV

Art.22 technical documentation is the foundation, but Chapter IV builds several obligations on top of it:

The next posts in the CRA series will cover Art.23 (EU DoC requirements) and Art.24 (CE marking for software products), completing the conformity assessment documentation triad.

Summary

ObligationWhat It RequiresWhen
Art.22(1)Draw up Annex V technical documentationBefore market placement
Art.22(2)Keep documentation up to dateThroughout lifecycle
Art.22(3)Retain documentation10 years after last placement or EOL
Annex V7 mandatory elementsBefore EU DoC and CE marking
Annex VIExtended elements for Class I/IIBefore notified body engagement
Chapter IV applicationConformity assessment framework11 June 2026
Full CRA obligationsAll requirements including Art.2211 December 2027

CRA Art.22 technical documentation is not a bureaucratic formality — it is the evidentiary foundation of CRA compliance. Manufacturers who build their documentation infrastructure now, before the December 2027 deadline, will be ready for conformity assessment, CE marking, MSA cooperation requests, and notified body scrutiny. Manufacturers who leave documentation to the last moment will face the same scramble that GDPR created in 2018 — except with market access consequences rather than merely reputational ones.

See Also