Como preservar o histórico de revisão e aprovação de documentos na gestão da qualidade?

Como preservar o histórico de revisão de documentos?

Abra cada revisão como nova versão sob uma identidade de documento imutável; guarde sem eliminar o conteúdo anterior, a justificação da alteração, os revisores, a decisão de aprovação, a data de entrada em vigor e o trilho de distribuição.

O objetivo não é apenas arquivar o ficheiro antigo. O sistema deve conseguir reconstituir que versão estava em vigor numa data de operação específica e por quem e com que prova essa versão foi aprovada.

Porque separar documento controlado e registo?

Resposta curta: o documento descreve como o trabalho deve ser feito e pode ser revisto; o registo prova o resultado do trabalho feito e o seu histórico não deve ser alterado retroativamente.

Políticas, procedimentos, instruções, modelos e formulários em branco podem ser documentos controlados. Um formulário de controlo preenchido, uma decisão de aprovação ou uma presença em formação são um registo. Ainda que possam ser mantidos na mesma área de ficheiros, os seus estados, autorizações e regras de conservação não devem ser os mesmos.

A ISO 10013:2021 oferece orientação para desenvolver e manter informação documentada que suporte um sistema de gestão da qualidade eficaz, de acordo com a necessidade da organização. Isto significa que, em vez de copiar uma única hierarquia de pastas ou de documentos para todas as organizações, o controlo deve ser alinhado com os processos e o risco.

Como constituir o modelo de identidade e versão do documento?

Separe a identidade imutável do número de versão. Por exemplo, mantendo-se a identidade do documento, as revisões 03, 04 e 05 são objetos distintos; o novo ficheiro não é escrito por cima da linha antiga.

• Núcleo do documento: identidade única, nome, tipo, processo, função de responsável e classe de confidencialidade.
• Registo de versão: revisão, hora de criação, resumo da alteração, resumo do ficheiro de origem e ligação à versão anterior.
• Registo de decisão: revisor, aprovador, momento da decisão, função/autoridade e, se existir, justificação da rejeição.
• Registo de vigência: data de início, pontos de utilização, trabalhos em aberto afetados e motivo da cessação de vigência.
• Registo de distribuição: quem ou que função viu, por que canal acedeu, a cópia controlada antiga foi recolhida?

O nome do ficheiro pode ser cómodo, mas não é identidade única. Quando o ficheiro é renomeado ou convertido para outro formato, a ligação documento-versão-aprovação não deve perder-se.

Que portas deve conter o fluxo de análise e aprovação?

Resposta curta: o autor, o revisor técnico e quem tem autoridade para pôr em vigor devem ser explícitos; o processo não deve fechar-se com justificação em falta ou decisão não autorizada.

1. Rascunho: o responsável pelo documento regista o âmbito e a justificação da alteração.
2. Análise de impacto: avaliam-se formulários ligados, formações, trabalhos em aberto, contratos e requisitos externos.
3. Revisão técnica: a função autorizada verifica a exatidão e a aplicabilidade do conteúdo.
4. Aprovação: quem decide liga o registo da decisão ao valor de resumo do ficheiro que lhe foi apresentado.
5. Entrada em vigor: a versão aprovada torna-se selecionável na data definida; a versão antiga fecha-se a novos trabalhos.
6. Distribuição e leitura: as funções afetadas são informadas; se necessário, a utilização não é aberta sem prova de formação ou de aptidão concluída.

Não incorpore no software, como regra universal, que o autor e o aprovador tenham obrigatoriamente de ser pessoas diferentes em todas as situações. A separação de funções deve ser definida pela norma aplicável, pela avaliação de risco da entidade, pela matriz de autoridade e pelas condições contratuais. O sistema deve aplicar a regra escolhida de forma consistente e não deixar passar exceções sem justificação.

Como impedir a utilização da versão antiga?

Apenas colocar a etiqueta “inválido” não chega. Ao iniciar uma nova ordem de trabalho, criação de formulário ou tarefa de campo, o sistema deve apresentar apenas a versão adequada segundo a data de vigência e o contexto do processo.

