No conformidades y acciones correctivas en ISO 27001

Un Sistema de Gestión de la Seguridad de la Información (SGSI) no demuestra su madurez intentando simular que jamás comete errores o que no sufre incidencias. La verdadera madurez de un SGSI se demuestra mediante su capacidad para detectar desviaciones, solucionar de inmediato sus efectos, analizar las causas profundas que las provocaron e implementar acciones que impidan su recurrencia.

Como vimos al repasar la evaluación del desempeño del SGSI y al utilizar la checklist ISO 27001 para auditar requisitos, la norma ISO/IEC 27001:2022 estructura la respuesta organizativa en la Cláusula 10 (Mejora). En la edición vigente de la norma, esta estructura se compone de dos elementos centrales:

Cláusula 10.1 — Mejora continua: Exige que la organización mejore continuamente la idoneidad, adecuación y eficacia del SGSI.
Cláusula 10.2 — No conformidades y acciones correctivas: Establece la sistemática a seguir ante cualquier incumplimiento detectado.

Qué es una no conformidad en ISO 27001 (y qué no lo es)

En el marco estandarizado de la norma ISO/IEC 27001:2022, una no conformidad (NC) se define estrictamente como el incumplimiento de un requisito especificado.

Ese requisito incumplido puede provenir de diversas fuentes dentro del marco del SGSI:

Las cláusulas de la propia norma ISO/IEC 27001:2022 (cláusulas 4 a 10).
Las directivas o políticas de seguridad internas aprobadas por la organización.
Requisitos legales, normativos o regulatorios aplicables a la empresa.
Compromisos contractuales o Acuerdos de Nivel de Servicio (SLA) firmados con clientes o terceros.
Procedimientos operativos o especificaciones técnicas del plan de tratamiento de riesgos.

Diferenciación crucial: lo que NO es automáticamente una No Conformidad

Para evitar burocracia innecesaria y el colapso del sistema de gestión, es fundamental aclarar que:

Un incidente de seguridad no es automáticamente una NC: Un ataque de phishing bloqueado por los controles desplegados demuestra que el control funcionó. Solo será NC si el incidente fue provocado por el incumplimiento de una política o procedimiento obligatorio.
Una vulnerabilidad técnica no es automáticamente una NC: La detección de un fallo de software durante un escaneo de rutina es parte del proceso operativo de gestión de parches. Solo constituirá NC si la vulnerabilidad superó los plazos de remediación fijados en la política interna.
Una recomendación u observación de auditoría no es una NC: Señala una oportunidad de optimización, no el incumplimiento demostrado de un requisito.

Corrección vs. Acción correctiva: la diferencia fundamental

Uno de los errores conceptuales más frecuentes en la gestión del SGSI es tratar las correcciones y las acciones correctivas como si fuesen sinónimos. La distinción es nítida:

Concepto	Definición y Enfoque	Ejemplo Práctico
Corrección (Solución inmediata)	Acción tomada para eliminar la no conformidad detectada o mitigar su impacto inmediato. Actúa sobre el síntoma.	Deshabilitar inmediatamente la cuenta de usuario de un exempleado que permaneció activa tras su baja.
Acción Correctiva (Tratamiento de causa)	Acción tomada para eliminar la causa raíz de la no conformidad y prevenir su reincidencia o su aparición en otras áreas. Actúa sobre el sistema.	Automatizar la integración entre la plataforma de Recursos Humanos y el directorio activo para que la baja del contrato deshabilite los accesos de forma inmediata sin intervención manual.

La corrección atiende la urgencia; la acción correctiva transforma el proceso para evitar que el fallo vuelva a producirse.

¿Qué ocurrió con la "Acción Preventiva"?

En versiones históricas de las normas ISO existía la figura separada de la acción preventiva. En la estructura de alto nivel moderna (ISO 27001:2022), el pensamiento preventivo se encuentra plenamente integrado en la gestión de riesgos y oportunidades y en la planificación del SGSI. Por tanto, no se exige un procedimiento independiente de acción preventiva.

Flujo paso a paso para gestionar una no conformidad

