How Does System Certification Software Work? A Digital Process from Application to Certificate

What does system certification software manage?

System certification software manages the application, scope review, audit time, auditor competence, Stage 1 and Stage 2 records, findings, independent review, decision, certificate and surveillance cycle in the same traceable file.

The value here is greater than moving a paper form onto a screen. The certification body must be able to show for each client what information was obtained when, on which inputs the plan was built, which audit evidence supported which finding, and through which authorized record the decision was made. The software makes this chain visible; it does not take over the certification body's technical responsibility, impartiality obligations or authorized decision.

How should the digital file's backbone be built?

A solid backbone centers not the customer record but interlinked and versioned decision evidence running from the application scope to the certificate cycle.

ISO/IEC 17021-1:2015 defines principles and requirements for the competence, consistency and impartiality of bodies performing management system audit and certification. According to ISO's official summary, management system certification is a third-party conformity assessment activity. Therefore a "sales opportunity" opened in a CRM is not a technically reviewed certification application. The two records may be linked; but their purposes, authorizations and approval gates differ. [1]

Why is application review not merely a form approval?

Application review must translate the organization's request into a certification scope; it must evaluate the activity, sites, personnel, standard, program rules and resource adequacy together.

Having only company name, employee count and standard selection on the application screen is not enough. Information such as in which sites and shifts activities are carried out, whether temporary or virtual sites exist, critical outsourced processes, an integrated system request, previous certification status and transfer needs changes the technical review. When initially entered information is later updated, the system must not delete the old answer; it should generate an assessment task on the impact of the change on the quotation, duration, team and scope.

TÜRKAK explains that management system certification bodies must meet, in addition to ISO/IEC 17021-1, the competence documents specific to the relevant management system standard, IAF mandatory documents and applicable EA/TÜRKAK documents. For example, the expertise and additional normative document sets for ISO 9001, ISO 14001, ISO/IEC 27001 or ISO 45001 files are not the same. Software must not reduce this difference to a single generic "ISO certificate" product; it must manage it by program and scope. [2]

How are audit time and team assignment linked?

First the justified calculation of audit time is made; then a competent, impartial and available team that can cover this time and scope is planned.

IAF MD 5:2023 states that in quality, environmental and occupational health and safety management systems the initial audit time is the sum of Stage 1 and Stage 2 as part of application review. Effective personnel count is the starting point; but it is not the only factor. Variables such as risk or complexity, site and shift structure, language, high regulatory density, outsourced processes and temporary sites are also considered. The basis of the calculation result and the corrections made must be recorded. [3]

Therefore software must not be designed with a "select headcount, get days" approach alone. The rule set version, input data snapshot, increase/decrease factors, explanation, approver and recalculation reason must be stored together. The topic-specific IAF MD 5 audit time guide explains why the base duration and organization-specific correction must be kept separate.

Team assignment likewise does not check only calendar availability. The auditor's sector/code qualification, relevant standard competence, role, previous assignments, impartiality or conflict of interest declaration and, if needed, technical expert support must be visible. When a suitable person cannot be found, the system must not secretly reduce the duration or move the scope to another code; it should route the planning exception to an authorized review.

How does the record progress from Stage 1 to the certification decision?

Each stage should close with its own purpose and output; the next step should reference the approved output of the previous stage, and a retroactive change should create a new version.

The Stage 1 record should make visible the readiness for audit, significant site and scope conditions, points affecting the Stage 2 plan and issues to be followed. In Stage 2 the audit plan, sampled processes, interviews, document and implementation evidence, and findings are linked in the same file. A finding is not just text and a class; it has a lifecycle with the evidence it rests on, the relevant requirement, owner, deadline, the correction submitted and the verification result.

When the file reaches the decision stage, the system must not switch to an "auto-generate a certificate if all boxes are full" logic. Checking for missing or contradictory records and presenting a summary and source links to the decision authority are useful; but the decision's scope, conditions, justification, date and authority must be recorded separately. If finding or scope data changes later, the old decision must not be silently updated; a need for reassessment must arise.

Do transfer and remote audit files fit the same flow?

A common record backbone can be used; but transfer review and remote audit should be separate scenarios with their own mandatory checks and evidence fields.

IAF MD 2:2023 defines minimum checks for certificate validity, accreditation scope and pre-transfer review in the transfer of accredited management system certificates. That a certificate known to be suspended must not be accepted like a normal transfer file, and that the required information be assessed through document review and, if needed, a pre-transfer visit, can be turned into a checklist in software. However, the system must not by itself issue the outcome of this review as a "suitable transfer". [4]

