The central evidence question is not simply whether a document exists. It is whether the organisation can show which evidence applied to the product and release that was placed on the market, what changed later and how cybersecurity obligations were maintained through the support period. Preserve both current and historical evidence where older supported versions remain relevant to market surveillance or vulnerability handling.
Build Evidence Around the Product and Release
Every important evidence item should identify the product, model, software or firmware version and relevant date or release state. This makes it possible to reconstruct the conformity position for a product already on the market instead of presenting only the latest documentation for a later release.
Keep the Cybersecurity Risk Assessment With the Evidence Set
Article 13 requires the cybersecurity risk assessment to be documented, updated as appropriate during the support period and included in the technical documentation. Preserve the assessment version, review date, key assumptions, treatment decisions and links to the product evidence supporting those decisions.
Map Annex I Requirements to Technical Evidence
Maintain traceability from applicable Annex I requirements to design controls, process evidence, test reports and product-security records. Where a requirement is treated as not applicable, preserve the reasoning so a reviewer can distinguish a deliberate product-specific conclusion from missing evidence.
Version Architecture and Component Evidence
Architecture, dependency and SBOM information can change significantly between releases. Keep enough historical evidence to identify which components and security boundaries applied to each supported or investigated version, especially where a later vulnerability affects only part of the product population.
Retain Vulnerability-Handling Evidence Through the Support Period
Preserve vulnerability intake, validation, affected-version analysis, remediation decisions, security-update releases and user communications. Market surveillance can assess vulnerability handling as well as product design, so lifecycle records are part of the evidence story rather than separate operational tickets.
Keep Conformity Evidence Linked to the Product Version
Retain the conformity-assessment route, applicable standards or specifications, test reports, notified-body evidence where relevant, EU declaration of conformity and CE-marking records for the product version placed on the market. Later conformity work should not overwrite the historical record.
Apply the Manufacturer Retention Rule Correctly
Article 13 requires manufacturers to keep the technical documentation and EU declaration of conformity available to market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer. A support period longer than 10 years therefore extends the practical retention requirement for those records.
Maintain Economic-Operator Traceability for 10 Years
Article 23 separately requires economic operators to be able to present specified information about operators that supplied them with a product and, where available, operators to whom they supplied it. That information must remain presentable for 10 years after supply in either direction.
Preserve Change History Instead of Overwriting Evidence
When architecture, product functionality, development processes, standards or security controls change, preserve the previous evidence state and the reason for the change. Version history allows reviewers to understand whether a later improvement existed when the earlier product version was placed on the market.
Store Internal Supporting Records Where They Can Be Retrieved
Article 53 can reach related internal documentation needed to assess design, development, production and vulnerability handling. Engineering review notes, release approvals, remediation records and security decisions should therefore remain retrievable where they materially support the compliance position, even if they are not themselves formal Annex VII documents.
Maintain an Authority-Response History
Where an authority has already requested information, retain what was supplied, when it was supplied, which product version it concerned, any corrections made and the authority's follow-up. This helps prevent inconsistent statements during later reviews and provides context if the same issue expands across Member States.
Use Evidence Review Triggers
Review the evidence set after major product releases, substantial modifications, important component changes, conformity-route changes, serious vulnerability findings, significant cybersecurity risk assessments, authority requests and support-period changes. Evidence maintenance should follow the product lifecycle rather than wait for a market-surveillance investigation.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.