Como funciona o software de certificação de sistemas? Processo digital do pedido ao certificado

O que gere o software de certificação de sistemas?

O software de certificação de sistemas gere, no mesmo processo rastreável, a candidatura, a análise de âmbito, a duração da auditoria, a competência dos auditores, os registos da Fase 1 e da Fase 2, as não conformidades, a revisão independente, a decisão, o certificado e o ciclo de vigilância.

O valor aqui é maior do que transportar um formulário em papel para o ecrã. O organismo de certificação deve conseguir mostrar, para cada cliente, que informação foi obtida e quando, com que entradas o plano foi construído, que evidências da auditoria sustentaram que não conformidade e através de que registo autorizado a decisão foi tomada. O software torna esta cadeia visível; não assume a responsabilidade técnica do organismo de certificação, a sua obrigação de imparcialidade nem a sua decisão autorizada.

Como deve ser construída a espinha dorsal do processo digital?

Uma espinha dorsal sólida centra-se não no registo do cliente, mas nas evidências de decisão interligadas e versionadas, desde o âmbito da candidatura até ao ciclo do certificado.

A ISO/IEC 17021-1:2015 define os princípios e requisitos para a competência, a consistência e a imparcialidade dos organismos que realizam auditoria e certificação de sistemas de gestão. Segundo o resumo oficial da ISO, a certificação de sistemas de gestão é uma atividade de avaliação da conformidade por terceira parte. Por isso, uma “oportunidade de venda” aberta num CRM não é uma candidatura de certificação tecnicamente analisada. Os dois registos podem estar ligados; mas os seus fins, as suas autoridades e os seus controlos de aprovação são diferentes. [1]

Porque é que a análise da candidatura não se resume a uma aprovação de formulário?

A análise da candidatura deve converter o pedido da organização num âmbito de certificação; deve avaliar em conjunto a atividade, os locais, o pessoal, a norma, as regras do programa e a suficiência de recursos.

Não basta que o ecrã de candidatura contenha apenas o nome da empresa, o número de trabalhadores e a escolha da norma. Informações como em que locais e turnos as atividades decorrem, se existem locais temporários ou virtuais, os processos críticos subcontratados, o pedido de sistemas integrados, o estado de certificação anterior e a necessidade de transferência alteram a análise técnica. Quando a informação inicialmente introduzida é atualizada mais tarde, o sistema não deve apagar a resposta anterior; deve gerar uma tarefa de avaliação do impacto da alteração na proposta, na duração, na equipa e no âmbito.

A TÜRKAK explica que os organismos de certificação de sistemas de gestão devem cumprir, além da ISO/IEC 17021-1, os documentos de requisitos específicos da respetiva norma de sistema de gestão, os documentos obrigatórios do IAF e os documentos EA/TÜRKAK aplicáveis. Por exemplo, os conjuntos de especialização e de documentos normativos adicionais dos processos ISO 9001, ISO 14001, ISO/IEC 27001 ou ISO 45001 não são os mesmos. O software não deve reduzir esta diferenza a um único produto genérico de “certificado ISO”; deve geri-la por programa e por âmbito. [2]

Como se ligam a duração da auditoria e a atribuição da equipa?

Primeiro faz-se o cálculo justificado da duração da auditoria; depois planeia-se uma equipa competente, imparcial e disponível, capaz de cobrir essa duração e esse âmbito.

A IAF MD 5:2023 indica que, nos sistemas de gestão da qualidade, ambiente e segurança e saúde no trabalho, a duração da auditoria inicial, como soma da Fase 1 com a Fase 2, faz parte da análise da candidatura. O número efetivo de trabalhadores é o ponto de partida; mas não é o único fator. Variáveis como risco ou complexidade, estrutura de locais e turnos, língua, elevada densidade legislativa, processos subcontratados e locais temporários são também consideradas. O resultado do cálculo e o fundamento das correções feitas devem ser registados. [3]

Por isso, o software não deve ser desenhado apenas com a abordagem “escolher o número de trabalhadores, obter o número de dias”. A versão do conjunto de regras, a fotografia dos dados de entrada, os fatores de aumento/redução, a explicação, quem aprovou e a razão do recálculo devem ser guardados em conjunto. Leia guia da duração da auditoria IAF MD 5, que explica por que razão a duração de base e a correção específica da organização devem ser mantidas separadas.

Na atribuição da equipa também não se verifica apenas a disponibilidade no calendário. Devem ver-se a suficiência do auditor por setor/código, a competência na norma relevante, o papel, as missões anteriores, a declaração de imparcialidade ou conflito de interesses e, se necessário, o apoio de perito técnico. Quando não se encontra uma pessoa adequada, o sistema não deve reduzir silenciosamente a duração nem transferir o âmbito para outro código; deve encaminhar a exceção de planeamento para revisão autorizada.

