How Does Product Certification Software Work? From Technical File to Certificate

What does product certification software do?

Product certification software manages the application, the product family and variants, the applicable program, the technical file, testing-inspection-audit tasks, findings, review and decision, certificate scope, surveillance and product changes in a single traceable file.

The aim is not to produce a certificate PDF faster. The real aim is to be able to show by which technical requirements and with which samples and evidence each product was assessed, on which file version the decision rests, and whether a later change affects the certificate scope. The software organizes this evidence chain; it does not assume the conformity assessment body's competence, the program owner's rules, the manufacturer's obligations or the authorized decision.

What do ISO/IEC 17065 and ISO/IEC 17067 determine?

ISO/IEC 17065 sets the requirements for bodies certifying products, processes and services; ISO/IEC 17067 provides the fundamental guide for understanding, developing and operating product certification schemes.

According to the ISO status page dated 11 July 2026, ISO/IEC 17065:2012 is still the published version; it was reviewed and confirmed in 2024 and is expected to be replaced by ISO/IEC FDIS 17065 in the coming months. ISO/IEC 17067:2013 is also still the published version; ISO/IEC FDIS 17067 for a second edition is under development. This transition picture shows that software must manage the standard not only by name but by edition, program version and effective date. [1] [2]

TÜRKAK treats product certification body accreditation within the framework of TS EN ISO/IEC 17065, applicable EA/IAF mandatory documents and guides. Depending on the activity required by the product or program, the applicable requirements of ISO/IEC 17025 for testing, ISO/IEC 17020 for inspection and ISO/IEC 17021-1 for management system auditing may also come into play. Product certification software is therefore not just a certificate module; it is an orchestration layer linking different assessment sources in the same decision file. [3]

What steps does the digital flow from technical file to certificate consist of?

The flow consists of application and program selection, product identity, technical file, assessment tasks, nonconformity closure, review, decision, certificate and surveillance/change tracking.

At application, is the product or the program defined first?

The product identity and intended use are clarified first; then the applicable technical regulation, normative document and certification program are matched through authorized review.

Broad names like "electrical device", "machine" or "construction product" are not sufficient on their own. Trade name, model, variant, technical specifications, intended use, user group, production site, target market and, if any, existing certificates/reports must be kept in structured fields. Different voltage, material, software version or critical component options of the same product may require different assessments.

Program selection must not be made randomly from a dropdown. The program owner, normative document, certification scheme, required assessment activities, surveillance approach, mark usage and the body's scope of authority must be examined together. ISO/IEC 17067 provides a framework for understanding and operating schemes; but it does not by itself determine which legislation or module applies to a specific product. [2]

How does the technical file folder become a traceable data model?

Each document must be linked to the product/model, requirement, version, publisher, date, assessment status and the relevant test/inspection/decision record.

The content that may be found in a technical file varies by product and applicable rule. Product description, design/manufacturing drawings, critical parts or materials list, risk analysis, applied standards, test reports, inspection records, instructions for use, label/mark design and production control information are common examples. The software must not present this list as a universal, immutable legislative checklist; it must version it according to the selected program and technical regulation.

The EU's Decision No 768/2008/EC contains the common framework requiring the manufacturer to draw up the necessary technical documentation and carry out, or have carried out, the applicable conformity assessment procedure; and requiring the technical documentation to be such as to enable assessment of the product's conformity with the relevant requirements. Elements such as drawings, descriptions, applied standards and risk assessment are exemplified in the module texts. This source does not say the same technical file is sufficient for every product; sector legislation and the module are the determining factors. [4]

How are sample, testing and inspection records linked?

Every assessment result must be linked to the correct product and sample identity, the method used, the laboratory or inspection source and the immutable version of the report.

At sample acceptance, serial/lot, model, variant, quantity, photograph, seal or delivery information and storage status should be tracked. If testing or inspection is outsourced, the assignment, scope, report, revision and the body's assessment must stay in the same file. A report being uploaded to the system does not mean it is automatically accepted; it must be reviewed for product identity, method, scope, result and authority.

If the assessment program includes a production site audit, the plan, team, site, processes, evidence and findings are linked to the product file. Management system auditing, product testing and product inspection are different activities; the software must not merge all of them under "audit report" and lose the method and competence distinction. TÜRKAK's product certification explanation importantly shows in this respect that, depending on the program, the applicable requirements of ISO/IEC 17025, ISO/IEC 17020 or ISO/IEC 17021-1 may come into play. [3]

Once the nonconformity is closed, can the certificate be published automatically?

No. Handling the nonconformity, completing the assessment file and the authorized review/decision step must be kept separate; the software should only support the control and evidence flow.

A nonconformity record should show the relevant requirement, evidence, scope, owner, correction, root cause/corrective action need, submitted documents and the verification result. A new file upload by the applicant must not close the record by itself. The assessing person records the sufficiency of the evidence; if there are open or conditional issues in the file, the decision authority receives the correct status.

The decision screen can summarize results, show contradictions and block missing mandatory fields. However, decisions such as granting a certificate, narrowing the scope, requesting further assessment, suspension or withdrawal must be recorded with justification by authorized persons according to the program and the body's procedure. If a test report changes later, the old decision must not be silently linked to the new report; an impact review must be opened.

How are certificate scope and mark usage controlled?

The certificate must match one-to-one the products, models, normative documents, program, production sites and conditions approved in the decision; mark usage must be managed only per actual authority.

