Correlacionar un conjunto de políticas con varios marcos sin reescribirlo
Las organizaciones que adoptan un segundo o tercer marco suelen reescribir sus políticas para cada uno. No hace falta: basta con estructurarlas una vez y después establecer las correspondencias.
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.
Un patrón habitual: una empresa redacta un conjunto de políticas para ISO 27001; después, un cliente pide SOC 2 y alguien compra un segundo paquete de plantillas; luego llega PCI DSS con sus propios requisitos. Tres conjuntos de políticas solapados, cada uno ligeramente desactualizado, y ninguno refleja lo que la gente hace realmente. Las políticas no tienen por qué ser específicas de cada marco. Deben ser específicas de la organización y estar correlacionadas.
Estructura: tres capas
- Una política de seguridad de la información: breve, aprobada por la dirección, que establezca los objetivos, el alcance, las responsabilidades y el compromiso. Tanto la cláusula 5.2 de ISO 27001 como el 12.1.1 de PCI DSS la exigen.
- Políticas temáticas (una docena aproximadamente): control de acceso, uso aceptable, gestión de activos, criptografía, respuesta a incidentes, continuidad de negocio, seguridad de proveedores, desarrollo seguro, gestión de vulnerabilidades y parches, registro y monitorización, seguridad física y seguridad de recursos humanos.
- Procedimientos y estándares de nivel inferior, donde se definen las frecuencias, las configuraciones y los pasos. Estos cambian con más frecuencia y no deberían requerir la aprobación de la dirección cada vez.
Incluya el detalle específico de cada marco en los procedimientos, no en las políticas: «los accesos se revisan cada seis meses» pertenece al procedimiento de revisión de accesos, donde puede figurar la frecuencia exigida por PCI DSS sin sobrecargar la política.
Correlacionar, no reescribir
Mantenga una tabla de correspondencias: una fila por cada sección de política, con los requisitos que aborda en cada marco. El tema Política de gobernanza muestra lo que espera cada marco a nivel superior:
| Marco | Política de gobernanza | Vínculo |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01GV.PO-02 | Definición del tema |
| ISO 27001 | A.5.1A.5.37Clause 5.2 | Correspondencia |
| CIS v8.1 | — | Sin correspondencia en nuestros datos |
| SOC 2 | CC5.3CC1.1 | Editorial |
| PCI DSS | 12.1.112.1.2 | Correspondencia |
| CMMC | — | Sin correspondencia en nuestros datos |
| 800-53 | PM-1PL-1 | Correspondencia |
| HIPAA | §164.316(a)§164.316(b)(2)(iii) | Correspondencia |
| GDPR | Art.24(2) | Editorial |
| NIS2 | 1.1 | Correspondencia |
| Essential Eight | — | Sin correspondencia en nuestros datos |
Detalle completo y motivo de cada vínculo: Política de gobernanza en todos los marcos →
Cuando llegue un nuevo marco, realice un análisis de brechas y revise los requisitos de gobernanza y de políticas: la mayoría se corresponderá con una política que ya tiene; el resto se convertirá en nuevas secciones o procedimientos.
Lo que exigen específicamente los marcos por escrito
- ISO 27001: una política de seguridad de la información (5.2) y políticas específicas por tema según sea necesario (A.5.1), comunicadas y revisadas.
- SOC 2: políticas que establezcan lo que se espera, desplegadas mediante procedimientos (CC5.3).
- PCI DSS: para cada uno de sus doce requisitos, políticas y procedimientos documentados y vigentes (x.1.1) y funciones asignadas (x.1.2), revisados al menos una vez al año.
- NIS2: una política sobre la seguridad de los sistemas de redes y de información, y políticas específicas por tema (Reglamento de Ejecución, punto 1).
- NIST CSF 2.0: la política está establecida, comunicada y se aplica (GV.PO).
Un conjunto mínimo de políticas
Para la mayoría de las organizaciones pequeñas y medianas, estos documentos cubren los requisitos de políticas de ISO 27001, SOC 2, NIST CSF, PCI DSS y NIS2:
- Política de seguridad de la información (nivel superior, aprobada por la dirección)
- Política de uso aceptable
- Política de control de acceso
- Política de gestión de activos y clasificación de datos
- Política de criptografía
- Política de desarrollo seguro y gestión de cambios
- Política de gestión de vulnerabilidades y parches
- Política de registro y monitorización
- Política de respuesta a incidentes (con las obligaciones de notificación)
- Política de continuidad de negocio y copias de seguridad
- Política de seguridad de proveedores
- Política de seguridad de recursos humanos
- Política de seguridad física
Trece documentos, la mayoría de unas pocas páginas, cada uno con un responsable y una fecha de revisión. Los procedimientos recogen el detalle y cambian con más frecuencia.
Puntos clave
- Las políticas deben ser específicas de la organización y estar correlacionadas, no ser específicas de cada marco.
- Incluya las frecuencias y las configuraciones en los procedimientos.
- Trece políticas breves cubren la mayoría de los marcos.
- PCI DSS exige que sus políticas y procedimientos se revisen al menos una vez al año.
Mantenerlas vigentes
- Escriba lo que hace, no lo que dice una plantilla. Los auditores contrastan las políticas con la práctica.
- Revise anualmente, y después de cambios significativos, con una aprobación registrada.
- Breve es mejor que completo: una política de control de acceso de dos páginas que la gente lee es mejor que veinte páginas que nadie lee.
Para un conjunto común completo de controles basado en la misma idea, consulte un conjunto de controles para SOC 2 e ISO 27001.
Preguntas
¿Cuántas políticas de seguridad necesita?
Menos de las que sugieren la mayoría de las plantillas. Una política de seguridad de la información de nivel superior más una docena de políticas temáticas (acceso, uso aceptable, respuesta a incidentes, seguridad de proveedores, etc.) suele cubrir ISO 27001, SOC 2, NIST y PCI DSS.
¿PCI DSS exige políticas específicas?
Sí. Cada requisito de PCI DSS comienza exigiendo políticas y procedimientos documentados y vigentes para ese ámbito (x.1.1), además de funciones y responsabilidades (x.1.2).
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-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.
Análisis · 2026-10-13Requisitos de MFA comparados en 11 marcos de seguridadQué marcos exigen MFA, a quién y con qué rigor: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 y HIPAA, comparados en paralelo.