In remote use of technology, which activity was carried out with information and communication technology, the method used, participants, duration, connection security, evidence access and its place in the plan must be recorded. IAF MD 4:2023 provides a framework for the use of ICT for audit/assessment purposes. An interview that can be done remotely is not the same as a process that must be seen on site; the program and risk boundary must be preserved in authorized planning. [5]

Why doesn't the process end once the certificate is published?

The certificate is a single output of the three-year cycle; surveillance, scope changes, suspension, withdrawal, recertification and verification records continue the lifecycle.

On the certificate card, scope, standard, site, validity, decision, first issue and revision information should be separated. While the document PDF is stored as an immutable output, a correction or scope change must produce a new version. The customer portal should show the current document; the internal user should be able to see why and when previous versions changed.

According to TÜRKAK's announcement dated 2 December 2024, the TBDS infrastructure was extended to cover monitoring of audit information, and from 1 January 2025 it became mandatory for management system certification bodies accredited by TÜRKAK to enter their initial certification, surveillance, certificate renewal and other audit information into the system. This makes matching internal records with official notification fields important; however, a "submitted" status in the software must not be counted as successful without the actual service response and reference number. [6]

What does a defensible digital record look like in an audit?

A defensible record shows not just the final PDF but the input, version, actor, time, justification, approval and previous value together.

• Versioning: Application, calculation, plan, report, finding and certificate changes do not overwrite old data.
• Role separation: Sales, planning, auditor, technical reviewer, decision authority and administrator have different authorization sets.
• Evidence linkage: Every finding is linked to the relevant requirement and verification evidence; every decision to the file version used.
• Exception justification: A duration, team, date or scope change produces an authorized approval record, not a free note.
• Notification evidence: Email or portal delivery rests on the technical result and delivery time, not just the send button.
• Access log: Viewing, downloading and changing critical content are monitored by customer and role boundary.

ISO 19011:2026 offers current guidance on auditing principles, managing audit programs and auditor competence; ISO's official page also clearly states that this standard alone does not lead to certification. In software design, this guidance can be used for program management and audit discipline, but it cannot replace third-party certification requirements. [7]

How should the transition to system certification software be made?

The safest transition is first to map the real process and authorizations, then run a pilot in a single program, and expand the validated model in a controlled way.

1. Break the current file into its parts

Extract the application form, calculation sheet, quotation, auditor file, plan, report, findings, decision minutes, certificate and notification records. Identify where the same information repeats across files, which one is treated as the source and who can change it.

2. Run a pilot with a single program and a limited client group

Choose not the most complex exception but a manageable scope representing the real process. Pilot success criteria should not be processing speed alone; missing data, replanning reasons, wrong team assignment warnings, open finding visibility and access to the decision file should also be measured.

3. Verify integrations with evidence

In ERP/CRM, email, e-signature, TBDS or customer portal connections, only the success scenario must not be tested. Resubmission, authorization errors, service outages, partial transfers and correction scenarios must be handled without producing lost records.

4. Version the rules and standards

When an IAF document, program rule, standard or organizational procedure changes, which version open jobs continue under must be determined. The old file must not be rewritten with today's calculation; the rule of the period must remain visible.

What are the most common design mistakes?

The most widespread mistakes are treating the CRM status as a technical decision, reducing competence to calendar availability, and changing approved records without preserving history.

• Forcing every standard into the same workflow: A common backbone can be built; program and normative document differences must remain in separate rule sets.
• Giving audit time via a hidden formula: The user must be able to see the input, rule version, correction factors and justification.
• Automating the technical decision: The system can flag gaps; the certification decision must be an authorized and traceable human assessment.
• Making the certificate PDF the master record: The PDF is an output; it does not replace decision, scope, site, version and cycle data.
• Assuming the integration outcome: TBDS, email or portal submissions must be verified with the actual technical response.
• Deleting the old file: A revision must not destroy the previous evidence and decision relationship.

How does Vizyon Alia support this flow?

Vizyon Alia is configured to manage the certification file on a single process backbone, from application and quotation to auditor planning, from field/audit records to decision and the certificate cycle.

Vizyon Alia solution page where you can examine the module approach, and on the certification software service page you can see process and integration options. During setup, rather than directly copying current forms and procedures, scope, role, decision, version and integration rules must be verified together with the organization's real operation.

Preparing an anonymized application, a real audit time calculation, a competency matrix, a sample finding and a certificate revision scenario before the demo makes the outcome concrete. When planning a process analysis with VizyonTech an end-to-end pilot flow can be built over these five examples.

Frequently asked questions