A estrutura comum dos sistemas de gestão da ISO, com data de 1 de julho de 2026, exige que a informação documentada seja adequada ao uso e acessível onde necessário; e que seja protegida contra utilização indevida ou perda de integridade. O mesmo texto aborda também a identificação e o controlo dos documentos de origem externa considerados necessários. O equivalente VizyonTech são as seguintes portas técnicas:

• Não permitir a seleção de um modelo caducado numa nova operação.
• Fixe com que versão começaram os trabalhos em aberto; quando a versão mudar, abra automaticamente uma tarefa de impacto.
• Ligue à cópia controlada descarregada a versão e o momento da descarrega; separe claramente a cópia não controlada.
• Se o equipamento de campo estiver offline, valide a versão válida antes da sincronização; em estado indeterminado, não inicie nova operação.
• Quando uma norma externa ou caderno de encargos do cliente for atualizado, encontre por relação os procedimentos, formulários e formações afetados.

Que eventos deve manter o histórico de aprovação e o trilho de operação?

Apenas o campo “último a atualizar” é insuficiente para auditoria. Criação, carregamento, comparação, envio para análise, rejeição, reenvio, aprovação, entrada em vigor, descarrega, distribuição e alteração de autoridade devem ser eventos separados.

A NIST SP 800-92 encara a gestão robusta de registos não apenas como produzir registos, mas como estabelecer a infraestrutura de registos e geri-los de forma regular. Por isso, o evento de aprovação e o trilho de auditoria devem ser mantidos separados mas relacionados; o administrador da aplicação não deve poder editar o histórico silenciosamente e os acessos aos registos também devem ser restringidos.

Como gerir o acesso, a cópia de segurança e a conservação?

Proteger o histórico de aprovação não significa abri-lo a todos. Conceda acesso baseado em funções e âmbitos, segundo a classe de conteúdo, dados pessoais, informação de cliente e segredo comercial.

A declaração oficial de segurança de dados da KVKK sublinha que as medidas devem ser adequadas à atividade e à estrutura do responsável pelos dados e ao risco dos dados protegidos; à prevenção do acesso ilícito e à conservação dos dados. O equivalente técnico é a operação conjunta da matriz de autoridade, do registo de acessos, da cópia de segurança, do teste de restauro e da política de conservação/destruição.

• Não considere a mensagem “cópia de segurança efetuada” como sucesso; restaure uma cadeia de documentos de amostra e valide as relações.
• Não copie um único número de prazo de conservação para todos os documentos; ligue-o à finalidade, ao contrato e à legislação aplicável.
• Se existir retenção legal ou contratual, interrompa de forma controlada o fluxo normal de destruição.
• Não elimine o registo de aprovação antigo de um utilizador cuja autoridade foi retirada; desative a conta e preserve a identidade histórica.

Que cenários devem ser testados no piloto VizyonTech?

Vizyon Periyodik ou ao avaliar o fluxo de qualidade VizyonTech adaptado à sua organização, faça um piloto completo de um único procedimento real e da família de formulários a ele ligada.

• Envie para aprovação sem justificação da alteração; o fluxo deve parar.
• Tente a aprovação com um utilizador não autorizado; não deve formar-se decisão.
• Altere o ficheiro submetido à aprovação no último momento; a aprovação anterior deve ficar inválida e deve ser pedida nova análise.
• Abra um novo trabalho com a versão antiga do formulário; o sistema deve bloquear a seleção.
• Atualize um documento de origem externa; deve formar-se uma tarefa de impacto para os procedimentos e formações ligados.
• Faça restauro a partir da cópia de segurança; as relações entre documento, versão, aprovação e distribuição devem ser validadas em conjunto.

O critério de sucesso do piloto não é a possibilidade de carregar documentos. É o sistema fechar-se perante prova indeterminada ou em falta, preservar o histórico e permitir ao auditor reconstruir, a partir de uma única cadeia, a versão válida numa data específica. Para o ciclo de vida diferente de um relatório de inspeção assinado, consulte o guia de versão e trilho de operação na revisão de relatórios com assinatura eletrónica , que pode consultar.