La gestión eficaz de una no conformidad debe seguir un ciclo estructurado de 7 fases:

Detección y Registro: Identificar la no conformidad (procedente de una auditoría interna, un incidente, una medición o una revisión por la dirección) y registrarla formalmente indicando el requisito incumplido y la evidencia objetiva.
Reacción Inmediata y Corrección: Tomar medidas inmediatas para contener el problema, mitigar consecuencias y aplicar la corrección a corto plazo.
Análisis de Causas: Investigar los factores organizativos, técnicos o de proceso que permitieron que la no conformidad ocurriera.
Evaluación de Ocurrencia en otras Áreas: Comprobar si la misma vulnerabilidad o fallo de proceso existe o podría repetirse en otros departamentos, sedes o aplicaciones.
Diseño e Implementación de la Acción Correctiva: Definir un plan de acción con responsables, plazos, recursos y cambios en controles, herramientas o información documentada del SGSI.
Verificación de Eficacia: Tras un periodo de tiempo representativo, comprobar empíricamente si la acción implementada eliminó la causa y evitó la repetición de la no conformidad.
Cierre y Actualización de Riesgos: Cerrar la no conformidad tras verificar su eficacia y, si procede, actualizar la evaluación de riesgos y la Declaración de Aplicabilidad (SoA).

Análisis de causa: herramientas y mitos sobre los "5 Porqués"

Para definir una acción correctiva válida, es indispensable determinar la causa raíz del fallo. No obstante, es un mito asumir que la norma ISO/IEC 27001 obliga a utilizar un método específico.

Las organizaciones pueden emplear la técnica que mejor se adapte a la complejidad del hallazgo:

Los 5 Porqués (5 Whys): Técnica sencilla consistente en encadenar preguntas iterativas para profundizar más allá de la causa aparente.
Diagrama de Ishikawa (Causa-Efecto / Espina de Pescado): Clasifica los factores en categorías como Procesos, Personas, Tecnología, Entorno y Gobernanza.
Análisis de Árbol de Fallos (Fault Tree Analysis): Adecuado para incidentes complejos o fallos de infraestructura técnica.

Ejemplo de análisis con los 5 Porqués

Hallazgo: Una copia de seguridad crítica falló y no pudo ser restaurada durante un ejercicio de recuperación.

1. ¿Por qué falló la restauración? Porque el archivo de backup estaba corrupto.
2. ¿Por qué estaba corrupto? Porque la tarea de copia finalizó con errores no detectados.
3. ¿Por qué no se detectaron los errores? Porque el log de alerta del software de backup no estaba integrado en el SIEM ni generaba ticket.
4. ¿Por qué no estaba integrado? Porque el servidor se desplegó mediante un script antiguo que no incluía el agente de monitorización.
5. ¿Por qué se usó un script antiguo? Porque el procedimiento de aprovisionamiento de infraestructura no se había actualizado tras el último cambio de arquitectura. (Causa Raíz)

Cómo verificar la eficacia real de una acción correctiva

Una acción correctiva no puede considerarse cerrada simplemente porque el responsable afirme haber completado la tarea o porque haya vencido la fecha limite del plan.

La Cláusula 10.2 exige revisar la eficacia de cualquier acción correctiva tomada. Esto requiere aportar pruebas objetivas de que el problema no ha reincidido tras un periodo de observación operativa (por ejemplo, 30, 60 o 90 días después de la implementación):

Tipo de Acción Correctiva	Evidencia de Implementación (Insuficiente)	Verificación de Eficacia (Requerida)
Automatización de bajas en IAM	Captura del script configurado en el servidor.	Auditoría posterior sobre la totalidad de las bajas ejecutadas durante los últimos 60 días, confirmando 0 cuentas deshabilitadas fuera del plazo fijado.
Formación en detección de phishing	Lista de asistencia al curso presencial.	Resultado de la siguiente simulación de phishing transcurridos 2 meses, demostrando la reducción de la tasa de clics por debajo del umbral objetivo.
Actualización de parches en servidores	Ticket de ejecución del parcheo manual.	Informe de escaneo de vulnerabilidades consecutivo durante 3 meses verificando que el SLA de parcheo crítico se mantiene por encima del 98%.

