¿Cómo funciona un software de certificación de sistemas? Proceso digital de la solicitud al certificado

¿Qué gestiona un software de certificación de sistemas?

Un software de certificación de sistemas gestiona en el mismo expediente trazable la solicitud, la revisión del alcance, la duración de la auditoría, la competencia de los auditores, los registros de Fase 1 y Fase 2, los hallazgos, la revisión independiente, la decisión, el certificado y el ciclo de vigilancia.

El valor aquí es mayor que trasladar un formulario en papel a la pantalla. El organismo de certificación debe poder mostrar, para cada cliente, qué información se obtuvo cuándo, con qué entradas se construyó el plan, qué evidencias de auditoría respaldaron qué hallazgo y a través de qué registro autorizado se tomó la decisión. El software hace visible esta cadena; no asume la responsabilidad técnica, la obligación de imparcialidad ni la decisión autorizada del organismo de certificación.

¿Cómo debe construirse la columna vertebral del expediente digital?

Una columna vertebral sólida no centra el registro del cliente, sino las evidencias de decisión encadenadas y versionadas desde el alcance de la solicitud hasta el ciclo del certificado.

ISO/IEC 17021-1:2015 define los principios y requisitos para la competencia, coherencia e imparcialidad de los organismos que auditan y certifican sistemas de gestión. Según el resumen oficial de ISO, la certificación de sistemas de gestión es una actividad de evaluación de la conformidad por terceras partes. Por ello, una “oportunidad de venta” abierta en el CRM no es, técnicamente, una solicitud de certificación examinada. Ambos registros pueden estar vinculados; pero sus fines, autorizaciones y puertas de aprobación son distintos. [1]

¿Por qué la revisión de la solicitud no es una simple aprobación de formulario?

La revisión de la solicitud debe convertir la petición de la organización en un alcance de certificación; debe evaluar en conjunto la actividad, los emplazamientos, el personal, la norma, las reglas del programa y la suficiencia de recursos.

No basta que la pantalla de solicitud contenga solo el nombre de la empresa, el número de empleados y la elección de la norma. Información como en qué emplazamientos y turnos se realizan las actividades, si existen emplazamientos temporales o virtuales, los procesos críticos externalizados, la solicitud de sistemas integrados, el estado de certificaciones previas y la necesidad de transferencia cambia la revisión técnica. Cuando la información inicial se actualiza después, el sistema no debe borrar la respuesta antigua; debe generar una tarea de evaluación del impacto del cambio en la oferta, la duración, el equipo y el alcance.

TÜRKAK explica que los organismos de certificación de sistemas de gestión deben cumplir, junto con ISO/IEC 17021-1, los documentos de cualificación específicos de la norma de gestión correspondiente, los documentos obligatorios de IAF y los documentos aplicables de EA/TÜRKAK. Por ejemplo, los conjuntos de experiencia y documentos normativos adicionales de expedientes ISO 9001, ISO 14001, ISO/IEC 27001 o ISO 45001 no son iguales. El software no debe reducir esta diferencia a un único producto genérico de “certificado ISO”; debe gestionarla por programa y alcance. [2]

¿Cómo se vinculan la duración de la auditoría y la asignación del equipo?

Primero se hace el cálculo justificado de la duración de la auditoría; luego se planifica un equipo competente, imparcial y disponible que pueda cubrir esa duración y ese alcance.

IAF MD 5:2023 indica que en auditorías de sistemas de gestión de calidad, medio ambiente y seguridad y salud en el trabajo la duración de la auditoría inicial, como suma de Fase 1 y Fase 2, forma parte de la revisión de la solicitud. El número de personal efectivo es el punto de partida; pero no es el único factor. También se consideran variables como el riesgo o la complejidad, la estructura de emplazamientos y turnos, el idioma, la alta densidad normativa, los procesos externalizados y los emplazamientos temporales. Debe registrarse la base del resultado del cálculo y de las correcciones realizadas. [3]

Por ello, el software no debe diseñarse con el enfoque de “elige el número de personal y obtén los días”. Deben conservarse en conjunto la versión del conjunto de reglas, la instantánea de los datos de entrada, los factores de aumento/reducción, la explicación, la persona aprobadora y el motivo del recálculo. La guía de duración de auditoría IAF MD 5explica con detalle la lógica de cálculo del tema y por qué la duración base y la corrección específica de la organización deben mantenerse separadas.

