How Is a Technical File Reviewed Before the Certification Decision?

Short answer: when is the technical file ready for a decision?

A file is ready for decision when the product and its revision are clearly identified, every applicable requirement is linked to current evidence, nonconformities are closed, and an independent review separate from the assessment has been completed.

The purpose of the review is not to count how many documents are in the folder, but to enable the decision maker to reconstruct an unbroken chain of evidence for a single product scope. If a document is missing, has an unclear validity period, or belongs to a different revision, the system must stay on the safe side and halt the decision.

Which seven gates should be checked before the decision?

Short answer: a file cannot be considered complete until identity, scope, applicable requirements, evidence, nonconformities, independent review, and decision inputs all pass together.

1. Product identity: are the model, type, variant, serial/batch scope, and technical revision consistent with each other?
2. Program and scope: do the application, contract, certification program, and requested certificate scope all describe the same product?
3. Applicable requirements: have the current versions of the legislation, standards, program rules, and customer requirements been determined?
4. Evidence sufficiency: is every requirement linked to verifiable evidence such as a drawing, risk record, calculation, or inspection or test report?
5. Closing of findings: are there open nonconformities, pending additional assessments, or unverified corrections?
6. Independent review: has an authorized person who did not take part in the assessment recorded adequate information and procedural completeness?
7. Decision package: can the decision maker see the scope, review outcome, exceptions, and open risks in a single view?

How should a requirement-evidence matrix be built?

Each row should show a single applicable requirement and the current record that evidences it. Instead of an "available" checkbox, keep the evidence identifier, revision, result, and review status.

Decision No 768/2008/EC provides that, in the EU harmonisation legislation modules, technical documentation must allow conformity to be assessed; and that, as appropriate, it covers product description, design and manufacturing information, risk assessment, standards, calculations, and test reports. Rather than copying this list verbatim for every product, match it to the applicable legislation and program.

How is within-file consistency tested?

Short answer: compare the same critical identifiers across different documents and treat any contradiction not merely as a warning but as a decision blocker.

• Compare the model/type names in the application, product label, drawings, and test report.
• Record that the tested sample represents the product family subject to the decision.
• Cross-link risk control measures to design outputs, usage information, and test results.
• Show which clauses of a partially applied standard were used and how the remaining requirements were met.
• Refer to authorized assessment whether old test or review results remain valid after a technical change.
• Separate the revision of a translation or exported PDF from the source record; never present a derivative as the original record.

The European Commission's 2022 Blue Guide also explains that the conformity assessment route depends on the product and the applicable rules. Therefore, a test report, CE marking, or a previous certificate alone is not sufficient decision evidence for every program.

Why should technical review be separated from the decision?

ISO/IEC's current conformity assessment guidance explains that assessment results should be documented before the review; that the review should be carried out by a person who did not participate in the assessment; and that the decision should be made after the review is completed. Even if the same person takes on both the review and the decision, the distinction of not having participated in the assessment activity is preserved.

In a digital workflow, at least three states should be kept separate: assessment completed, technical review acceptable and decision made. Completion of one state should not automatically generate another; the person, scope of authority, date, input version, and rationale should be recorded in an immutable activity trail.

How should standard and program versions be managed?

The checklist should be versioned together with the file. In ISO's official inventory, ISO/IEC 17065:2012 and ISO/IEC 17067:2013 are still the published versions; the 2026 revisions are at the FDIS development stage. Draft text must not be applied automatically as if it were a published requirement.

Every file should retain the program name/version, the applicable standard edition, the transition rule, and the checklist used on the decision date. When a rule is updated, past decisions are not silently rewritten; a new review or surveillance task is opened with an impact assessment.

How should a fail-closed decision gate be designed in software?

Tie the decision button not only to role authorization but to a verifiable file status. It is not enough for mandatory fields to appear filled; it must also be checked that the linked evidence is accessible, at the correct revision, and in a valid state.

1. Generate mandatory requirement rows from the program version.
2. Link each row to the product revision and evidence identifier.
3. Show open findings, missing evidence, conflicting identities, or pending assessments as blockers.
4. Verify whether the reviewer was on the assessment team and their scope of authority.
5. Snapshot the matrix and attachments used at the decision moment as an immutable package.
6. Manage subsequent changes with a new revision and impact record without overwriting the old decision package.

the end-to-end flow of product certification software explains the broader data model between application and certificate. the document revision and approval history guide details how the change trail should be preserved.

Which scenarios should be tested in the Vizyon Cert pilot?

Vizyon Cert while it is being evaluated, choose a single product family and a real but anonymized file. First establish the correct product, program, requirement, and evidence links; then test that the system actually halts the decision in negative scenarios.

• Upload a test report belonging to the wrong product revision.
• Leave a mandatory requirement without evidence.
• Try to open a decision with an unclosed nonconformity.
• Assign the user who performed the assessment as the reviewer.
• After the decision package, change the drawing and verify that the past package has not changed.

The success criterion is not merely a "file completed" label. The system should explain which requirement is deficient; preserve the re-review trail after corrections; and present only the valid version to the decision maker.