How Should Conformity Evidence Be Kept?

Keeping conformity evidence means keeping the technical documentation, declarations, test reports, quality system records, notified body certificates and passport evidence for the period required, in a form that can be produced to a market surveillance authority on request. The keeping duty is a continuing duty that runs from placing on the market, and it applies even when the battery model is discontinued, the supplier changes, or the operator structure changes. Evidence that cannot be produced on request is, for surveillance purposes, evidence that does not exist, even when the underlying assessment was carried out correctly.

Evidence keeping is a system, not a folder. A system defines what is kept, where it is kept, who can access it, how it is versioned, how it is backed up, and how it is produced on request. A folder of documents without an index, without version control and without a production route will fail under the time pressure of a surveillance request, because the operator will search, duplicate and omit documents. A system with an index, version control and a production route will produce a complete file within the request period, and the completeness will be evident from the index.

What evidence must be kept?

Evidence to be kept includes technical documentation under Annex VIII, the EU declaration of conformity, test reports, calculations, quality system documentation and records where the module requires them, notified body certificates, notifications and surveillance reports, and the passport evidence that links the declaration and the assessment to the battery record. Each evidence type must be kept for the period required, with the keeping period running from the placing date for the battery model. A file that keeps the declaration but not the test reports, or that keeps test reports but not the quality system records for a Module D1 battery, is incomplete for the module in question.

An evidence index should list each evidence type, the model, the placing date, the storage location and the retention end date. An index without placing dates cannot show retention, and an index without storage locations cannot show production. The index should be reviewed annually, with evidence due for retention end marked and a documented decision on retention or disposal. Disposal without a documented decision, or disposal before the retention end date, is a keeping failure.

How long must evidence be kept?

Technical documentation and the declaration of conformity must be kept for ten years from the date the battery is placed on the market, as set in the operator and conformity provisions of the Regulation. Other evidence, such as quality system records and notified body surveillance records, must be kept for the period that supports the conformity file for the model, and in practice for the same ten year horizon where the evidence supports the declaration. The keeping period should be recorded per model, with the placing date as the start point, and the period should be applied to the complete file, not to selected documents.

Worked check: a model is placed on the market in 2026 and discontinued in 2027. The evidence file must still be producible in 2035, nine years after discontinuation, because the keeping period runs from placing, not from discontinuation. A file deleted on discontinuation, on the assumption that the model is no longer sold, fails the keeping duty. The retention end date in the index should show 2036, and the file should be retained until that date, with backup and access arrangements maintained.

How should evidence be organised?

Evidence should be organised by battery model and variant, with a contents list, version control, a change log and cross references between the declaration, the test reports, the quality records and the passport. Organisation by function, such as a single testing folder for all models, makes it difficult to produce a complete file for one model on request, because the reviewer must search across functions. Organisation by model, with function subsections, allows a complete file to be produced from one index entry, and it allows a change to one model to be filed without affecting other models.

Organisation should be tested by a mock production request, in which a complete file for a sample model is produced within a defined time, with the contents list checked against the file produced. A mock request that finds missing documents, or that takes longer than the request period, reveals an organisation gap. The mock should be carried out periodically, with the result and any corrections filed. The test is part of the keeping system, not an addition to it.

How are evidence changes handled?

Evidence changes, such as a design change, a supplier change, a test method change or a passport update, must be recorded as a change event, with the old and new evidence preserved, the change reason recorded, and the declaration and passport updated where the change affects them. A change recorded only by overwriting the old document, without preserving the original, hides the history that an authority may need to understand a battery placed under the original evidence. A change recorded without a reason leaves the reviewer unable to judge whether the change was assessed.

Change handling should include a change log per model, with the date, the change, the reason, the assessment carried out and the documents updated. A log without assessment detail cannot show that the change was assessed for conformity impact. A log with assessment detail, and with links to the updated documents, shows the change control that the conformity system requires. The log should be reviewed before each placing, so that an unassessed change is caught before the changed battery is placed.

What happens when an operator changes structure or vendor?

When an operator changes structure, is acquired, ceases activity or changes a software or hosting vendor, the evidence file must transfer with the responsibility, and access to the file must be preserved. A file held only in a personal drive, or only in a vendor system without export, will be lost or inaccessible after the change, and the new operator will be unable to produce the file on request. Transfer should be planned in advance, with the file index, the storage location, the access roles and the backup arrangement transferred and tested, and the transfer recorded with dates.

Transfer testing should include a production request from the new system, with the complete file produced and checked against the index. A transfer that copies files without testing production leaves the operator uncertain whether the new system can produce the file. A transfer with a tested production request provides evidence that the file survived the change intact. The transfer record should be retained with the conformity file, so that a later authority query about a gap can be answered from the transfer evidence.

How is evidence produced on request?

Evidence is produced on request by the response coordinator, using the index, with a document list, a language check and a completeness check before submission. As checked on 28 October 2026, the production route should be documented in the keeping policy, with the coordinator role, the index, the language and the timetable named. A production without a coordinator or an index will be incomplete, and the incompleteness will be visible to the authority. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. Keeping is a system with an index and a production route, and the system should be tested by a mock request.