Fields such as certificate number, first issue, validity, revision, product description, models, standard/program version, manufacturer and production site must be generated from the structured record. A post-approval correction must open a new certificate version; the previous PDF and verification record must be preserved. The customer portal highlights only the current document while the internal user can see the change history.

The software must not turn the logo or conformity mark library into a free design area. The CE mark, accreditation mark, program mark and certification body logo are subject to different legal and contractual rules. A mark must not be added to a document before authority, scope, graphic rules and usage approval are verified. The phrase "the system produced the certificate" alone does not prove the product's regulatory conformity or the body's accredited authority.

Are product certification, CE and technical regulation the same process?

No. The applicable technical regulation determines which conformity assessment route will be followed; some routes involve a third party while others may rely on modules under the manufacturer's own responsibility.

The European Commission's 2022 Blue Guide is a comprehensive guide explaining the implementation of EU product rules; the guide itself is not binding legislation and the legal force lies in the relevant Union harmonisation legislation. It addresses economic operator roles, technical documentation, conformity assessment bodies, accreditation, market surveillance and the limits regarding the CE marking together. Therefore, in software, the product's target market and applicable legislation record is a more accurate starting point than a generic "CE certification" product. [5]

In Türkiye, under Law No. 7223 on Product Safety and Technical Regulations, products must conform to the applicable technical regulation; the Ministry of Trade's official FAQ page states that a product cannot be placed on the market, kept on the market or offered as a service unless the nonconformity is eliminated. The Regulation on Conformity Assessment Procedures explains that which module or modules will be followed for a product will be specified in the relevant technical regulation. Software can offer a rule library to help select the legislation; the final selection must be determined by the current official texts and authorized assessment. [6] [7]

Why should product change and surveillance be tracked in the same file?

Because a change in material, component, production site, design or software can affect the validity of previous evidence and the certificate scope.

When the applicant organization reports a change, the system should compare the old and new product structure; flag the affected drawings, risk, test, inspection, production and certificate records. A change cannot be automatically closed with a "minor" option. An authorized person must determine, with a decision record, whether retesting, additional documentation, a production site review or a certificate revision is required.

If there is a surveillance program, dates, activities, sample, market or production site records are planned per the program rule. Delays, results or nonconformities are linked to certificate status. Complaints and appeals are also managed with separate authority and confidentiality flows; they must not be lost as customer service notes. When the program changes, which version open files will be completed under must be determined by a written transition rule.

Which records does a solid product certification data model separate?

Product, model, variant, technical requirement, evidence, sample, assessment, finding, decision and certificate must be separate objects; their relations built with version and date information.

• Product family: Base model, variant and critical component relations.
• Requirements matrix: Technical regulation, standard/program clause and evidence status.
• Document version: The file's publisher, date, product scope and previous version link.
• Sample chain: Acceptance, identity, storage, dispatch, testing/inspection and return/destruction records.
• External assessment: The assigned body, scope, report and technical review outcome.
• Decision link: The assessment and file versions the decision used.
• Certificate cycle: Issue, revision, suspension, withdrawal, validity and verification status.
• Change impact: The changed element, affected evidence, required activity and decision.

This separation makes it queryable which variants a test report was used for, or which certificates need review when a component changes. In a system based only on a folder tree, these relations are left to file names and user memory.

How should the transition to product certification software be planned?

First a real technical file and decision flow of one program is modeled; then the pilot is validated with product family, external assessment, certificate and change scenarios.

1. Produce the program and document inventory

Collect the application form, requirements list, sample form, testing/inspection records, audit report, findings, decision, certificate, mark usage rules and surveillance plan. Identify each document's source and the approving role.

2. Build the evidence tree with one product family

Select a base model and at least two variants. Separate the common technical documents from model-specific evidence. Track in the pilot which reports a critical component change affects.

3. Test the external laboratory/inspection flow

Try assignment, sample dispatch, report acceptance, revision and technical review steps with real error scenarios. A report belonging to the wrong model or a missing scope must become visible in the system.

4. Verify the decision and certificate revision

Test the authorized decision role, missing-file block, scope selection, certificate version and the old document's verification status together. Producing a PDF must not be assumed to complete decision control.

What are the most common product certification software mistakes?

The biggest mistakes are treating CE and certificate as synonymous, melting variants into a single product, and automatically accepting evidence when a file is uploaded.

• Fixing the program: Using the same requirements list for every product and market.
• Trusting the file name: Leaving the product, version and requirement link only to the file name.
• Losing the sample trail: Not linking the test result to the correct serial/lot and variant.
• Auto-approving external reports: Not passing scope, method and product matching through technical review.
• Tying the decision to PDF production: Using document generation in place of an authorized decision.
• Using marks freely: Adding the CE or accreditation/program mark without verifying authority and graphic rules.
• Keeping changes as notes: Not assessing the evidence and certificate impact of a product revision.

How does Vizyon Cert support the product certification process?

Vizyon Cert can combine application, product family, technical file, assessment tasks, findings, decision, certificate and surveillance records in a single operations file, according to the organization's program and authority structure.

On the Vizyon Cert solution page you can explore the modular structure of the certification operation. Certification software service within the scope of which the current programs, forms, decisions and integrations are analyzed and the appropriate data model is designed. Installing the software does not mean the organization automatically conforms to ISO/IEC 17065 or is accredited; the process and practice must be verified with authorized assessments.

Preparing an anonymized product family, two variants, a test report, a nonconformity, a component change and a certificate revision for the demo gives the most realistic result. Process analysis with VizyonTech an end-to-end flow from technical file to decision can be built over these examples.

Frequently asked questions