Ejemplos prácticos completos (Cuentas huérfanas, Backups, Proveedores)

Caso Práctico 1: Cuentas privilegiadas huérfanas

Incumplimiento: Política de control de accesos A.8.2. Se detectan 4 cuentas de administradores activos que ya no pertenecen a la empresa.

Corrección: Revocación inmediata de credenciales y bloqueo de sesiones activas.

Causa Raíz: Desconexión entre el sistema de ticketing de IT y la notificación de bajas de Recursos Humanos.

Acción Correctiva: Integración API directa entre HR y Active Directory para revocación automática en el momento del despido.

Verificación de eficacia: Muestreo mensual durante un trimestre comprobando el 100% de coincidencias de bajas en < 1 hora.

Caso Práctico 2: Evaluación de proveedores de servicios Cloud

Incumplimiento: Control de relaciones con proveedores A.5.19. Dos proveedores SaaS críticos operan sin evaluación de seguridad anual actualizada.

Corrección: Solicitud urgente de informes SOC 2 / ISO 27001 a los dos proveedores.

Causa Raíz: Ausencia de un inventario centralizado de terceros con alertas de vencimiento de auditorías.

Acción Correctiva: Implementación de un módulo GRC de gestión de proveedores con alertas automáticas 60 días antes del vencimiento del ciclo anual.

Verificación de eficacia: Comprobación transcurridos 6 meses de que el 100% de los proveedores críticos tienen sus certificaciones al día.

No conformidades repetidas y actualización de riesgos y documentos

Cuando una no conformidad reincide tras haber sido declarada como "cerrada", es una señal inequívoca de que el análisis de causas fue incompleto o la verificación de eficacia fue defectuosa.

Ante una no conformidad repetida, la organización debe proceder a:

Reabrir la acción correctiva y asignar un nivel superior de supervisión o recursos.
Revisar si el fallo revela un cambio en el perfil de amenaza o en la efectividad de los controles, procediendo a actualizar el análisis de riesgos y la Declaración de Aplicabilidad (SoA).
Modificar las políticas, procedimientos o configuraciones involucradas para reforzar las barreras organizativas o técnicas.

Mejora continua (Cláusula 10.1): evolucionar sin inventar burocracia

La Cláusula 10.1 exige la mejora continua del SGSI. La mejora continua no requiere modificar procedimientos diariamente de forma artificial; consiste en aprovechar las fuentes del propio sistema para aumentar su madurez:

Resultados de la evaluación del desempeño y cumplimiento de objetivos de seguridad.
Lecciones aprendidas tras la resolución de no conformidades e incidentes.
Conclusiones de la auditoría interna y las decisiones tomadas en la revisión por la dirección.
Automatización de controles manuales repetitivos para reducir el margen de error humano.

Plantilla modelo de registro de No Conformidad y Acción Correctiva

Modelo de Registro de No Conformidad (CAPA)

Código / ID: NC-2026-XXXX
Fecha de Detección: [DD/MM/AAAA] | Origen: [Auditoría / Medición / Incidente / Revisión]
Proceso / Área Afectada: [Nombre del proceso]
Requisito Incumplido: [Cláusula / Política / Requisito Legal / Control]
Descripción de la No Conformidad: [Detalle objetivo del incumplimiento]
Evidencia Objetiva: [Muestras, tickets, logs o registros de prueba]
Corrección Inmediata (Síntoma): [Acción tomada y fecha de ejecución]
Análisis de Causa Raíz: [Resultado de los 5 Porqués o Ishikawa]
Acción Correctiva Propuesta: [Plan detallado para eliminar la causa]
Responsable de la Acción: [Nombre / Cargo] | Fecha Límite: [DD/MM/AAAA]
Criterio de Verificación de Eficacia: [Métrica o prueba que demostrará que no se repite]
Fecha de Verificación de Eficacia: [DD/MM/AAAA] | Resultado: [Eficaz / No Eficaz]
Aprobación de Cierre: [Firma / Cargo del CISO o Autoridad Designada]

