El núcleo común de requisitos de seguridad de todos los marcos
Si se cruzan once marcos de seguridad, aparece un núcleo pequeño presente en todos ellos. Si está empezando un programa o gestionando varios marcos a la vez, ese núcleo es el punto de partida.
Esta entrada cubre los 11 marcos que ControlMapping había asignado cuando se redactó. Desde entonces, se añadieron DORA, CPS 234, Cyber Essentials el 2026-10-27; sus páginas y la matriz de cobertura ya los incluyen.
Las organizaciones rara vez responden a un solo marco de seguridad. Una empresa de software vende a clientes estadounidenses que quieren un informe SOC 2 y a clientes europeos que piden ISO 27001; un proveedor de pagos añade PCI DSS; un proveedor digital de la UE ahora queda sujeto a NIS2. Cada marco llega con su propia estructura, numeración y vocabulario, y es fácil concluir que cada uno exige un programa distinto.
No es así. Bajo la numeración distinta hay mucho terreno común, y una parte pequeña es compartida por todos los marcos que cruzamos. Buscamos los temas que tienen un requisito asignado en los once: NIST CSF 2.0, NIST SP 800-53, ISO 27001, CIS Controls, SOC 2, PCI DSS, CMMC Level 2, la Regla de Seguridad de HIPAA, RGPD [GDPR], NIS2 y las Essential Eight de ASD.
Los cinco temas presentes en todos los marcos
5 de 50 temas tienen un requisito asignado en todos los 11 marcos. Cada página de tema enumera los identificadores de requisito de cada marco y la evidencia de cada vínculo.
Ese es el núcleo común: gestión de activos, gestión de vulnerabilidades, copias de seguridad y recuperación, respuesta a incidentes y notificación de incidentes. Cada uno de los once marcos tiene al menos un requisito en cada uno de ellos, incluso el RGPD, que es una ley de privacidad, y las Essential Eight, que son una lista breve de medidas técnicas de mitigación.
Es una lista breve a propósito. Muchos otros temas, como el control de acceso, el registro de eventos y el cifrado, están cubiertos por diez de los once, y la mayoría de los marcos comparten bastantes más de cinco temas. Pero estos cinco son los que ningún marco omite.
Por qué estos cinco
Siguen el ciclo de vida de un incidente. No se puede proteger lo que no se sabe que se tiene (gestión de activos). La mayoría de los ataques siguen explotando debilidades conocidas (gestión de vulnerabilidades). Cuando algo sale mal, hay que restaurar sistemas y datos (copias de seguridad y recuperación), gestionar el incidente (respuesta a incidentes) e informar a quienes necesitan saberlo: la dirección, los clientes y los reguladores (notificación de incidentes).
Los marcos discrepan en casi todo lo demás: si la gobernanza es un sistema de gestión o un conjunto de resultados, cuán prescriptivos deben ser los controles técnicos y con qué frecuencia deben ocurrir las cosas. En estos cinco coinciden, porque sin ellos el resto no funciona.
Mismo tema, distinta profundidad
Un tema compartido no significa un requisito idéntico. Tomemos la gestión de vulnerabilidades:
| Marco | Gestión de vulnerabilidades | Vínculo |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01ID.RA-08 | Definición del tema |
| ISO 27001 | A.8.8 | Correspondencia |
| CIS v8.1 | CIS 7.1CIS 7.2CIS 7.5CIS 7.6CIS 7.7CIS 16.6CIS 18.1CIS 18.2CIS 18.3CIS 18.4CIS 18.5 | Correspondencia |
| SOC 2 | CC7.1 | Editorial |
| PCI DSS | 6.3.111.3.111.3.2 | Correspondencia |
| CMMC | RA.L2-3.11.2RA.L2-3.11.3 | Correspondencia |
| 800-53 | RA-5CA-8 | Correspondencia |
| HIPAA | §164.308(a)(1)(ii)(A)§164.308(a)(1)(ii)(B)§164.308(a)(8) | Correspondencia |
| GDPR | Art.32(1)(d) | Editorial |
| NIS2 | 6.56.10 | Correspondencia |
| Essential Eight | ISM-1807ISM-1808ISM-1698ISM-1699ISM-1701ISM-1702 | Editorial |
Detalle completo y motivo de cada vínculo: Gestión de vulnerabilidades en todos los marcos →
El A.8.8 de ISO 27001 pide obtener información sobre vulnerabilidades técnicas, evaluar la exposición y tomar las medidas adecuadas, y deja el plazo a su evaluación de riesgos. PCI DSS exige análisis internos cada tres meses y tras cambios significativos (11.3.1), análisis externos por un proveedor certificado de escaneo (Approved Scanning Vendor) (11.3.2), y parches de severidad crítica y alta en el plazo de un mes desde su publicación (6.3.3). Las Essential Eight fijan plazos de parcheo que se endurecen en cada nivel de madurez. HIPAA aborda el tema a través de sus requisitos de análisis y gestión de riesgos, en lugar de uno específico sobre vulnerabilidades.
Así, el núcleo común indica qué espera cada marco que haga, no cuánto. Al diseñar un control, diséñelo para el marco más estricto al que responde, y los demás normalmente se alinearán.
Cómo se ve en la práctica
- Gestión de activos: un inventario único de hardware, software, servicios en la nube y almacenes de datos, con responsables, mantenido al día mediante herramientas de descubrimiento y no solo con hojas de cálculo.
- Gestión de vulnerabilidades: análisis programados (internos y externos), una clasificación de severidad, plazos de remediación según la severidad y evidencia de que se cumplen.
- Copias de seguridad y recuperación: copias de datos, software y configuración, protegidas frente a cambios y borrados, con restauraciones probadas según un calendario.
- Respuesta a incidentes: un plan escrito con roles, niveles de severidad y escalado, ejercitado al menos una vez al año.
- Notificación de incidentes: un procedimiento que indique quién debe ser informado, en qué plazo y por quién: la dirección interna, los clientes con contrato y los reguladores (por ejemplo, la alerta temprana de 24 horas de NIS2 o la notificación de 72 horas del RGPD a la autoridad de control).
Por qué importa el núcleo
Si está iniciando un programa de seguridad, construya primero estos cinco. Son los requisitos que encontrará en cualquier marco que pueda adoptar después, así que el trabajo nunca se desperdicia.
Si ya gestiona varios marcos, use el núcleo como base de un conjunto común de controles: un control por cada uno de estos temas, correspondido con cada marco al que responde, y con las evidencias recogidas una sola vez. La misma idea se extiende a los temas compartidos por diez, nueve u ocho marcos. Nuestra matriz de cobertura muestra los cincuenta temas frente a los once marcos, y el análisis de brechas muestra, requisito por requisito, qué se traslada entre dos cualesquiera.
Cómo lo medimos
Cada tema en ControlMapping se define por los resultados de NIST CSF 2.0 y enumera el requisito de cada marco que lo aborda. Un vínculo se etiqueta como Correspondencia cuando una correspondencia publicada (de NIST, ENISA, CIS o PCI SSC) lo respalda, y como Editorial cuando es nuestro criterio, con el motivo indicado. Los vínculos de SOC 2, RGPD y Essential Eight son siempre Editorial, porque no existe una correspondencia de licencia abierta para ellos. La metodología completa está en la página de metodología, y todas las cifras anteriores proceden de los datos en vivo, así que se actualizan cuando cambian las correspondencias.
Preguntas
¿Qué controles de seguridad exigen todos los marcos?
En los datos de ControlMapping, cinco temas tienen un requisito asignado en los 11 marcos: gestión de activos, gestión de vulnerabilidades, copias de seguridad y recuperación, respuesta a incidentes y notificación de incidentes. La redacción exacta y la profundidad varían según el marco.
¿Cumplir la versión de un marco satisface a los demás?
No automáticamente. Una correspondencia significa que los requisitos abordan el mismo tema; uno puede ser mucho más específico (PCI DSS y las Essential Eight fijan plazos y frecuencias que ISO 27001 deja a su criterio). Revise el texto de cada marco.
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 · 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
Análisis · 2026-10-27APRA CPS 234 y ISO 27001: qué cubre su SGSI y qué añade APRAUn SGSI conforme a ISO 27001 cubre casi todos los párrafos de la CPS 234 de APRA, pero APRA añade obligaciones del consejo de administración, garantías de terceros y plazos estrictos de notificación.
Análisis · 2026-10-27Cyber Essentials frente a Essential Eight: dos referencias nacionales comparadasEl Cyber Essentials del Reino Unido y el Essential Eight de Australia persiguen ambos los ataques más comunes, pero cubren terrenos distintos. Qué se solapa, qué no y por qué.
Análisis · 2026-10-27DORA frente a NIS2: qué cubre ya un programa NIS2DORA y NIS2 comparten casi todo su contenido de seguridad; DORA añade registro, cláusulas y pruebas basadas en amenazas. Qué se traslada, artículo por artículo.