La política de ciberseguridad no es papelería
40 páginas que nadie leyó no son una política. Analizamos qué lleva una política marco real, la jerarquía documental de un SGSI y por qué sin estructura, tu seguridad es decoración.
40 páginas que nadie leyó
Portada corporativa. 7 fuentes bibliográficas. Índice numerado.
Nadie la leyó. Nadie sabe dónde está. Y cuando ocurrió el incidente, nadie supo qué hacer.
Eso no es una política. Es decoración.
Pero hay otro extremo igual de común: meter todo en un solo documento. Procedimientos, configuraciones, matrices de roles, flujos de escalamiento. Todo revuelto en una “política” de 80 páginas.
Eso tampoco es una política. Es un Frankenstein documental.
La política marco define el qué y el por qué. Nunca el cómo
El cómo vive en lo que se desprende de ella:
- Políticas específicas: accesos, uso aceptable, seguridad OT
- Procedimientos: respuesta a incidentes, gestión de cambios, respaldos
- Planes: continuidad, recuperación, gestión de crisis
- Guías e instructivos: hardening, configuración, operación SOC
Esa jerarquía no es opcional. Es lo que hace que un SGSI funcione en la práctica.
Procedimientos sin política marco
He visto procedimientos de respuesta a incidentes impecables. Técnicamente sólidos. Detallados al minuto.
Sin política marco.
Flotan en el vacío. Sin respaldo directivo, sin criterio de riesgo. El día que hay que decidir si pagamos el rescate o detenemos la operación, el procedimiento no alcanza.
Esas decisiones son de gobernanza. Y la gobernanza se define en la política marco.
Políticas que ignoran la red OT
He visto plantas industriales con políticas que ni mencionan la red OT. Que hablan de “proteger activos de información” pero nadie mapeó que un PLC o un SCADA también son activos.
Y que comprometerlos no es perder datos — es detener una operación física.
Si tu política de ciberseguridad solo habla de IT, estás dejando fuera la superficie de ataque más crítica de tu organización industrial.
Qué lleva una política marco real
1. Alcance claro
Si tienes OT y la política solo habla de IT, partiste mal.
El alcance debe cubrir explícitamente:
- Infraestructura IT (redes, servidores, endpoints, nube)
- Infraestructura OT (SCADA, PLCs, HMIs, redes industriales)
- Servicios de terceros y proveedores con acceso a la red
- Datos en todas sus formas: digital, física, en tránsito
2. Apetito de riesgo definido por la dirección
No por el CISO. No por el consultor. Por la dirección.
Con firma y con el compromiso explícito de proveer los recursos necesarios para la implementación, operación y mejora continua del SGSI.
Sin presupuesto asignado, el apetito de riesgo es ficción.
3. Roles estratégicos
La política marco define roles de gobernanza:
- Quién es responsable del SGSI
- Quién reporta a quién ante un incidente crítico
- Quién tiene autoridad para tomar decisiones de contención
No el detalle operativo — eso va en procedimientos.
4. Compromiso de alta dirección
Esto no es una formalidad. Es el fundamento legal y organizacional del SGSI.
Sin compromiso explícito de la alta dirección:
- No hay presupuesto garantizado
- No hay autoridad para hacer cumplir las políticas
- No hay respaldo cuando las decisiones son difíciles
Sin esto, el SGSI es ficción.
5. Marco normativo aplicable
La política debe declarar los marcos de referencia bajo los cuales opera:
| Dominio | Marcos de referencia |
|---|---|
| Seguridad de la información | ISO 27001, ISO 27002 |
| Gestión de riesgos | ISO 31000, NIST RMF |
| Framework de ciberseguridad | NIST CSF 2.0 |
| Seguridad industrial (OT) | IEC 62443 |
| Regulación local (Chile) | Ley 21.663, Decreto 295/2024 |
Declarar los marcos no es decorativo: define el criterio de auditoría y el lenguaje común del equipo.
6. Criterios de revisión
La política no es estática.
Define cuándo se revisa:
- Periódicamente: mínimo una vez al año
- Por evento: después de un incidente significativo
- Por cambio: nueva regulación, nueva tecnología, nueva estructura organizacional
La jerarquía documental del SGSI
Política Marco de Ciberseguridad
├── Política de Control de Accesos
├── Política de Uso Aceptable
├── Política de Seguridad OT
│
├── Procedimiento de Respuesta a Incidentes
├── Procedimiento de Gestión de Cambios
├── Procedimiento de Respaldos y Recuperación
│
├── Plan de Continuidad de Negocio (BCP)
├── Plan de Recuperación ante Desastres (DRP)
├── Plan de Gestión de Crisis
│
├── Guía de Hardening de Servidores
├── Guía de Configuración de Firewalls
└── Instructivo de Operación SOCCada nivel tiene un propósito distinto:
- Políticas: definen el qué y el por qué — aprobadas por dirección
- Procedimientos: definen el cómo paso a paso — mantenidos por operaciones
- Planes: definen la respuesta ante escenarios específicos — probados con ejercicios
- Guías e instructivos: definen configuraciones técnicas — actualizados por los equipos técnicos
Cuando llega el ransomware a las 2 AM
Nadie abre la política marco a las 2 AM.
Pero si esa política definió bien la estructura, el procedimiento de respuesta a incidentes que sí se abre tiene:
- Fundamento: está respaldado por una decisión de gobernanza
- Autoridad: define quién puede tomar decisiones de contención
- Respaldo directivo: el CISO no está solo cuando hay que detener la planta
La cadena funciona porque cada eslabón existe y está conectado.
La ciberseguridad no empieza con un firewall
Tampoco empieza con 80 páginas.
Empieza con una decisión estratégica bien estructurada.
Una política marco que nadie puede encontrar es tan inútil como no tener política. Y un SGSI sin jerarquía documental es un archivo de buenas intenciones.
La pregunta para tu organización es simple: si mañana ocurre un incidente crítico, ¿tu equipo sabe exactamente qué documento abrir, quién tiene autoridad para decidir y bajo qué criterio actuar?
Si la respuesta no es un sí inmediato, el problema no es técnico.
Es de gobernanza.