Ir al contenido principal

¿Qué es realmente el gobierno de datos?, y ¿dónde termina su responsabilidad?

GOBIERNO DE DATOS · TÉCNICO-GERENCIAL Definición · Componentes · Límites ¿Qué es realmente el gobierno de datos?, y ¿dónde termina? Sus componentes reales, qué roles lo ejecutan y el límite exacto donde empieza la ciberseguridad. Clasificación Qué datos existen y qué valor tienen Custodio Quién es responsable de cada conjunto Calidad Completitud, precisión y consistencia Ciclo de vida Retención, uso y eliminación LB Luis Bolívar Service Delivery Manager Senior · Cybersecurity Insights #GobiernoDeDatos

Gobierno de datos: sus cuatro pilares reales y el límite exacto donde comienza la responsabilidad de la ciberseguridad.

Ayer establecimos por qué gobierno de datos y ciberseguridad no son lo mismo, y ¿cuál es el costo de confundirlos?. Hoy desarrollo la primera parte de esa separación: ¿qué es realmente el gobierno de datos?, ¿qué componentes lo integran?, ¡quién lo ejecuta? y, sobre todo, ¿dónde termina su responsabilidad? y ¿dónde comienza la de la ciberseguridad?.

La confusión entre ambas disciplinas empieza muchas veces porque el gobierno de datos no tiene una definición única y ampliamente conocida en el mundo empresarial. Se lo nombra, se dice que es importante, y luego nadie está del todo seguro de qué significa en la práctica. Esa ambigüedad es exactamente lo que permite que la ciberseguridad lo absorba o lo ignore según la conveniencia del momento.

Hoy le doy una definición operativa y lo descompongo en sus partes concretas.


¿Qué es el gobierno de datos?: definición operativa

El gobierno de datos es el conjunto de políticas, procesos, roles y estándares que definen cómo una organización gestiona sus datos como activo estratégico. No es un proyecto de TI ni una herramienta tecnológica; es un marco de toma de decisiones sobre los datos: quién puede decidir qué se hace con ellos, bajo qué criterios y con qué nivel de accountability.

En términos prácticos, el gobierno de datos responde a preguntas que el negocio necesita contestar antes de que TI pueda hacer cualquier cosa con la información: ¿qué datos tiene la organización?, ¿cuáles son sensibles y cuáles son públicos?, ¿quién es el responsable de cada conjunto de datos?, ¿con qué calidad se mantienen?, ¿durante cuánto tiempo se retienen y bajo qué normativa?, ¿cómo se usan para generar valor sin violar la privacidad de las personas involucradas?

Sin respuestas a esas preguntas, la ciberseguridad opera con un mapa incompleto. No puede priorizar qué proteger primero si no sabe qué datos son críticos. No puede calibrar los controles de acceso si no sabe quién debería acceder a qué. No puede diseñar la arquitectura de backups si no sabe cuáles datos tienen requisitos legales de retención y cuáles pueden eliminarse. El gobierno de datos no es un lujo de organizaciones grandes; es el insumo mínimo para que la ciberseguridad funcione correctamente en cualquier organización.

La distinción que más se olvida: El gobierno de datos es una función de negocio, no de TI. TI puede implementar las herramientas que lo soportan, pero las decisiones sobre qué datos son prioritarios, quién los posee y cómo se usan son decisiones del negocio. Cuando esas decisiones se delegan completamente a TI, el gobierno de datos se convierte en gestión técnica de datos, que es algo distinto y más limitado.

Los cuatro pilares del gobierno de datos

El gobierno de datos bien implementado tiene cuatro componentes que operan de forma integrada. Entender cada uno es necesario para entender también dónde termina y dónde empieza la responsabilidad de la ciberseguridad.

Clasificación de datos. Es el primer paso y el más crítico. Clasificar significa asignar a cada conjunto de datos un nivel de sensibilidad (público, interno, confidencial, restringido) y un nivel de criticidad para el negocio. Sin clasificación, no hay base para ninguna decisión posterior, ni de gobierno de datos ni de ciberseguridad. En el caso de TechCorp Latam, la ausencia de clasificación formal fue uno de los factores que dificultó la respuesta al ransomware: cuando los servidores cayeron, nadie tenía claro con inmediatez qué datos críticos estaban en cada uno ni cuál era la prioridad de recuperación.

Custodio o propietario del dato. Cada conjunto de datos necesita un responsable formal: una persona o área que tome las decisiones sobre ese dato, que responda por su calidad, que autorice o deniegue solicitudes de acceso y que defina su ciclo de vida. Ese rol se llama Data Owner o Data Steward según el marco que se use. Sin custodio, los datos son de todos y de nadie al mismo tiempo, lo que en la práctica significa que nadie toma decisiones sobre ellos de forma consistente.

Calidad del dato. El gobierno de datos establece estándares de completitud, precisión, consistencia y actualización para cada conjunto de datos. Un dato de baja calidad genera decisiones de negocio incorrectas; un dato de alta calidad pero sin protección genera riesgo de confidencialidad. Los dos problemas son distintos y requieren soluciones distintas. La calidad del dato es responsabilidad del gobierno de datos; la protección del dato es responsabilidad de la ciberseguridad.