Como avança o registo da Fase 1 até à decisão de certificação?

Cada fase deve fechar com o seu próprio objetivo e resultado; o passo seguinte deve referenciar o resultado aprovado da fase anterior e uma alteração retroativa deve gerar uma nova versão.

O registo da Fase 1 deve tornar visível o estado de preparação para a auditoria, as condições importantes de local e âmbito, os pontos que influenciam o plano da Fase 2 e os assuntos a acompanhar. Na Fase 2, o plano de auditoria, os processos amostrados, as entrevistas, as evidências documentais e de implementação e as não conformidades são relacionados no mesmo processo. Uma não conformidade não é apenas texto e classificação; tem um ciclo de vida com a evidência em que se baseia, o requisito aplicável, o responsável, o prazo, a correção apresentada e o resultado da verificação.

Quando o processo chega à fase de decisão, o sistema não deve passar à lógica “se todas as caixas estiverem preenchidas, gerar automaticamente o certificado”. É útil verificar registos em falta ou contraditórios e apresentar ao responsável pela decisão um resumo com ligações às fontes; mas o âmbito, as condições, a justificação, a data e o responsável da decisão devem ser registados separadamente. Se mais tarde mudarem dados de não conformidade ou de âmbito, a decisão anterior não deve ser atualizada silenciosamente; deve surgir a necessidade de reavaliação.

Os processos de transferência e de auditoria à distância cabem no mesmo fluxo?

Pode usar-se a mesma espinha dorsal de registos; mas a análise de transferência e a auditoria à distância devem ser cenários separados, com campos de controlo e evidência obrigatórios próprios.

A IAF MD 2:2023 define controlos mínimos para a validade do certificado, o âmbito de acreditação e a análise prévia à transferência na transferência de certificados de sistemas de gestão acreditados. O facto de um certificado conhecido como suspenso não ser aceite como um processo normal de transferência, e de as informações necessárias serem avaliadas por análise documental e, se necessário, por uma visita prévia à transferência, pode converter-se numa lista de verificação no software. Contudo, o sistema não deve por si próprio concluir esta análise como “transferência adequada”. [4]

Na utilização técnica à distância, devem registar-se que atividade foi realizada com tecnologias de informação e comunicação, o método utilizado, os participantes, a duração, a segurança da ligação, o acesso às evidências e o lugar no plano. A IAF MD 4:2023 apresenta um quadro para a utilização de TIC em fins de auditoria/avaliação. Uma entrevista que pode ser feita à distância e um processo que tem de ser visto no local não são a mesma coisa; o limite do programa e do risco deve ser preservado no planeamento autorizado. [5]

Porque é que o processo não termina quando o certificado é emitido?

O certificado é apenas um resultado do ciclo de três anos; a vigilância, a alteração de âmbito, a suspensão, a retirada, a recertificação e os registos de verificação prolongam o ciclo de vida.

Na ficha do certificado, o âmbito, a norma, o local, a validade, a decisão, a primeira emissão e as informações de revisão devem ser separados. Enquanto o PDF do documento é guardado como resultado imutável, uma correção ou alteração de âmbito deve gerar uma nova versão. O portal do cliente deve mostrar o documento atual; o utilizador interno deve poder ver porquê e quando as versões anteriores mudaram.

Segundo o anúncio da TÜRKAK de 2 de dezembro de 2024, a infraestrutura TBDS foi alargada para abranger o acompanhamento das informações de auditoria e, a partir de 1 de janeiro de 2025, os organismos de certificação de sistemas de gestão acreditados pela TÜRKAK ficaram obrigados a introduzir no sistema as informações da certificação inicial, da vigilância, da renovação do certificado e das outras auditorias. Isto torna importante a correspondência entre o registo interno e os campos de notificação oficial; mas o estado “enviado” no software não deve ser considerado bem-sucedido sem a resposta técnica real do serviço e o número de referência. [6]

Como se vê um registo digital defensável numa auditoria?

O registo defensável mostra em conjunto não apenas o PDF final, mas a entrada, a versão, quem fez a operação, a hora, a justificação, a aprovação e o valor anterior.

