Ir al contenido principal

¿Cómo construir la conversación correcta entre el Data Officer y el CISO?

REFLEXIÓN · LIDERAZGO · CIERRE DE SERIE La conversación que pocas organizaciones tienen ¿Cómo construir la conversación correcta entre el Data Officer y el CISO? ¿Qué preguntas hacerse, cómo estructurar el puente y por qué esta conversación no puede esperar al próximo incidente? Data Officer Qué datos, quién los posee, cómo se clasifican y retienen. CISO Cómo se protegen, qué controles implementan esas decisiones. LB Luis Bolívar Service Delivery Manager Senior · Cybersecurity Insights #DataGovernance

La conversación que el Data Officer y el CISO deberían tener antes de que un incidente la fuerce.

Cerramos la semana. Establecimos que gobierno de datos y ciberseguridad son disciplinas distintas. Desarrollamos sus componentes y responsabilidades. Mostramos dónde la ausencia de coordinación generó brechas reales en TechCorp Latam. Hoy viene la parte propositiva: cómo construir la conversación que cierra esa brecha antes de que un incidente la fuerce.

En pocas organizaciones de la región esa conversación ocurre de forma estructurada. El Data Officer, cuando existe como rol, tiende a operar en el mundo de la estrategia de datos, la calidad y el cumplimiento normativo. El CISO o encargado de ciberseguridad tiende a operar en el mundo de los controles técnicos, los incidentes y los frameworks de seguridad. Los dos mundos se tocan en la superficie, comparten vocabulario, y rara vez tienen una agenda de trabajo conjunto antes de que algo salga mal.

Lo que sigue es la estructura de esa conversación: qué preguntas debe responder cada rol, qué insumos debe aportar cada uno al otro, y cómo formalizar esa colaboración sin crear una burocracia que la haga imposible.


Las cinco preguntas que estructuran la conversación

La conversación entre el Data Officer y el CISO no es una reunión de presentaciones. Es un intercambio de información operativa que permite que cada uno tome mejores decisiones en su dominio. Hay cinco preguntas que, respondidas en conjunto, cubren el territorio más crítico de esa intersección:

¿Qué datos son verdaderamente críticos para el negocio? Esta pregunta le corresponde responder al Data Officer, con input de las áreas funcionales. La respuesta alimenta directamente la priorización de controles de la ciberseguridad: qué activos proteger primero, con qué nivel de inversión y con qué velocidad de respuesta ante un incidente. Sin esta respuesta, el CISO prioriza según criterios técnicos propios, que pueden o no coincidir con lo que el negocio considera más valioso.

¿Quién puede acceder a cada conjunto de datos y bajo qué condiciones? Esta pregunta la inicia el Data Officer con la definición de custodios y políticas de uso, y la termina el CISO con la implementación técnica de esas políticas en los controles de acceso. En entornos con la nueva infraestructura Fortinet de TechCorp Latam, esa implementación pasa por las políticas de FortiGate, los perfiles de usuario y la segmentación de red. El punto crítico es que esa conversación tiene que ocurrir antes de que el CISO configure los controles, no después.

¿Cuánto tiempo puede la organización estar sin acceso a cada conjunto de datos críticos? Esta es la pregunta del RTO y RPO que mencionamos el miércoles. La responde el negocio a través del Data Officer, y la implementa el CISO a través de la arquitectura de backups, la redundancia de infraestructura y los planes de recuperación. Si esa conversación no ocurre, el CISO define sus propios RTO y RPO basados en capacidad técnica, no en necesidad de negocio.

¿Qué obligaciones legales existen sobre los datos y qué implican en caso de incidente? Esta pregunta le corresponde al Data Officer con soporte del área legal. La respuesta define qué información necesita el CISO para activar correctamente el protocolo de notificación ante un incidente que involucre datos personales: qué datos fueron comprometidos, de quién son, qué normativa aplica y en qué plazo. Sin esa información preparada de antemano, cada incidente genera una carrera contra el reloj para reconstruir el mapa de datos bajo presión.

