Cómo realizar un análisis de brechas entre dos marcos y convertirlo en un registro de seguimiento

Todo segundo marco empieza con la misma pregunta: ¿cuánto de esto ya tenemos? Un análisis de brechas responde a ella. Mal hecho, produce una hoja de cálculo que indica "parcialmente conforme" en todo y nunca se vuelve a abrir. Bien hecho, produce una lista de tareas con costes y responsables. Este es el método que usaríamos.

Paso 1: fijar el alcance y la dirección

Un análisis de brechas tiene una dirección: tener un marco (o sus controles actuales) y necesitar otro. Anótelos ambos, con sus versiones, y el alcance organizativo: qué entidad, servicios y ubicaciones. Los análisis de brechas fallan con más frecuencia cuando los dos alcances no coinciden; por ejemplo, un certificado ISO que cubre una línea de producto comparado con una obligación NIS2 para toda la entidad.

Paso 2: generar la comparación requisito por requisito

Parta de una correspondencia, no de una hoja en blanco. El análisis de brechas de ControlMapping enumera cada requisito del marco que necesita, cada uno con su equivalente en el que ya tiene:

• Con correspondencia: una correspondencia publicada o nuestro criterio editorial lo vincula con algo que usted tiene.
• Relación tangencial: solo comparte un resultado con algo que usted tiene. Considérelo probablemente trabajo nuevo.
• Sin correspondencia en nuestros datos: probablemente trabajo nuevo, salvo que la cobertura de ese marco sea parcial.

Por ejemplo, al pasar de ISO 27001 a NIS2:

De los 49 puntos de requisito de NIS2, 49 (100%) se corresponden con algo en ISO 27001, 0 solo guardan una relación tangencial y 0 no tienen correspondencia en nuestros datos. Abrir el informe de brechas →

Paso 3: validar las correspondencias frente a la realidad

Una correspondencia indica que dos requisitos están relacionados. No indica que su implementación cumpla ambos. Para cada fila con correspondencia, pregúntese:

1. ¿Realmente hacemos lo que hemos vinculado? Una correspondencia con ISO A.8.8 solo es útil si su gestión de vulnerabilidades funciona.
2. ¿El nuevo requisito es más específico? Plazos, frecuencias, técnicas concretas y alcance suelen diferir.
3. ¿El vínculo es editorial? Revise la razón mostrada y decida si está de acuerdo.

Marque cada fila como cumplido, parcialmente cumplido o no cumplido. Sea honesto: un análisis de brechas demasiado optimista solo traslada el hallazgo a la auditoría.

Paso 4: exportarlo como registro de seguimiento

Pulse e en la vista de brechas (o el botón Exportar CSV) para descargar el resultado. Cada fila incluye el requisito, su sección, la correspondencia, la base y la razón, además de cuatro columnas vacías para el trabajo: responsable, estado de implementación, referencia de evidencia y notas. Ábralo en su hoja de cálculo o impórtelo en su herramienta GRC.

Paso 5: convertir las filas en trabajo

• Agrupe por responsable y tema, no por número de requisito: "contratos con proveedores" es una tarea que puede cerrar seis filas.
• Estime cada grupo y secuéncielo: los cambios de gobernanza y de políticas suelen desbloquear el trabajo técnico.
• Complete la columna de evidencias a medida que avanza, para que el registro se convierta en su expediente de auditoría.
• Repita el análisis cuando cambie cualquiera de los dos marcos; el nuestro se actualiza cuando lo hacen los datos.

Puntos clave

• Fije primero el alcance y la dirección: tener A, necesitar B, con versiones.
• Parta de una correspondencia y, después, valide cada una frente a lo que realmente hace.
• Exporte el resultado como registro de seguimiento con columnas de responsables, estado y evidencias, y convierta las filas en trabajo agrupado.

Errores frecuentes

• Comparar con una versión sustituida (CSF 1.1, ISO 27001:2013, PCI DSS v3.2.1).
• Tratar la "relación tangencial" como cubierta.
• Ignorar por completo los requisitos fuera de la correspondencia: las obligaciones legales, como los plazos de notificación de incidentes, a menudo no aparecen en ningún catálogo de controles.

Para ejemplos trabajados, consulte ISO 27001 frente a NIS2 punto por punto y las comparativas, cada una de las cuales es un análisis de brechas bidireccional ya preparado.

Preguntas

¿Qué es un análisis de brechas de cumplimiento?

Una comparación requisito por requisito entre lo que ya hace (o el marco que ya cumple) y los requisitos de un marco que necesita, que identifica qué está cubierto, qué está parcialmente cubierto y qué falta.

¿Cuánto tiempo lleva un análisis de brechas?

La correspondencia puede generarse en minutos con una herramienta como el análisis de brechas de ControlMapping. Validarla frente a sus controles y evidencias reales es el trabajo importante, que normalmente lleva de días a unas pocas semanas según el alcance.

¿Qué significa 'relación tangencial' en un análisis de brechas?

Los dos requisitos solo comparten un resultado de NIST CSF 2.0; nadie los ha asignado entre sí. Trátelos como una pista que hay que comprobar y, normalmente, como trabajo nuevo, no como cobertura.