• Versão: As alterações de candidatura, cálculo, plano, relatório, não conformidade e certificado não sobrescrevem os dados anteriores.
• Separação de papéis: Vendas, planeamento, auditor, revisor técnico, responsável pela decisão e gestor têm conjuntos de permissões diferentes.
• Ligação a evidências: Cada não conformidade liga-se ao requisito aplicável e à evidência de verificação; cada decisão, à versão do processo utilizada.
• Justificação de exceção: Uma alteração de duração, equipa, data ou âmbito não é uma nota livre; produz um registo aprovado por autoridade competente.
• Evidência de notificação: A entrega por e-mail ou portal baseia-se não apenas no botão de envio, mas no resultado técnico e na hora de entrega.
• Registo de acessos: A visualização, descarrega e alteração de conteúdo crítico são monitorizadas com limite de cliente e de papel.

A ISO 19011:2026 oferece orientação atual sobre princípios de auditoria, gestão de programas de auditoria e competência dos auditores; a página oficial da ISO declara também explicitamente que esta norma, por si só, não conduz à certificação. No desenho do software pode tirar-se proveito desta orientação para a gestão de programas e a disciplina de auditoria, mas não pode substituir os requisitos de certificação por terceira parte. [7]

Como fazer a transição para um software de certificação de sistemas?

A transição mais segura é primeiro mapear o processo real e as autoridades, depois fazer um piloto num único programa e alargar de forma controlada o modelo validado.

1. Decomponha o processo atual nos seus elementos

Retire o formulário de candidatura, a folha de cálculo, a proposta, o processo do auditor, o plano, o relatório, as não conformidades, a ata de decisão, o certificado e os registos de notificação. Determine em que ficheiros a mesma informação se repete, qual é aceite como fonte e quem a pode alterar.

2. Faça um piloto com um único programa e um grupo limitado de clientes

Escolha não a exceção mais complexa, mas um âmbito gerível que represente o processo real. O critério de sucesso do piloto não deve ser apenas a velocidade de operação; devem medir-se também os dados em falta, a razão das replaneações, os avisos de atribuição errada de equipa, a visibilidade das não conformidades abertas e o acesso ao processo de decisão.

3. Valide as integrações com evidências

Nas ligações a ERP/CRM, e-mail, assinatura eletrónica, TBDS ou portal do cliente, não se deve testar apenas o cenário de sucesso. Os cenários de reenvio, erro de autorização, interrupção do serviço, transferência parcial e correção devem ser tratados sem produzir perda de registos.

4. Faça o versionamento de regras e normas

Quando mudar um documento do IAF, uma regra de programa, uma norma ou um procedimento da entidade, deve determinar-se com que versão continuam os processos abertos. O processo antigo não deve ser reescrito com o cálculo de hoje; a regra da época deve permanecer visível.

Quais são os erros de desenho mais frequentes?

Os erros mais comuns são tomar o estado do CRM como decisão técnica, reduzir a competência à disponibilidade no calendário e alterar registos aprovados sem preservar o histórico.

• Forçar todas as normas para o mesmo fluxo de trabalho: Pode construir-se uma espinha dorsal comum; as diferenças de programa e de documentos normativos devem permanecer num conjunto de regras separado.
• Fornecer a duração da auditoria com uma fórmula oculta: O utilizador deve poder ver a entrada, a versão da regra, o fator de correção e a justificação.
• Automatizar a decisão técnica: O sistema pode sinalizar lacunas; a decisão de certificação deve ser uma avaliação humana autorizada e rastreável.
• Tornar o PDF do certificado o registo principal: O PDF é um resultado; não substitui os dados de decisão, âmbito, local, versão e ciclo.
• Assumir o resultado da integração: O envio para o TBDS, e-mail ou portal deve ser confirmado com a resposta técnica real.
• Apagar o processo anterior: A revisão não deve eliminar a relação com a evidência e a decisões anteriores.

Como é que o Vizyon Alia suporta este fluxo?

O Vizyon Alia é configurado para gerir o processo de certificação numa única espinha dorsal de processo, desde a candidatura e a proposta até ao planeamento dos auditores, e desde os registos de local/auditoria até à decisão e ao ciclo do certificado.

Página da solução Vizyon Alia pode conhecer a abordagem por módulos através de na página do serviço de software de certificação pode ver as opções de processo e de integração. Na implementação, em vez de copiar diretamente os formulários e procedimentos existentes, as regras de âmbito, papel, decisão, versão e integração devem ser validadas juntamente com o funcionamento real da organização.

Preparar antes da demonstração uma candidatura anonimizada, um cálculo real de duração de auditoria, uma matriz de competências, um exemplo de não conformidade e um cenário de revisão de certificado torna o resultado concreto. Ao planear a análise do processo com a VizyonTech pode estabelecer-se um fluxo piloto ponta a ponta a partir destes cinco exemplos.

Perguntas frequentes