¿Qué datos deberían dejar de existir y cuándo? La política de retención es una decisión de gobierno de datos con consecuencias directas de ciberseguridad. Cada dato que se retiene más allá de su período necesario es superficie de exposición activa. El CISO no puede eliminar datos por iniciativa propia; necesita que el Data Officer defina qué puede eliminarse, cuándo y bajo qué proceso. Sin esa definición, los datos se acumulan indefinidamente y la superficie de ataque crece sin control.

El formato que funciona: Una reunión trimestral entre el Data Officer, el CISO y los custodios de datos críticos, con una agenda fija de cinco puntos: revisión de clasificación de datos, revisión de políticas de acceso, revisión de RTO/RPO, actualización de obligaciones normativas y revisión de política de retención. Noventa minutos. Cuatro veces al año. Eso es suficiente para mantener la coordinación operativa entre los dos dominios sin crear una estructura paralela que nadie puede sostener.

¿Qué aporta cada rol a la conversación?

La conversación funciona cuando cada rol llega con insumos concretos, no con posiciones generales. El Data Officer necesita llegar con el inventario de datos clasificados actualizado, la lista de custodios por dominio, el mapa de obligaciones normativas vigentes y la política de retención aprobada. Sin esos insumos, la conversación se convierte en una discusión conceptual que no produce decisiones.

El CISO necesita llegar con el estado actual de los controles que protegen los datos clasificados como críticos, los incidentes o amenazas recientes que afectan a esos activos, las brechas identificadas en el período y las decisiones de inversión pendientes que requieren validación desde el negocio. Sin esos insumos, el Data Officer no puede tomar decisiones informadas sobre qué datos requieren mayor nivel de protección ni qué inversiones de seguridad son prioritarias desde el punto de vista del valor de los datos.

Lo que la conversación debe producir es un documento de trabajo simple: la lista de datos críticos con su nivel de clasificación actualizado, las políticas de acceso vigentes y sus responsables, los RTO y RPO acordados por tipo de dato, las acciones pendientes de cada dominio con responsable y fecha, y la fecha de la próxima revisión. Ese documento no es un informe para el directorio; es la herramienta de trabajo que mantiene la coordinación entre los dos dominios entre reuniones.

El error más común en esta conversación: Que se convierta en una reunión de reportes en lugar de una reunión de decisiones. El Data Officer reporta el estado del gobierno de datos. El CISO reporta el estado de los controles. Ninguno hace preguntas al otro. Nadie sale con acciones concretas. Esa reunión tiene valor de visibilidad mutua, pero no produce la coordinación operativa que los dos dominios necesitan. La diferencia entre una reunión de reportes y una reunión de decisiones está en las preguntas que cada rol le hace al otro.

¿Cuando no existe ninguno de los dos roles?

En muchas organizaciones de la región, especialmente las medianas, ni el Data Officer ni el CISO existen como roles formales dedicados. El gobierno de datos lo gestiona parcialmente TI, parcialmente el área de calidad, parcialmente nadie. La ciberseguridad la maneja el Service Delivery Manager, el IT Manager o un proveedor externo con alguna solución de monitoreo.

En ese contexto, la conversación que estoy describiendo no desaparece; cambia de participantes. El profesional que gestiona la infraestructura y la seguridad necesita tener esa conversación con los gerentes funcionales que poseen los datos: el gerente comercial, el CFO, el gerente de operaciones. Las mismas cinco preguntas, los mismos insumos, el mismo documento de trabajo. La estructura no requiere títulos específicos; requiere que alguien se haga responsable de hacer las preguntas correctas y de que las respuestas produzcan decisiones.

Ese es precisamente el rol que el Service Delivery Manager puede jugar en organizaciones donde ninguno de los dos roles existe formalmente: el puente entre las decisiones de negocio sobre los datos y las decisiones técnicas de seguridad que las implementan. No como propietario de ninguno de los dos dominios, sino como el profesional que garantiza que la conversación ocurra con la estructura y la frecuencia que los dos dominios necesitan.

La conversación más importante que nadie agenda: En TechCorp Latam, esa conversación no existía antes del ransomware. El comité de ciberseguridad que se creó después fue el primer mecanismo que la hizo posible de forma regular. No fue suficiente para evitar el incidente, porque llegó después. Pero fue suficiente para que el siguiente incidente, si llega, encuentre una organización con el mapa de datos disponible, los custodios identificados y los controles calibrados sobre la realidad del negocio.