Información documentada y evidencias que debe revisar un auditor

Conforme a la Cláusula 10.2, la organización debe conservar información documentada como evidencia de:

La naturaleza de las no conformidades y cualquier acción tomada posteriormente.
Los resultados de cualquier acción correctiva y la prueba de su verificación de eficacia.

Un auditor de certificación o interno no buscará necesariamente un impreso en papel; revisará registros en herramientas GRC, tickets en plataformas de gestión (Jira, ServiceNow), actas de comité o repositorios con control de versiones. Lo crítico es demostrar la trazabilidad desde la detección hasta la comprobación de eficacia.

Métricas e indicadores clave de gestión de no conformidades

Para evaluar la salud del proceso de mejora continua, se pueden utilizar métricas de gestión como:

Número de No Conformidades abiertas vs. cerradas por ciclo de revisión.
Tiempo medio de resolución (MTTR) de acciones correctivas por nivel de severidad.
Porcentaje de acciones correctivas verificadas como eficaces en la primera revisión.
Tasa de reincidencia de no conformidades (indicador de fallos en el análisis de causa raíz).

Errores frecuentes, checklist de cierre y preguntas frecuentes (FAQs)

Errores frecuentes al gestionar acciones correctivas

Cerrar las no conformidades en cuanto se aplica la corrección inmediata: Omitir el análisis de causas y la verificación de eficacia posterior.
Asignar "error humano" como causa raíz única: Culpar al operador en lugar de analizar la falta de controles, supervisión o automatización del proceso.
Usar la formación como única acción correctiva: Asumir que impartir una charla soluciona fallos estructurales de diseño en los controles.
No actualizar el análisis de riesgos: No incorporar la información revelada por la no conformidad en la matriz de riesgos del SGSI.

Checklist de cierre de una No Conformidad

[ ] Se ha fundamentado el incumplimiento en un requisito y evidencia documentada.
[ ] Se ha aplicado la corrección inmediata para contener los efectos del problema.
[ ] Se ha investigado y documentado la causa raíz de la desviación.
[ ] Se ha verificado si el mismo fallo puede estar ocurriendo en otros procesos o ubicaciones.
[ ] Se ha implementado la acción correctiva sobre la causa.
[ ] Se ha realizado la verificación de eficacia tras un periodo operativo razonable.
[ ] Se han actualizado los registros de riesgo, políticas o procedimientos si ha sido necesario.
[ ] El cierre ha sido validado formalmente por la autoridad designada del SGSI.

Preguntas frecuentes (FAQs)

¿Existe un plazo máximo obligatorio fijado por ISO 27001 para cerrar una no conformidad?

No. La norma ISO/IEC 27001:2022 no establece plazos numéricos universales. Los plazos deben ser definidos por la propia organización en función del riesgo, la severidad del hallazgo y la complejidad de la acción correctiva.

¿Es obligatorio clasificar las no conformidades en "Mayores" y "Menores"?

La norma ISO/IEC 27001 no exige esta clasificación en su texto. Es una categorización empleada habitualmente por los organismos de certificación e inspectores de auditoría para graduar el impacto del hallazgo sobre la certificación del SGSI.

¿Qué ocurre si una acción correctiva resulta no ser eficaz tras su verificación?

El hallazgo no puede cerrarse. Debe reabrirse el proceso, reevaluar el análisis de causas, diseñar un nuevo plan de acción correctiva y programar una nueva fecha de verificación de eficacia.

Formación especializada en GRC y Gestión de SGSI

Si deseas dominar el análisis de riesgos, la gestión de auditorías, el tratamiento de no conformidades y la mejora continua en marcos corporativos reales, te recomendamos explorar nuestro curso profesional:

Ver curso: Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento

Sobre el autor: Álvaro Chirou

Consultor e instructor especializado en Ciberseguridad, ISO 27001 y Gobierno de TI. Con cientos de miles de estudiantes en Udemy, imparte formación práctica orientada a certificaciones e implementación de marcos de seguridad en empresas.