El departamento de IT pide más presupuesto para licencias EDR y firewalls. El comité de dirección solo ve una fuga constante de dinero en la cuenta de resultados que no parece aportar valor directo. Este es el síntoma clásico de una empresa donde la seguridad técnica está completamente desconectada de la realidad del negocio.
Para cerrar esta brecha existe la gobernanza de ciberseguridad. Su objetivo no es parchear servidores ni configurar reglas en la nube, sino garantizar que los esfuerzos técnicos apoyen y protejan la misión de la empresa sin asfixiarla.
Alinearnos con los estándares de la industria (como los marcos avalados por entidades como ISC2) nos obliga a cambiar el enfoque: vamos a desgranar cómo dejar de ser un «freno» para empezar a hablar un idioma que la dirección entienda, respalde y, lo más importante, financie.
Índice de contenidos
Por qué la ciberseguridad no es (solo) un problema de IT
Históricamente, la seguridad se ha delegado de forma íntegra en los administradores de sistemas. Esto es un error fundamental: el dueño del riesgo siempre es el negocio, no IT. El equipo técnico solo implementa los controles para mitigar ese riesgo.
Si una medida de seguridad bloquea un proceso crítico de ventas o hace que los empleados tarden el doble en hacer su trabajo diario, la seguridad ha fallado.
La gobernanza busca el equilibrio exacto: proteger los activos de la empresa permitiendo que esta siga operando y facturando.
La ciberseguridad debe ser un habilitador, los frenos de alto rendimiento que permiten al coche ir más rápido de forma segura.
El enfoque «Top-Down»: La seguridad empieza en la dirección
Los grandes marcos de trabajo insisten en una máxima innegociable: la seguridad debe tener un enfoque Top-Down (de arriba hacia abajo). Si la dirección no está implicada, no entiende los riesgos y no aprueba formalmente las políticas, cualquier iniciativa técnica acabará fracasando por falta de autoridad o de recursos.
Riesgo empresarial vs. Riesgo técnico
Los técnicos hablan de exploits y puntuaciones CVSS. La dirección habla de euros, daño reputacional, pérdida de clientes y multas. Un servidor con una vulnerabilidad crítica (CVSS 9.8) no supone el mismo riesgo si es un entorno de pruebas aislado que si es la pasarela de pagos de producción.
La gobernanza traduce el riesgo técnico a riesgo empresarial. Una vez cuantificado, solo hay cuatro formas de tratarlo:
- Mitigarlo: Implementar controles técnicos o administrativos (ej. segmentar la red, exigir MFA).
- Transferirlo: Pasar el impacto financiero a un tercero (ej. contratar un ciberseguro).
- Aceptarlo: Cuando el coste de la solución es mayor que el impacto del problema. Ojo: esto requiere la firma explícita de la dirección, no del CISO o del responsable de sistemas.
- Evitarlo: Dejar de realizar la actividad que genera el riesgo (ej. apagar un servicio heredado que ya no compensa mantener).
La trampa del «Check-box Compliance»
Adoptar frameworks como ISO 27001 o NIST CSF es una excelente base. Sin embargo, el mayor error corporativo es tratarlos como una simple lista de verificación. Cumplir normas sobre el papel no es lo mismo que estar seguro en la práctica. Si implementas controles genéricos sin entender las amenazas reales de tu empresa, solo estás generando burocracia inútil. Y aquí tiene sentido hablar de Due Care y Due Diligence, y no, no son nombres de colonia.
Due Care y Due Diligence: La diferencia que te salva en un juicio
Estos dos conceptos legales y corporativos son el núcleo de la responsabilidad en ciberseguridad. A menudo se confunden, pero la diferencia es vital si ocurre una brecha de datos y llegan las auditorías o las demandas.
- Due Care (Cuidado debido): Es «hacer lo correcto». Es el estándar mínimo de protección que se espera de una empresa responsable. Implica establecer las medidas, comprar las herramientas y redactar las políticas necesarias.
- Due Diligence (Diligencia debida): Es «hacerlo bien de forma continua». Es el esfuerzo constante por verificar, auditar y mantener que ese Due Care se está cumpliendo en la realidad operativa.
Due Care es la acción (comprar, redactar, implementar). Due Diligence es la validación (auditar, revisar, probar). Tener el primero sin el segundo es tirar el dinero y, legalmente, se considera negligencia.
Ejemplo due care, due diligence: «gestión de copias de seguridad«:
- Due Care: es redactar una política que exija hacer copias de las bases de datos cada 24 horas y comprar un software de backup profesional.
- Due Diligence: es revisar los logs diarios para comprobar que esos backups no han fallado y, sobre todo, hacer un simulacro de restauración (DRP) paso a paso cada seis meses para asegurar que los datos realmente sirven.
Tener la política pero no auditarla (Due Care sin Due Diligence) es negligencia.
Ejemplo due care due diligence: «gestionando vulnerabilidades»:
- Due Care: Redactar una política que exija que las vulnerabilidades críticas se parcheen en menos de 48 horas y comprar una herramienta como WSUS, SCCM o Qualys para automatizarlo. Has establecido el estándar.
- Due Diligence: Ejecutar un escaneo de vulnerabilidades independiente cada semana para verificar que esos parches realmente se han aplicado, y revisar los logs buscando máquinas que hayan dado error en la actualización.
Ejemplo due care due diligence: «gestion de proveedores»:
- Due Care: Exigir por contrato a tu nuevo proveedor de software en la nube que firme un NDA (Acuerdo de Confidencialidad) y rellene un cuestionario de seguridad antes de darle acceso a tus datos.
- Due Diligence: Solicitar a ese proveedor su informe de auditoría externo (ej. SOC 2 Tipo II o ISO 27001) cada año, revisarlo detalladamente y comprobar que siguen cumpliendo las normas iniciales.
Ejemplo due care due diligence: «respuesta ante incidentes»:
- Due Care: Contratar a una consultora externa para que te redacte un Plan de Respuesta ante Incidentes (IRP) de 50 páginas y dejarlo guardado en una carpeta compartida de SharePoint.
- Due Diligence: Organizar un simulacro o tabletop exercise cada seis meses con el comité de dirección y los técnicos para simular un ataque de ransomware y comprobar si la gente sabe usar ese plan y si los teléfonos de emergencia siguen activos.
La jerarquía del orden: Políticas, Estándares y Procedimientos
Un entorno gobernado tiene reglas claras. Mezclar el «qué queremos hacer» con el «cómo se hace» en un mismo documento es la receta para el caos. La jerarquía documental debe ser estricta:
- Políticas (Policies): Obligatorias y de alto nivel. Aprobadas por la dirección. Definen el «Qué» y el «Por qué», nunca la tecnología concreta. (Ej: «Todos los accesos externos a sistemas críticos de la empresa requerirán autenticación fuerte»).
- Estándares (Standards): Obligatorios. Definen la tecnología exacta autorizada para cumplir la política. (Ej: «La autenticación fuerte se realizará mediante Microsoft Entra ID utilizando tokens TOTP o llaves físicas FIDO2»).
- Procedimientos (Procedures): Obligatorios. Es el paso a paso técnico, detallado y secuencial para implementar el estándar. Debe incluir los comandos exactos, las rutas de los menús o los scripts necesarios. (Ej: El manual paso a paso con capturas y comandos de PowerShell para habilitar el MFA a un usuario nuevo en el tenant de Azure).
- Guías (Guidelines): Recomendaciones. No son obligatorias, pero ayudan al usuario. (Ej: «Buenas prácticas para crear reglas en tu bandeja de correo»).
Un problema que acecha en las mentes de muchos equipos de TI… ¿Para que tener políticas si somos «cuatro gatos» para aplicarlas?. Bueno… tenerlas ya puede suponer atenuantes en las multas, si la cosa se pusiera fea. Las políticas deberían estar acotadas a ser «cuatro gatos», eso también.
Cultura de Ciberseguridad: Más allá del curso de phishing
La gobernanza dicta las reglas, pero la cultura de ciberseguridad dicta lo que hace la gente un viernes a las seis de la tarde, cuando nadie mira.
El error de culpabilizar al usuario
Llamar al usuario «el eslabón más débil» es una frase tóxica que a menudo demuestra pereza defensiva por parte de IT. Si un empleado de contabilidad hace clic en un Excel malicioso y eso compromete todo tu Active Directory, el problema no es solo la falta de concienciación del usuario; el problema real es que tu arquitectura carece de segmentación y no aplica el principio de mínimo privilegio.
La cultura no consiste en castigar al que se equivoca, sino en aplicar Secure by Design: diseñar sistemas que asuman que el error humano va a ocurrir inevitablemente y limiten su radio de impacto. 👉 Revisa nuestro artículo sobre concienciación al empleado corporativo.
Security Champions: Escalando la seguridad
El equipo de IT o de seguridad es finito y no puede auditar cada proyecto desde el día uno. Una excelente práctica de gobernanza es crear Security Champions: empleados de otros departamentos (desarrollo, recursos humanos, marketing) que reciben formación técnica y estratégica avanzada. Ellos actúan como enlaces, evangelizadores y primeros filtros de seguridad dentro de sus propios equipos.
3 Errores comunes al implementar la gobernanza
- Copiar políticas de internet: Descargar una política restrictiva y simplemente cambiarle el logo en el encabezado. Si tu política exige cambiar la contraseña cada 30 días (algo que ya desaconseja el NIST) y la empresa no tiene la capacidad de gestionarlo, la política nace muerta y fomenta el incumplimiento sistemático por parte de todos.
- Ignorar el BIA (Business Impact Analysis): Invertir en licencias sin saber qué procesos son críticos. ¿Vas a gastar el mismo presupuesto y horas de monitorización en proteger el servidor que aloja el menú del comedor que el CRM de ventas? Sin un BIA previo, proteges a ciegas.
- Métricas de vanidad: Reportar a la dirección frases como «hemos bloqueado 15.000 intentos de escaneo de puertos este mes». Al comité de dirección ese dato no le dice nada operativo. Las métricas deben hablar de negocio: «Hemos reducido el tiempo medio de recuperación (MTTR) de 8 horas a 2 horas, salvando un potencial de 50.000€ en paradas operativas».
Checklist: ¿Está tu estrategia alineada con el negocio?
Revisa estas preguntas de forma honesta con tu equipo. Si la respuesta es «No» a más de dos, tu seguridad es puramente reactiva:
- ¿Puede el comité de dirección explicar cuáles son las 3 mayores ciberamenazas reales para la continuidad de la empresa?
- ¿Sabes documentar y demostrar la diferencia entre el Due Care y el Due Diligence en tus procesos más críticos (ej. backups, gestión de identidades)?
- ¿Está documentado y firmado formalmente por la dirección el riesgo que se ha decidido «Aceptar»?
- ¿Tus políticas de seguridad son públicas para los empleados, están actualizadas y se pueden leer sin ser ingeniero informático?
- Cuando pides presupuesto para una herramienta, ¿lo justificas mostrando qué riesgo financiero o reputacional mitigas en lugar de listar las características técnicas del software?
Cuanto trabajo por hacer, ¿verdad?. No te agobies (tampoco te duermas), recuerda que la perfección no existe y el objetivo es mitigar riesgos de forma constante.
Conclusión
La gobernanza de ciberseguridad es la frontera que separa a un «bombero» informático de un estratega tecnológico. Mientras el departamento se limite a apagar fuegos, instalar parches y reaccionar a alertas, la dirección lo seguirá viendo como un centro de costes inevitable.
Cuando empieces a mapear las vulnerabilidades técnicas contra los procesos de negocio que sustentan, a ejercer una diligencia debida real (Due Diligence) sobre tus controles y a liderar la cultura basándote en el diseño seguro en lugar de la prohibición, la ciberseguridad ocupará el lugar estratégico que le corresponde.