Cierre de la semana

Esta semana desarrollamos cinco dimensiones de la misma realidad: gobierno de datos y ciberseguridad son disciplinas distintas que se necesitan mutuamente, y la confusión entre ellas no es un problema conceptual sino operacional con consecuencias concretas en la capacidad de respuesta ante incidentes, en la calidad de los controles de acceso y en el cumplimiento normativo.

La conversación entre el Data Officer y el CISO no es un lujo de organizaciones grandes. Es el mecanismo mínimo para que los dos dominios operen con información suficiente. Y en organizaciones donde ninguno de esos roles existe formalmente, alguien tiene que hacer esas preguntas de todos modos. Porque si nadie las hace, TechCorp Latam ya mostró qué pasa a las 4 de la mañana cuando el ransomware llega y nadie tiene el mapa.

Serie completa disponible en el blog

Suscríbete al newsletter Cybersecurity Insights en LinkedIn. La semana que viene, nueva serie.

#GobiernoDeDatos #Ciberseguridad #DataGovernance #CISO #CIO #ITManager #Fortinet #Cisco #WatchGuard #ISO27001 #NISTCSF #Liderazgo #CyberLeadership #Chile #Reflexión

Comentarios

Entradas más populares de este blog

¿Por qué CIS Controls antes que cualquier otra cosa? Serie: CIS Controls — Post 1 de 5

SERIE CIS CONTROLS · POST 1 DE 5 Estrategia · Liderazgo en TI ¿Por qué CIS Controls antes que cualquier otra cosa? El argumento estratégico para empezar por donde el riesgo es mayor, no por donde el proceso es más visible. Priorización por riesgo No todos los controles valen lo mismo Lenguaje de negocio Traduce técnica en riesgo medible Complementa ISO 27001 Donde la norma dice qué, CIS dice cómo LB Luis Bolívar IT Manager · Cybersecurity Insights #CISControls #Ciberseguridad Serie CIS Controls — Post 1 de 5: el argumento estratégico para empezar por donde el riesgo es mayor. Cuando TechCorp Latam implementó CIS Controls por primera vez, lo hizo después de un ransomware que comprometió el 65% de sus servidores. No fue una decisión estratégica planificada; fue un...

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos

NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos Serie · Post 2 de 6 🔍 Función ID — IDENTIFY NIST CSF 2.0 — IDENTIFY: Conoce tus activos antes de protegerlos No puedes proteger lo que no sabes que tienes. IDENTIFY es el mapa que toda organización necesita antes de implementar cualquier control de seguridad. Analizamos sus 3 categorías y construimos el inventario de TechCorp Latam. 📅 Publicación 2 de 6 ⏱ Lectura: ~10 min 🏢 TechCorp Latam · Inventario desde cero El error más costoso en ciberseguridad: proteger sin saber qué tienes Imagina contratar una empresa de seguridad para custodiar tu edificio, pero nadie te da el plano del edificio. ¿Cuántas entradas hay? ¿Dónde están los archivos más valiosos? ¿Qué puertas dan al exterior? Sin ese plano, la seguridad es aleatoria. Exactamente eso ocurre cuando una organización invierte en firewalls, antivirus y monitoreo sin haber hecho antes un trabajo sistemático de identif...

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió

NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Serie · Post 5 de 6 🚨 Función RS — RESPOND NIST CSF 2.0 — RESPOND: Actuar cuando el incidente ya ocurrió Todo lo que TechCorp Latam construyó en GOVERN, IDENTIFY, PROTECT y DETECT llegó a su momento de verdad: un ataque de ransomware real. Esta es la historia de cómo respondieron, qué salió bien y qué lección pagaron caro. 📅 Publicación 5 de 6 ⏱ Lectura: ~12 min 🏢 TechCorp Latam · El momento de la verdad El momento para el que todo lo anterior te prepara Llevan cuatro funciones construyendo su programa. Tienen gobernanza, inventario de activos, controles activos y visibilidad de red. Y aun así, el incidente ocurre. Porque esa es la realidad del riesgo cibernético: los controles reducen la probabilidad, no la eliminan . El objetivo de un programa maduro de ciberseguridad no es hacer que los incidentes sean imposibles — es hacer que sean contenibles, detectables y recuper...