En la asignación del equipo tampoco se busca solo la disponibilidad de calendario. Deben verse la cualificación sector/código del auditor, la competencia en la norma pertinente, su rol, asignaciones anteriores, la declaración de imparcialidad o conflictos de interés y, si procede, el apoyo de un experto técnico. Si no se encuentra la persona adecuada, el sistema no debe reducir ocultamente la duración ni trasladar el alcance a otro código; debe enviar la excepción de planificación a revisión autorizada.

¿Cómo avanza el registro de la Fase 1 a la decisión de certificación?

Cada fase debe cerrarse con su propio propósito y salida; el paso siguiente debe referenciar la salida aprobada de la fase anterior, y el cambio retroactivo debe generar una nueva versión.

El registro de la Fase 1 debe hacer visible el estado de preparación para la auditoría, las condiciones importantes de emplazamiento y alcance, los puntos que afectan al plan de la Fase 2 y los asuntos a seguir. En la Fase 2 se vinculan en el mismo expediente el plan de auditoría, los procesos muestreados, las entrevistas, las evidencias documentales y de aplicación, y los hallazgos. Un hallazgo no es solo texto y clase; tiene ciclo de vida con su evidencia de respaldo, el requisito aplicable, el responsable, el plazo, la corrección presentada y el resultado de la verificación.

Cuando el expediente llega a la fase de decisión, el sistema no debe pasar a la lógica de “si todas las casillas están llenas, genera el certificado automáticamente”. Es útil controlar los registros incompletos o contradictorios y ofrecer al decisor resúmenes y enlaces a las fuentes; pero el alcance, las condiciones, el motivo, la fecha y la autoridad de la decisión deben registrarse aparte. Si después cambian los datos de un hallazgo o del alcance, la decisión antigua no debe actualizarse silenciosamente; debe surgir la necesidad de reevaluación.

¿Caben los expedientes de transferencia y auditoría remota en el mismo flujo?

Puede usarse la columna vertebral común de registros; pero la revisión de transferencia y la auditoría remota deben ser escenarios separados, con sus propios controles obligatorios y campos de evidencia.

IAF MD 2:2023 define los controles mínimos para la validez del certificado, el alcance de acreditación y la revisión previa a la transferencia en la transferencia de certificados de sistemas de gestión acreditados. Que no se acepte como transferencia normal un certificado que se sabe suspendido, y que la información requerida se evalúe mediante revisión documental y, si es necesario, una visita previa a la transferencia, puede traducirse en una lista de control en el software. Pero el sistema no debe dar por sí solo el resultado de esta revisión como “transferencia adecuada”. [4]

En el uso técnico remoto deben registrarse qué actividad se realiza con tecnologías de la información y la comunicación, el método usado, los participantes, la duración, la seguridad de la conexión, el acceso a la evidencia y su lugar en el plan. IAF MD 4:2023 ofrece un marco para el uso de ICT con fines de auditoría/evaluación. Una entrevista que puede hacerse en remoto y un proceso que debe verse en el emplazamiento no son lo mismo; el límite de programa y riesgo debe preservarse en la planificación autorizada. [5]

¿Por qué el proceso no termina al publicarse el certificado?

El certificado es la única salida de un ciclo de tres años; la vigilancia, el cambio de alcance, la suspensión, la retirada, la recertificación y los registros de verificación sostienen el ciclo de vida.

En la ficha del certificado deben separarse el alcance, la norma, el emplazamiento, la validez, la decisión, la primera publicación y la información de revisión. Mientras el PDF del documento se conserva como salida inmutable, la corrección o el cambio de alcance deben producir una nueva versión. El portal del cliente debe mostrar el documento vigente; el usuario interno debe poder ver por qué y cuándo cambiaron las versiones anteriores.

Según el anuncio de TÜRKAK de 2 de diciembre de 2024, la infraestructura TBDS se amplió para cubrir el seguimiento de la información de auditorías y, desde el 1 de enero de 2025, los organismos de certificación de sistemas de gestión acreditados por TÜRKAK deben introducir en el sistema la información de la certificación inicial, la vigilancia, la renovación del certificado y demás auditorías. Esto hace importante que el registro interno coincida con los campos de notificación oficial; pero el estado “enviado” en el software no debe considerarse exitoso sin la respuesta real del servicio y el número de referencia. [6]

¿Cómo se ve un registro digital defendible en una auditoría?

El registro defendible no muestra solo el PDF final: muestra en conjunto la entrada, la versión, quién hizo la operación, la hora, el motivo, la aprobación y el valor anterior.

