cm/controlmapping
Español
Fuentes
Guía práctica · ISO 27001 · NIS2 · SOC 2

Del informe de brechas al plan de proyecto: responsables, evidencias y plazos

Un análisis de brechas indica qué falta, pero no qué hacer el lunes. Aquí explicamos cómo convertir una lista de requisitos no cumplidos en un plan que el equipo pueda ejecutar.

Impresión estilo risografía de una línea de tiempo horizontal con bloques de distinta longitud dispuestos en carriles sobre ella
Las brechas se convierten en flujos de trabajo, y los flujos de trabajo en una línea de tiempo.

Realizar un análisis de brechas es la parte fácil. Nuestra guía paso a paso le lleva a un tracker con todos los requisitos no cumplidos enumerados. Lo que ocurre después determina si el programa sale adelante: demasiados trackers se quedan en largas hojas de cálculo con filas marcadas como «no cumplido» que nadie asume.

Paso 1: agrupar las filas en flujos de trabajo

Los requisitos están numerados según la lógica del marco, no según la suya. Reagrupe las filas no cumplidas según qué las corregirá:

  • Gobierno y políticas (alcance, roles, políticas, aprobación de la dirección)
  • Identidad y acceso
  • Gestión de vulnerabilidades y parches
  • Registro y monitorización
  • Respuesta a incidentes y notificación
  • Gestión de proveedores
  • Continuidad de negocio y copias de seguridad
  • Desarrollo seguro
  • Seguridad física

Un flujo de trabajo suele cerrar diez o veinte filas. Incluir requisitos de seguridad para proveedores en los contratos, por ejemplo, puede satisfacer a la vez requisitos de ISO 27001, PCI DSS, GDPR y NIS2.

Paso 2: secuenciar según dependencias y riesgo

  1. Desbloqueadores primero: alcance, gobierno, políticas y evaluación de riesgos. El trabajo técnico sin ellos se rehace.
  2. Brechas de alto riesgo después: sistemas expuestos sin MFA, servicios accesibles desde internet sin parchear, copias de seguridad sin probar.
  3. Después el resto, con la documentación y la recopilación de evidencias ejecutándose en paralelo, no al final.
Fotografía de un tablón de corcho con columnas de fichas en blanco unidas por cuerda roja entre chinchetas
Las dependencias importan más que el orden de los números de requisito.

Paso 3: estimar con realismo

Para cada flujo de trabajo: el trabajo, quién lo realiza, cuánto tiempo lleva y cuánto cuesta (personas, herramientas, ayuda externa). Los costes ocultos suelen estar en mantener el control después (una revisión trimestral son cuatro reuniones al año, indefinidamente), no en implantarlo.

Paso 4: asignar responsables que vayan a operar el control

El responsable de una tarea de corrección debe ser la persona que operará el control después: el responsable de TI para los parches, compras para los contratos con proveedores, RRHH para la verificación de antecedentes. El responsable de cumplimiento coordina, revisa las evidencias e informa del progreso, pero no puede asumirlo todo.

Paso 5: definir «terminado» como evidencia

Una tarea está terminada cuando el control opera y genera evidencias: la primera revisión de accesos firmada, la primera prueba de restauración registrada, la política aprobada y comunicada. Incluya la referencia de la evidencia en el tracker a medida que avanza; en el momento de la auditoría, el tracker es su índice de evidencias.

Un ejemplo práctico

Supongamos que una empresa certificada en ISO 27001 necesita cumplir NIS2. El informe de brechas ISO 27001 → NIS2 relaciona cada punto de NIS2 con algo en ISO, pero la validación frente a la realidad detecta una docena de puntos solo parcialmente cumplidos. Agrupados por corrección, se reducen a cuatro flujos de trabajo:

  • Gobierno: aprobación por la dirección de las medidas y formación de la dirección (una sesión del consejo, un curso de formación, registrados).
  • Notificación: un procedimiento de incidentes significativos con plazos de 24 y 72 horas, plantillas y un ejercicio.
  • Proveedores: criterios de selección, cláusulas contractuales y una revisión de los veinte proveedores principales.
  • Profundidad técnica: divulgación de vulnerabilidades, una política criptográfica y métricas de eficacia.

Cuatro responsables, cuatro planes, cada uno con una fecha y una lista de evidencias, en lugar de una docena de filas sin relación. Gobierno y notificación van primero porque las autoridades de supervisión preguntarán por ellos en primer lugar; la profundidad técnica sigue durante el trimestre siguiente.

Puntos clave

  • Reagrupe los requisitos no cumplidos según lo que los corregirá, no según su número de requisito.
  • Haga primero gobierno, alcance y políticas; desbloquean todo lo demás.
  • Asigne a cada flujo de trabajo un responsable que opere el control después.
  • Defina «terminado» como un control que opera y genera evidencias.

Paso 6: informar del progreso de forma sencilla

La dirección quiere tres cifras: requisitos cumplidos, en curso y no iniciados, por flujo de trabajo, más los riesgos con retraso. Repita el análisis de brechas periódicamente; cuando se calcula a partir de datos en vivo, como ocurre con el nuestro, las cifras de cobertura cambian a medida que cierra brechas y cambian los marcos.

Para el punto de partida, ejecute el análisis de brechas entre el marco que tiene y el que necesita, y expórtelo. Las comparativas muestran los pares más habituales en ambas direcciones.

Preguntas

¿Cómo deben priorizarse las brechas de cumplimiento?

Por riesgo y dependencia: primero las brechas que bloquean a otras (gobierno, alcance, políticas), después las brechas técnicas de alto riesgo y luego la documentación y las evidencias. La numeración de los requisitos es una guía deficiente para el orden.

¿Quién debe asumir las tareas de corrección del cumplimiento?

Las personas que operarán el control después, no el equipo de cumplimiento. Cumplimiento coordina y revisa las evidencias; los responsables de los controles ejecutan.

¿Qué nivel de detalle debe tener un plan de proyecto de cumplimiento?

Suficiente para que cada flujo de trabajo tenga un responsable, un entregable, una fecha y una lista de evidencias. El detalle a nivel de requisito pertenece al tracker; el plan debería caber en una o dos páginas.

Datos a fecha de 2026-10-27: las cifras de esta entrada se calculan a partir de la correspondencia vigente y se actualizan cuando esta cambia. Correspondencia una tabla de correspondencias publicada (NIST, ENISA, CIS, PCI SSC) establece la relación · Editorial Criterio editorial de ControlMapping cuando no existe crosswalk; se muestra el motivo · Relación tangencial solo comparte un resultado de CSF 2.0: conviene revisarlo, no es una asignación · Sin correspondencia en nuestros datos no hay nada asignado en nuestros datos; a menudo es trabajo nuevo, pero revisa las notas de cobertura. No es asesoramiento de cumplimiento.

Artículos relacionados