How Should Passport Software Be Evaluated Without Endorsing a Vendor?

Evaluating passport software without endorsing a vendor means judging a system against the Regulation requirements, the harmonised standards and the operator workflow, using evidence and tests, without ranking vendors or recommending a named product. The evaluation question is whether a system can create, maintain, exchange and provide access to passports that meet Annex XIII, Article 77 and Article 78, under the operator responsibility model. A system that is technically strong but does not support operator responsibility, tier control or audit trails fails the evaluation even when its interface is polished.

Evaluation discipline protects the operator, because the operator remains responsible for passport accuracy and availability even when a vendor provides the software. A vendor claim, a demonstration or a reference site does not transfer responsibility, and the evaluation file must show that the operator tested the system against the requirements, rather than relying on vendor statements. The file should be usable by an authority to understand why the system was chosen and what was tested, without naming a vendor ranking.

What requirements should form the evaluation criteria?

Evaluation criteria should be drawn from Article 77, Article 78 and Annex XIII, together with the harmonised standards for data exchange, identifiers, carriers, APIs and interoperability, and the registry implementing rules. Criteria should cover field completeness, tier control, identifier uniqueness and resolution, registry interaction, data exchange, update and audit trails, continuity after operator cessation, and evidence export. Each criterion should state the Regulation or standard source, the test method and the pass threshold, so that the evaluation is repeatable and auditable.

A criteria document that lists generic software qualities, such as ease of use or scalability, without Regulation sources, cannot support a compliance decision. A criteria document that lists only Regulation sources, without test methods, cannot be executed. The combined document, source plus test, is the evaluation basis, and it should be approved before vendor demonstrations, so that demonstrations are judged against the criteria rather than shaping the criteria.

How should demonstrations be tested?

Demonstrations should be tested with the operator data, the operator battery models and the operator workflow, rather than with vendor sample data alone. A demonstration with sample data can show interface features, but it cannot show whether the system handles the operator field set, the operator supplier data, the operator identifier allocation or the operator access tiers. The test should include creating a passport for a real model, exchanging it with a second system or a test harness, updating it under tier control, and exporting the evidence file, with each step recorded.

Worked check: a vendor demonstrates a system with sample electric vehicle data. The operator test repeats the demonstration with an LMT model, supplier data in the operator format and a repairer access request. The system handles the sample data well but fails the LMT field set and the repairer tier test. The evaluation records the failure on the operator test, not the success on the sample test, and the system is judged on the operator workflow. Sample success does not prove operator readiness.

What evidence should be required from a vendor?

Evidence required from a vendor should include standard conformance test results, interoperability test results, security and access test results, continuity arrangements, data processing limits, and the software version and field catalogue that were tested. Evidence should be in a form that the operator can verify, such as test reports with dates and versions, rather than as marketing statements. A vendor who cannot provide test evidence for a criterion should be marked as untested on that criterion, not as passing on the basis of a statement.

Evidence review should be recorded per criterion, with the evidence reference, the reviewer and the date. A review that records only an overall impression cannot be audited, and a review that records evidence per criterion can be revisited when a new version is released. The evidence file should be retained with the operator passport evidence, so that an authority can see why the system was judged capable at the time of selection.

How are data processing limits checked?

Data processing limits are checked against Article 78, which prohibits operators authorised to store or process passport data on behalf of the responsible operator from selling, reusing or processing data beyond what is necessary for the storing or processing service. The evaluation should review the vendor contract, the data processing agreement, the hosting arrangement and the technical controls that prevent unauthorised reuse. A contract that allows a vendor to use passport data for product improvement, analytics or other purposes beyond the service, without a legal basis in the Regulation, fails the limit check.

Contract review should be carried out with the data processing agreement and the technical architecture together, because a contract limit without a technical control can be bypassed, and a technical control without a contract limit can be changed. The combined review should state the limit, the contract clause, the technical control and the audit route. A vendor who cannot show both the clause and the control should be marked as untested on the limit, and the operator should not place passport data with that vendor until the limit is evidenced.

How is total cost and lock in assessed without ranking?

Total cost and lock in are assessed by listing the cost elements, the data portability route and the exit route, without ranking vendors against each other. Cost elements include implementation, data migration, hosting, registry interaction, support, updates for standard and act changes, and exit migration. Lock in is assessed by testing data export in the standard format, with the field catalogue and audit trail included, and by confirming that the export can be imported into a second system without loss. A system with a low initial cost and no export route carries a high exit cost, and the evaluation should state that cost explicitly.

A cost and exit file should be prepared per system evaluated, with the same cost elements and the same export test for each, so that the operator can compare the files without a vendor ranking. The comparison should be a factual comparison of elements and test results, not a score that hides the basis. The operator decision should be recorded with the file references and the reasons, so that a later reviewer can follow the decision without reconstructing it from demonstrations.

What should the evaluation file contain at the end?

The evaluation file should contain the criteria document, the test evidence per criterion, the contract and data processing review, the cost and exit file, and the decision record with reasons, dated and signed by the operator role responsible for passport accuracy. As checked on 28 October 2026, the standards and catalogue position should be recorded in the file, with a review date for the next standard or act publication. 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. Evaluation is an evidence file, and the operator remains responsible even when a vendor provides the system.