Ciclo de vida del dato. Cada dato tiene un momento en que nace, un período en que es activo y útil, y un momento en que debe ser archivado o eliminado. El gobierno de datos define esos períodos bajo criterios de negocio y cumplimiento normativo. En Chile, la Ley 19.628 establece requisitos específicos sobre la retención de datos personales. Esos requisitos no los puede definir el equipo de ciberseguridad porque no son preguntas técnicas; son preguntas legales y de negocio que el gobierno de datos tiene que responder para que la ciberseguridad pueda implementar los controles correspondientes.

¿Cómo los cuatro pilares alimentan la ciberseguridad?: La clasificación informa qué activos proteger primero. El custodio define quién autoriza los accesos. La calidad determina qué datos requieren controles de integridad adicionales. El ciclo de vida define qué datos necesitan archivado seguro y cuáles pueden eliminarse, reduciendo la superficie de datos expuesta. Sin esos cuatro insumos, la ciberseguridad toma sus propias decisiones sobre prioridad, acceso e impacto, frecuentemente sin el contexto de negocio necesario para hacerlo correctamente.

Los roles que ejecutan el gobierno de datos

Una de las señales más claras de que el gobierno de datos no está implementado es la ausencia de roles formales con mandato explícito. Hay tres roles que cualquier organización que quiera gestionar sus datos seriamente necesita tener definidos, aunque los ejecuten personas que también tienen otras responsabilidades:

Chief Data Officer o responsable de datos. Define la estrategia de datos de la organización, establece las políticas de gobierno y responde ante la dirección por el cumplimiento de las obligaciones sobre datos. En organizaciones medianas, este rol frecuentemente lo absorbe el gerente de TI o el gerente de operaciones, lo que genera el problema que describimos ayer: cuando TI es responsable tanto de los datos como de la seguridad, la frontera entre los dos dominios desaparece.

Data Owner o propietario del dato. Es el responsable de negocio de un conjunto de datos específico. No tiene que ser un perfil técnico; tiene que ser quien conoce el valor de negocio de esos datos, quién los necesita y con qué propósito. El propietario de los datos de clientes puede ser el gerente comercial. El propietario de los datos financieros puede ser el CFO. La ciberseguridad protege; el Data Owner decide qué proteger y con qué prioridad.

Data Steward o custodio del dato. Es quien operativamente garantiza que los estándares de calidad, clasificación y ciclo de vida se aplican en el día a día. Puede ser un perfil más técnico que el Data Owner, con responsabilidad sobre la integridad y consistencia de los datos en los sistemas donde residen.

El error de rol más frecuente en la región: El IT Manager o Service Delivery Manager asume implícitamente la responsabilidad de gobierno de datos porque "los datos están en los sistemas de TI." Eso crea una sobrecarga de responsabilidad que ningún perfil puede gestionar bien simultáneamente: gobierno de datos requiere decisiones de negocio que TI no está posicionado para tomar unilateralmente, y ciberseguridad requiere foco técnico que se diluye cuando también hay que gestionar la clasificación, calidad y ciclo de vida de los datos.

¿Dónde termina el gobierno de datos y dónde empieza la ciberseguridad?

El límite entre las dos disciplinas no es una línea rígida; es una zona de colaboración donde los dos dominios se necesitan mutuamente. Pero tiene un punto de partida claro: el gobierno de datos termina donde termina la decisión sobre qué hacer con los datos, y la ciberseguridad empieza donde empieza la protección de cómo se accede a ellos, cómo se transmiten y cómo se almacenan.

En términos concretos: el gobierno de datos decide que los datos de clientes son confidenciales y que solo el equipo comercial y el área de soporte deben tener acceso. La ciberseguridad implementa los controles técnicos que hacen que esa decisión sea real: las reglas de acceso en la infraestructura Fortinet, los perfiles de usuario en los sistemas, el monitoreo de accesos anómalos en FortiAnalyzer, la segmentación de red que impide que otros segmentos accedan a esos datos aunque lo intenten.

Cuando ese límite no está definido, ocurre una de dos cosas: la ciberseguridad toma decisiones de negocio que no le corresponden (define quién puede acceder a qué sin consultar al Data Owner), o el gobierno de datos asume que la ciberseguridad ejecutará automáticamente sus políticas sin que nadie haya traducido esas políticas a controles técnicos. Las dos situaciones producen brechas. Mañana desarrollo dónde empieza concretamente la ciberseguridad y qué pasa cuando ese límite queda vacío.

Esta semana: gobierno de datos vs. ciberseguridad

Suscríbete al newsletter Cybersecurity Insights en LinkedIn para recibir cada entrega de la semana directamente.

#GobiernoDeDatos #DataGovernance #Ciberseguridad #CIO #ITManager #Fortinet #Cisco #WatchGuard #ISO27001 #NISTCSF #GestiónDeRiesgos #PrivacidadDeDatos #CyberLeadership #Chile #Estrategia

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...