La mayoría de las empresas no niega los riesgos de seguridad a los que se enfrenta. Sencillamente, no decide nada sobre ellos. El riesgo existe, lo conoce quien trabaja en el área, aparece de vez en cuando en las reuniones... y se queda ahí, sin aprobación, sin registro, sin responsable. Esa ausencia de decisión es, en sí misma, una decisión. Y suele ser la más cara. Es exactamente ahí donde la gestión de riesgos de seguridad de la información deja de funcionar. No por falta de tecnología o de equipo cualificado, sino por falta de un propietario. Alguien que lo firme, que responda por ello, que lo revise cuando el escenario cambie. Sin eso, el riesgo no desaparece: simplemente deja de tener dirección. ¿Qué es la gestión de riesgos de seguridad de la información? La gestión de riesgos de seguridad de la información es el proceso mediante el cual una organización identifica, evalúa y decide qué hacer con cada amenaza que puede comprometer sus sistemas, sus datos o sus operaciones. La palabra clave aquí es decide. No solo identifica. No solo monitoriza. Ante un riesgo identificado, existen cuatro caminos legítimos: mitigar (reducir la probabilidad o el impacto), transferir (como en el caso de los seguros o los contratos de responsabilidad), eliminar (cuando es posible eliminar la causa raíz) o aceptar (reconocer que el riesgo existe y que, por ahora, no se va a tratar). Todos estos caminos son válidos, siempre que se recorran de forma consciente, documentada y con alguien responsable de esa decisión. El problema no es aceptar un riesgo. El problema es aceptarlo sin que nadie sepa que se ha hecho. Aceptar el riesgo no es el problema. Aceptarlo en silencio sí lo es. Existe una diferencia fundamental entre una decisión tácita y una decisión formal. En la primera, el riesgo se percibe, se comenta en algún momento y se deja de lado por inercia o por la presión de otras prioridades. En la segunda, hay un registro: quién lo evaluó, cuál fue el criterio, quién lo aprobó y cuándo se revisará. El escenario de la decisión tácita es más habitual de lo que parece. El responsable de TI señala una vulnerabilidad, el CISO reconoce que no hay presupuesto para abordarla ahora, la dirección escucha brevemente el asunto en una reunión y sigue adelante. Nadie decide nada formalmente, pero todos, de alguna manera, han acordado no actuar. Ese es el riesgo sin propietario. Cuando ocurre un incidente y ese riesgo concreto está en el origen del problema, la pregunta inevitable es: ¿quién lo sabía? ¿Quién lo aprobó? ¿Por qué no se trató? Sin registro, no hay respuesta. Solo hay responsabilidad difusa, que, en la práctica, recae sobre quien esté más expuesto en el momento equivocado. Por eso, formalizar una política de seguridad de la información va mucho más allá de redactar un documento: crea el entorno en el que las decisiones sobre el riesgo deben quedar registradas, y en el que la ausencia de decisión deja de ser una opción silenciosa. Quién debería ser el propietario del riesgo en la gestión de riesgos de seguridad Una confusión habitual es pensar que el propietario del riesgo tiene que ser quien lo va a resolver. No funciona así. El propietario del riesgo es quien tiene la autoridad para decidir sobre él, y quien responde por las consecuencias de esa decisión. En algunos casos, ese papel corresponde al CISO. En otros, al responsable del área de negocio que depende del sistema en cuestión, al departamento jurídico cuando hay implicaciones regulatorias, o directamente a la alta dirección cuando el impacto potencial es significativo para la operación. Lo que no es aceptable es que el riesgo quede suspendido entre departamentos, sin que nadie tenga claro quién tiene la última palabra. La seguridad dejó de ser un problema exclusivo de TI hace mucho tiempo. Cuando un riesgo de seguridad puede paralizar una operación, exponer datos de clientes o generar responsabilidad legal, se convierte en un riesgo de negocio. Y los riesgos de negocio necesitan propietarios con capacidad de decisión, no solo técnicos con capacidad de identificación. Qué ocurre cuando el riesgo no se documenta Un riesgo no documentado no es un riesgo gestionado. Es un riesgo olvidado, hasta el momento en que se convierte en un incidente. Las consecuencias prácticas aparecen en distintas capas. La primera es operativa: sin un historial de decisiones, la empresa no puede reconstruir el razonamiento que llevó a la situación actual. La segunda es regulatoria: la LGPD (la Ley General de Protección de Datos de Brasil) exige que las organizaciones adopten medidas de seguridad proporcionales a los riesgos que conocen. Conocer un riesgo y no documentar lo que se decidió sobre él es una exposición que auditores y reguladores se toman muy en serio. La tercera es reputacional: los incidentes que revelan riesgos previamente conocidos y deliberadamente ignorados tienen un impacto distinto al de aquellos causados por amenazas genuinamente desconocidas. Las organizaciones que entienden qué les ocurre a las infraestructuras que nunca se han puesto a prueba reconocen que la ausencia de registros sobre riesgos conocidos es tan peligrosa como la ausencia de protección técnica. El daño ya tiene historial mucho antes de hacerse visible. Falsa sensación de control: cuando «está monitorizado» se convierte en excusa Existe un patrón recurrente en empresas con buenas herramientas de seguridad pero con una gestión de riesgos aún inmadura: la monitorización se confunde con la gestión. El panel está en verde. Las alertas están configuradas. El equipo sigue los registros. Y el riesgo estructural identificado hace meses sigue sin una decisión formal, porque la sensación general es que «está bajo control». Monitorizar no es decidir. Tener visibilidad sobre un problema no equivale a haber tomado una postura al respecto. Es el mismo razonamiento que explica por qué tener un firewall activo no significa que la seguridad esté garantizada: la herramienta cubre una capa, pero no sustituye la decisión humana sobre qué hacer con lo que revela. La gestión de riesgos de seguridad de la información exige algo más que visibilidad. Exige que lo que se observa se transforme en una decisión registrada, con responsable, criterio y plazo de revisión. Cómo formalizar la aceptación de riesgos en la gestión de riesgos de seguridad Formalizar la aceptación de un riesgo no exige un proceso burocrático pesado. Exige constancia. Los elementos mínimos de un registro adecuado son los siguientes: - **Descripción del riesgo:** qué se ha identificado, en qué sistema o proceso, y cuál es el impacto potencial. - **Evaluación de probabilidad e impacto:** basta con una clasificación sencilla: bajo, medio o alto para cada dimensión. - **Decisión tomada:** mitigar, transferir, eliminar o aceptar, con su justificación. - **Responsable del riesgo:** nombre, cargo, área. Quién responde por esa decisión. - **Aprobación de la dirección competente:** cuando el impacto es relevante, la decisión debe ser sancionada por quien tenga autoridad sobre el asunto. - **Plazo de revisión:** los riesgos aceptados hoy pueden volverse inaceptables mañana. Definir cuándo se reevaluará esa decisión forma parte del proceso. Ese registro no necesita estar en un sistema sofisticado para funcionar. Necesita existir, estar accesible y ser revisado. La madurez llega con el tiempo; lo que no puede esperar es el hábito de documentar. Riesgo sin propietario no es gestión. Es una apuesta. La provocación que abre este texto sigue siendo válida en la conclusión: cuando el riesgo de seguridad se acepta sin haberse discutido, no desaparece, simplemente se queda sin propietario. Y un riesgo sin propietario es un riesgo que la empresa carga sin saber exactamente el peso de lo que está sosteniendo. Una gestión de riesgos de seguridad de la información madura no es la que elimina todos los riesgos (eso no existe). Es la que sabe exactamente quién decidió, qué decidió, con qué criterio y cuándo va a revisarlo. Eso transforma una vulnerabilidad latente en una decisión consciente. Y las decisiones conscientes, aunque sean imperfectas, son mucho más manejables que los silencios cómodos. El mismo principio aparece cuando se habla de lo que una auditoría de seguridad revela y que el equipo de TI no llega a ver por sí solo, o cuando se estructura un plan de respuesta a incidentes antes de que el incidente ocurra. Las empresas que alcanzan ese nivel de madurez no llegan a él por accidente. Llegan porque, en algún momento, alguien que ya ha visto lo que puede salir mal ayudó a construir procesos en los que la ausencia de decisión dejó de ser una opción.
