Identificar un riesgo es solo una parte del trabajo.
Después viene una pregunta bastante menos cómoda: ¿el control que hemos puesto reduce realmente ese riesgo?
Porque es relativamente fácil acabar con una lista impecable de controles: backups, accesos, cambios, proveedores, monitorización, continuidad, configuración, revisiones…
Lo difícil es saber cuáles están funcionando de verdad.
Un control TIC no debería existir para quedar bien en un Excel. Debería ayudarnos a evitar un problema, detectarlo antes, reducir su impacto o recuperarnos mejor cuando ocurra.
Qué es un control, sin complicarlo
Un control es una medida que ayuda a gestionar un riesgo.
Puede evitar que algo pase, ayudar a detectarlo, reducir su impacto o facilitar la recuperación.
No tiene que ser algo espectacular.
A veces un buen control es tan simple como:
- revisar usuarios con permisos elevados,
- probar una restauración,
- activar MFA,
- cerrar un puerto que no se usa,
- documentar cómo se recupera un servicio,
- monitorizar una caída,
- revisar un proveedor crítico,
- o dejar evidencia de un cambio importante.
Lo importante no es que suene sofisticado.
Lo importante es que aporte.
Menos checklist y más realidad
Los checklists son útiles. Yo no estoy en contra de ellos.
De hecho, un buen checklist puede evitar olvidos, ordenar revisiones y ayudar a repetir un proceso con cierta calidad.
El problema es cuando el checklist sustituye al criterio.
Cuando alguien marca “backup: sí” sin haber probado una restauración. Cuando se marca “usuarios revisados” sin mirar permisos reales. Cuando se marca “proveedor controlado” sin saber qué servicio presta. Cuando se marca “monitorización activa” y nadie recibe alertas útiles.
Ahí el control existe en papel, pero no en la realidad.
Tipos de controles que conviene entender
Para simplificar, me gusta pensar en cuatro tipos de controles:
- Preventivos: intentan evitar que el problema ocurra. Por ejemplo, MFA, hardening, segmentación o revisión de permisos.
- Detectivos: ayudan a enterarte de que algo pasa. Por ejemplo, logs, alertas, monitorización o detección de cambios.
- Correctivos: ayudan a corregir o contener el problema. Por ejemplo, restaurar un backup, revocar un acceso o aplicar un parche.
- De recuperación: ayudan a volver a operar. Por ejemplo, planes de continuidad, pruebas de restauración o procedimientos de contingencia.
Un entorno maduro no vive solo de controles preventivos.
Porque por mucho que intentes evitar fallos, alguno llegará.
La diferencia está en detectarlo pronto, responder bien y recuperarte con orden.
Ejemplo 1: backups
Un backup es uno de los controles más clásicos, pero tener copias no significa necesariamente tener capacidad real de recuperación.
Un control útil no se queda en comprobar que una copia se ejecuta: también permite saber qué se protege, qué queda fuera, si la copia puede restaurarse y cuánto tardaríamos en volver a operar.
La diferencia no es estética. Es operativa.
Cuando algo falla, no te salva haber escrito “backup: sí”. Te salva poder recuperar.
Ejemplo 2: accesos y permisos
Otro control típico es la revisión de accesos.
Pero de nuevo, puede quedarse en una casilla o convertirse en algo útil.
No basta con saber que un usuario existe.
Conviene saber:
- qué permisos tiene,
- si los necesita,
- si tiene privilegios elevados,
- si hay cuentas compartidas,
- si hay cuentas técnicas sin responsable,
- si se revisan bajas y cambios de puesto,
- si hay MFA donde debe haberlo,
- y si queda evidencia de la revisión.
La revisión de accesos no debería ser un trámite anual para sufrirlo.
Debería ayudar a reducir exposición.
Ejemplo 3: hardening
El hardening es otro buen ejemplo.
Puede sonar técnico, pero la idea es sencilla: reducir superficie de ataque.
No exponer lo que no hace falta. No usar configuraciones por defecto. No dejar servicios innecesarios. No permitir accesos débiles. No olvidar actualizaciones. No dar más permisos de los necesarios.
Un buen hardening no tiene que ser perfecto.
Tiene que ser razonable, mantenible y verificable.
De poco sirve una configuración muy estricta si nadie la entiende, nadie la documenta y se rompe en la primera actualización.
Ejemplo 4: monitorización
Monitorizar tampoco consiste en acumular gráficos.
La pregunta útil es más sencilla:
¿me ayuda a enterarme antes y responder mejor?
Si una alerta no llega a quien puede actuar, si nadie revisa el resultado o si una caída termina descubriéndola un usuario, el control existe técnicamente, pero aporta bastante menos de lo que parece.
Ejemplo 5: proveedores TIC
Con un proveedor ocurre algo parecido.
Guardar un contrato no basta para entender el control. Lo importante es conocer qué servicio sostiene, qué dependencia introduce, cómo se gestionan las incidencias y qué alternativas existirían si esa relación dejara de funcionar como esperábamos.
El control no es tener documentación sobre el proveedor. Es entender la dependencia y saber qué haríamos si falla.
DORA y los controles TIC
DORA no inventa los controles TIC.
Lo que hace es ordenar y elevar la exigencia en sectores regulados: gestión del riesgo TIC, incidentes, pruebas de resiliencia, terceros, continuidad, seguridad y evidencias.
Pero incluso fuera de un entorno regulado, la idea tiene sentido.
Un control debería poder explicarse:
- qué riesgo reduce,
- quién lo ejecuta,
- cada cuánto se revisa,
- qué evidencia deja,
- y qué pasa si falla.
Si no podemos explicar eso, quizá no tenemos un control. Tenemos una frase en un documento.
La evidencia no debería ser postureo
La palabra evidencia suena aburrida.
Pero cuando hay una incidencia, una auditoría o una revisión interna, agradecerás no depender de la memoria.
Una evidencia puede ser algo sencillo:
- un ticket cerrado,
- un informe de restauración,
- un log de alerta,
- una captura de configuración,
- un acta de revisión,
- un registro de cambio,
- o una nota fechada con qué se revisó y qué resultado tuvo.
No se trata de documentar por documentar.
Se trata de poder demostrar que algo se hizo y entender qué se aprendió.
Controles que nadie mira
También hay controles que existen, pero nadie mira.
Alertas que llegan a un buzón saturado. Informes automáticos que nadie lee. Revisiones que se firman sin revisar. Políticas que nadie aplica. Procedimientos que no se prueban. Dashboards que quedan bonitos pero no provocan ninguna acción.
Eso es peligroso.
Porque da sensación de control sin control real.
Y esa falsa tranquilidad puede ser peor que reconocer que algo está pendiente.
Cómo saber si un control aporta
Me gusta hacer preguntas sencillas:
- ¿Qué riesgo reduce este control?
- ¿Evita, detecta, corrige o ayuda a recuperar?
- ¿Quién lo ejecuta?
- ¿Cada cuánto?
- ¿Qué evidencia deja?
- ¿Qué pasa si no se hace?
- ¿Alguien revisa el resultado?
- ¿Es mantenible?
- ¿Está adaptado a la criticidad del activo?
Si no sabemos contestar, toca revisar el control.
Un control sencillo bien aplicado vale más que uno perfecto en papel
En tecnología a veces nos vamos a soluciones demasiado complejas.
Y hay casos donde hace falta sofisticación, claro.
Pero muchas mejoras reales vienen de controles sencillos bien aplicados:
- MFA donde toca,
- copias probadas,
- usuarios revisados,
- servicios innecesarios apagados,
- logs útiles,
- alertas que alguien atiende,
- documentación mínima actualizada,
- proveedores críticos identificados,
- y procedimientos que se han probado alguna vez.
No suena espectacular.
Pero funciona.
Conclusión
Los controles TIC no deberían ser decoración.
No deberían existir solo para rellenar una matriz, superar una revisión o dejar tranquilo a alguien en una reunión.
Un control tiene que ayudar a reducir un riesgo real.
A evitar, detectar, corregir o recuperar.
Y para eso tiene que estar conectado con la realidad: activos, proveedores, datos, usuarios, procesos, continuidad y operación.
Menos checklist vacío.
Más controles que alguien entiende, ejecuta, revisa y puede demostrar.
Ahí es donde la gestión TIC empieza a aportar de verdad.
Fuentes de referencia
- Reglamento (UE) 2022/2554 — Digital Operational Resilience Act (DORA), EUR-Lex
- EIOPA — Reglas bajo DORA sobre gestión del riesgo TIC, terceros e incidentes
- DGSFP — Reglamento de Resiliencia Operativa Digital (DORA)
¿Quieres seguir explorando?
Puedes descubrir más artículos, seguir mis publicaciones en LinkedIn o escribirme.