• Versión: Los cambios de solicitud, cálculo, plan, informe, hallazgo y certificado no sobrescriben el dato antiguo.
• Separación de roles: Ventas, planificación, auditor, revisor técnico, decisor y dirección tienen conjuntos de permisos distintos.
• Vínculo de evidencia: Cada hallazgo se vincula al requisito y a la evidencia de verificación; cada decisión, a la versión del expediente utilizada.
• Justificación de excepciones: El cambio de duración, equipo, fecha o alcance no es una nota libre: produce un registro aprobado por autoridad competente.
• Evidencia de notificación: La entrega por correo o portal se basa en el resultado técnico y la hora de entrega, no solo en pulsar enviar.
• Registro de accesos: Las visualizaciones, descargas y cambios de contenido crítico se supervisan con límite de cliente y rol.

ISO 19011:2026 ofrece orientación actualizada sobre principios de auditoría, gestión de programas de auditoría y competencia de los auditores; la página oficial de ISO aclara además que esta norma por sí sola no conduce a la certificación. En el diseño del software puede aprovecharse esta guía para la gestión de programas y la disciplina de auditoría, pero no puede sustituir los requisitos de certificación por terceras partes. [7]

¿Cómo debe hacerse la transición a un software de certificación de sistemas?

La transición más segura es extraer primero el mapa real de proceso y autorizaciones, hacer después un piloto en un único programa y expandir de forma controlada el modelo validado.

1. Descomponga el expediente actual en sus partes

Extraiga el formulario de solicitud, la hoja de cálculo, la oferta, el expediente del auditor, el plan, el informe, los hallazgos, el acta de decisión, el certificado y los registros de notificación. Determine en qué archivos se repite la misma información, cuál se acepta como fuente y quién puede modificarla.

2. Haga un piloto con un solo programa y un grupo limitado de clientes

No elija la excepción más compleja, sino un alcance manejable que represente el proceso real. El criterio de éxito del piloto no debe ser solo la velocidad de tramitación; deben medirse también los datos incompletos, el motivo de replanificaciones, los avisos de asignación errónea de equipo, la visibilidad de hallazgos abiertos y el acceso al expediente de decisión.

3. Valide las integraciones con evidencia

En las conexiones con ERP/CRM, correo electrónico, firma electrónica, TBDS o portal de clientes no debe probarse solo el escenario exitoso. Los escenarios de reenvío, error de autorización, corte del servicio, transferencia parcial y corrección deben gestionarse sin producir registros perdidos.

4. Versione las reglas y la norma

Cuando cambien un documento IAF, una regla de programa, una norma o un procedimiento institucional, debe determinarse en qué versión continuarán los trabajos abiertos. El expediente antiguo no debe reescribirse con el cálculo de hoy; la regla de la época debe permanecer visible.

¿Cuáles son los errores de diseño más frecuentes?

Los errores más comunes son tomar el estado del CRM como decisión técnica, reducir la competencia a la disponibilidad de calendario y modificar registros aprobados sin preservar el historial.

• Forzar todas las normas al mismo flujo de trabajo: Puede construirse la columna vertebral común; las diferencias de programa y documento normativo deben permanecer en un conjunto de reglas separado.
• Dar la duración de auditoría con una fórmula oculta: El usuario debe poder ver la entrada, la versión de la regla, el factor de corrección y la justificación.
• Automatizar la decisión técnica: El sistema puede señalar carencias; la decisión de certificación debe ser una evaluación humana autorizada y trazable.
• Convertir el PDF del certificado en registro maestro: El PDF es una salida; no sustituye los datos de decisión, alcance, emplazamiento, versión y ciclo.
• Asumir el resultado de la integración: El envío a TBDS, correo o portal debe verificarse con la respuesta técnica real.
• Eliminar el expediente antiguo: La revisión no debe destruir la relación con la evidencia y la decisión anteriores.

¿Cómo respalda Vizyon Alia este flujo?

Vizyon Alia se configura para gestionar el expediente de certificación en una única columna vertebral de proceso, desde la solicitud y la oferta hasta la planificación de auditores, y desde los registros de emplazamiento/auditoría hasta la decisión y el ciclo del certificado.

Página de la solución Vizyon Alia para examinar el enfoque modular, y en la página del servicio de software de certificación puede ver las opciones de proceso e integración. En la implantación, en lugar de copiar directamente los formularios y procedimientos actuales, las reglas de alcance, rol, decisión, versión e integración deben validarse junto con el funcionamiento real de la organización.

Preparar antes de la demo una solicitud anonimizada, un cálculo real de duración de auditoría, una matriz de competencias, un ejemplo de hallazgo y un escenario de revisión de certificado hace tangible el resultado. Al planificar el análisis de proceso con VizyonTech puede establecerse un flujo piloto de extremo a extremo sobre estos cinco ejemplos.

Preguntas frecuentes