← Volver al blog Gobierno de TI

Gestión de riesgos tecnológicos: método y errores [2026]

Gestionar riesgos tecnológicos es decidir, por escrito y con dueño, qué le puede pasar a la tecnología de la que depende tu operación, qué haría eso al negocio y qué se va a hacer al respecto. No es un mapa de calor ni una lista de amenazas: es un conjunto de decisiones —mitigar, transferir, evitar o aceptar— que alguien con autoridad firma y que se revisan cada trimestre.

Esta guía da el método completo: por qué sin inventario de activos no hay gestión posible, las ocho familias de riesgo tecnológico con ejemplos, cómo valorar sin inventar números, las cuatro decisiones de tratamiento, el riesgo de terceros —que es el que más crece— y qué significan RTO y RPO cuando llega el día malo.

Qué es un riesgo tecnológico y qué no

Un riesgo tecnológico bien escrito tiene tres partes y una consecuencia de negocio. Sin las tres no se puede valorar ni tratar:

Y lo que no es un riesgo tecnológico: un problema que ya está ocurriendo —eso es un incidente o un hallazgo, y se trata con una acción correctiva, no con una apreciación de riesgo—; una tarea pendiente disfrazada —«riesgo de no haber actualizado el servidor» es un pendiente con dueño—; y una amenaza genérica sin activo ni consecuencia, que no se puede priorizar contra nada.

Conviene distinguir también dos ámbitos que se mezclan. El riesgo de seguridad de la información —confidencialidad, integridad y disponibilidad— es una parte, y es la que trata un SGSI ISO 27001. El riesgo tecnológico total incluye además obsolescencia, dependencia de un proveedor único, deuda técnica, mala elección de un sistema y pérdida de conocimiento: cosas que no aparecen en ningún Anexo A y que hunden un negocio igual.

Sin inventario de activos no hay gestión de riesgos

Es el paso que se salta y el que explica por qué la mayoría de las matrices de riesgo no sirven: no se puede valorar la pérdida de algo que nadie ha listado. Un inventario útil no es un listado de equipos de cómputo; es una lista de lo que sostiene la operación, con seis columnas:

1. Activo —sistema, base de datos, servicio contratado, integración, repositorio de documentos—.
2. Qué proceso de negocio depende de él y cuántas personas lo usan.
3. Qué información contiene y de qué nivel de clasificación.
4. Dónde vive: servidor propio, centro de datos, servicio en la nube, equipo de una persona.
5. Dueño, con nombre — el del negocio, no el de sistemas.
6. Cuánto aguanta caído antes de que duela de verdad.

La última columna es la que convierte el inventario en herramienta de decisión: ordena la lista por criticidad real y no por tamaño de la factura. Una hoja de cálculo que nadie considera «un sistema» puede ser el activo más crítico de una empresa, y se descubre justo en esa columna.

Ocho familias de riesgo tecnológico

Una taxonomía corta evita el efecto lista infinita y ayuda a que nadie olvide un frente completo. Ocho familias, con el ejemplo que más veces hemos visto en cada una:

• 1. Disponibilidad y continuidad. Caída de un sistema, del enlace o del proveedor de nube. Ejemplo típico: respaldos configurados que nunca se han probado restaurando.
• 2. Seguridad y ataque deliberado. Ataque de rescate, robo de credenciales, fraude por suplantación de un directivo. Ejemplo típico: la misma contraseña reutilizada entre un servicio personal y uno corporativo.
• 3. Integridad y calidad del dato. Información duplicada, criterios que cambiaron sin registro, catálogos con tres versiones. Ejemplo típico: reportes de dirección que no cuadran entre áreas.
• 4. Terceros y cadena de suministro. Un proveedor que falla, que sube el precio o que cierra; su propio proveedor detrás. Ejemplo típico: una integración crítica montada por un desarrollador externo que ya no responde.
• 5. Cumplimiento y contractual. Tratamiento de datos personales fuera de la finalidad informada, información de cliente bajo confidencialidad en herramientas no aprobadas, licencias de software vencidas.
• 6. Obsolescencia y deuda técnica. Sistemas sin soporte, versiones que ya no reciben actualizaciones, hardware que no se puede reemplazar. Ejemplo típico: la aplicación que solo corre en una versión de sistema operativo que ya nadie parchea.
• 7. Personas y conocimiento. Un solo administrador con las llaves de todo, procesos que viven en la cabeza de alguien, accesos heredados de gente que ya no está.
• 8. Proyecto y cambio. Migraciones sin vuelta atrás, implantaciones que dejan dos sistemas en paralelo, cambios en producción sin ventana ni plan de reversión. La elección de un sistema equivocado pertenece aquí, y se previene antes: cómo se decide está en la guía de cómo elegir un ERP.

Una familia nueva que conviene añadir explícitamente: el riesgo introducido por la IA —información que sale en las entradas, decisiones automatizadas sin supervisión, dependencia de un modelo que cambia por debajo—. No encaja limpiamente en ninguna de las ocho y se pierde si no se nombra. El marco para tratarlo está en la guía de gobernanza de IA.

El método, en 7 pasos

El proceso es el de ISO 31000 aplicado a tecnología, y coincide con el que exige la cláusula 6.1 de ISO/IEC 27001 para la parte de seguridad de la información. Siete pasos, y ninguno se salta:

1. Establecer el contexto y los criterios. Qué entra en el ejercicio, qué escalas se usan y —esto es lo que casi siempre falta— qué nivel de riesgo la dirección está dispuesta a aceptar. Sin ese umbral, la matriz no puede decidir nada.
2. Identificar. Recorrer el inventario activo por activo y escribir los riesgos con sus cuatro partes. Se hace con los dueños del proceso, no en un escritorio.
3. Analizar. Estimar probabilidad e impacto con las escalas definidas antes, no ajustadas después para que el resultado quede cómodo.
4. Evaluar. Comparar cada riesgo contra el umbral y ordenar. Aquí sale la lista corta de los que se van a tratar este año.
5. Tratar. Una decisión por riesgo —mitigar, transferir, evitar, aceptar—, con control, dueño, fecha y costo.
6. Registrar y comunicar. El registro de riesgos es un documento vivo con versión y fecha; el riesgo residual que queda lo acepta la dirección por escrito.
7. Seguir y revisar. Trimestral para los de nivel alto, anual para el resto, y siempre que haya un cambio: sistema nuevo, proveedor nuevo, incidente, reorganización.

Si quieres profundizar en el método, las referencias son cortas: ISO 31000 para el marco general de gestión del riesgo, ISO/IEC 27005 para la apreciación aplicada a la seguridad de la información, y ISO 22301 para la parte de continuidad del negocio. Ninguna de las tres se certifica de forma directa en el sentido en que se certifica un sistema de gestión, y las tres se pueden usar sin comprar un proyecto.

Cómo valorar sin inventar números

El defecto más común de una matriz de riesgos es que sus números no significan nada: un 4 en probabilidad y un 3 en impacto que nadie puede justificar. La cura es definir las escalas con criterios observables antes de valorar nada, y pegarlas al lado de la matriz.

Dos prácticas que hacen defendible la valoración. La primera: valorar en grupo y registrar el desacuerdo; cuando dos dueños de proceso difieren en dos puntos, ahí hay información que ninguna matriz individual captura. La segunda: valorar el riesgo inherente y el residual por separado —antes y después de los controles que ya existen—, porque si solo se registra el residual, nadie puede ver qué control lo está sosteniendo ni qué pasaría si se retira.

Las cuatro decisiones de tratamiento

Cada riesgo por encima del umbral recibe una decisión, y solo hay cuatro. Escribir «se monitoreará» no es una de ellas:

• Mitigar. Implantar un control que baje probabilidad o impacto. Es la más usada y la que exige más disciplina: control concreto, dueño, fecha y costo. Un control sin fecha es una intención.
• Transferir. Pasar parte de la consecuencia a un tercero: un seguro, una cláusula de nivel de servicio con penalización, un contrato de soporte. Ojo: se transfiere la consecuencia económica, nunca la responsabilidad frente al cliente o frente a la ley.
• Evitar. No hacer la actividad que genera el riesgo, o sustituirla: apagar el sistema sin soporte, dejar de tratar un dato que no se necesita, cancelar una integración. Es la opción más subestimada y a menudo la más barata.
• Aceptar. Decidir vivir con él, por escrito y con firma de quien tiene autoridad para hacerlo. Un riesgo aceptado se registra, se comunica y se revisa; no desaparece del registro.

La prueba de que un tratamiento es real: tiene presupuesto o tiene firma. Si no cuesta nada y nadie lo aceptó, lo que hay en la casilla es una aspiración.

Proveedores y servicios en la nube: el riesgo que más crece

La superficie de riesgo de una empresa mediana ya no está adentro: está repartida entre veinte servicios contratados, cada uno con su propia cadena de proveedores. Y casi ninguno se evaluó antes de firmar. Lo mínimo por cada proveedor que toque información o sostenga un proceso:

1. Qué proceso sostiene y qué pasa si no está mañana.
2. Qué información suya trata y de qué clasificación.
3. Qué compromiso de servicio tiene por contrato, y qué compensación —una cláusula sin penalización es una promesa.
4. Quién está detrás de él: el subencargado que también trata tus datos.
5. Cómo te avisa de un incidente y en cuánto tiempo.
6. Qué puedes exportar y cómo sales. La dependencia se negocia al firmar, no el día que quieres irte.
7. Cuándo se revisa: al menos una vez al año, y siempre que cambie el alcance del servicio.

Y la pregunta de concentración, que casi nadie hace: ¿cuántos de tus procesos críticos dependen del mismo proveedor? Una caída de un único servicio que sostiene el correo, los archivos y la autenticación no es un riesgo de disponibilidad; es un riesgo de continuidad de toda la empresa, y se trata distinto.

RTO, RPO y la prueba que casi nadie hace

Dos números por proceso crítico, decididos por el negocio y no por sistemas, convierten una conversación difusa en un requisito técnico:

• RTO (recovery time objective): cuánto tiempo puede estar caído el proceso antes de que el daño sea inaceptable. Define la arquitectura de recuperación y su costo.
• RPO (recovery point objective): cuánta información puedes permitirte perder, medida en tiempo. Define la frecuencia de respaldo. Un RPO de cuatro horas con respaldo diario es una contradicción escrita.

Y la prueba que separa un plan de continuidad real de uno decorativo: restaurar de verdad. No verificar que el respaldo «corrió», sino levantar el sistema desde cero, con el respaldo, cronometrando cuánto tardó y comprobando que la información está completa. Hasta que eso se hace, el respaldo es una hipótesis. Es, además, el hallazgo más frecuente en una primera auditoría de seguridad de la información: existe la política de respaldos, existe el registro de ejecución, y no existe ni una restauración probada.

El ejercicio se documenta como cualquier otro proceso de la empresa —con responsable, pasos y registro—, siguiendo el mismo estándar del manual de procedimientos. Un plan de recuperación que solo vive en la cabeza del administrador es exactamente el riesgo número siete de la taxonomía.

El mito: el mapa de calor no es gestión de riesgos

El entregable estrella de casi todos los ejercicios de riesgo es una cuadrícula de colores. Se presenta en el comité, se aplaude y no cambia nada. El mapa de calor es una vista, y tiene tres límites que conviene decir en voz alta:

• Esconde la cola. Los eventos de probabilidad muy baja e impacto extremo quedan en una esquina discreta y son justo los que quiebran una empresa.
• Invita a promediar. Un riesgo con impacto legal 5 y operativo 2 aparece como 3,5 y desaparece de la vista.
• No contiene ninguna decisión. Un color no dice quién hace qué, para cuándo y con qué presupuesto.

Lo que sí es el entregable: un registro de riesgos con una fila por riesgo —descripción con sus cuatro partes, valoración inherente, controles existentes, valoración residual, decisión, dueño, fecha, estado— y un acta de aceptación del riesgo residual firmada por la dirección. Si de un ejercicio de riesgos no sale una lista de acciones con nombre y fecha, no hubo gestión: hubo una presentación.

8 errores que se repiten

1. Empezar sin inventario. Se valoran riesgos sobre activos que nadie listó y se olvidan los dos más críticos.
2. Escribir riesgos genéricos. «Riesgo de ciberataque» no se puede valorar, priorizar ni tratar.
3. Escalas sin criterios. Números que nadie puede justificar producen una matriz que nadie defiende ante un auditor.
4. Hacerlo solo con el área de sistemas. El impacto lo conoce el negocio; sistemas conoce la probabilidad técnica. Los dos, o el ejercicio queda sesgado.
5. Confundir riesgo con pendiente. Si ya sabes que hay que actualizar un servidor, eso es una tarea con dueño, no un riesgo por apreciar.
6. Tratar todo. Sin umbral de aceptación, la lista de acciones sale con cuarenta líneas y no se ejecuta ninguna.
7. Aceptar riesgos sin firma. La aceptación tácita no existe: el día del incidente nadie la asume.
8. Hacerlo una vez. Un registro de riesgos sin revisión trimestral envejece en un semestre y deja de reflejar la empresa.

Ejemplo resuelto: tres riesgos de una empresa de servicios

Así se ven tres filas de un registro de riesgos de una empresa de servicios profesionales de alrededor de 80 personas, con la operación en un sistema administrativo, un repositorio de documentos en la nube y varias integraciones:

Tres filas bien escritas ordenan un trimestre entero. Nótese que ninguna dice «se monitoreará», que las tres tienen dueño y fecha, y que la tercera —la más frecuente hoy— no se resuelve con tecnología sino con una decisión y un documento: cómo se escribe está en la guía de la política de uso de IA.

Cuando este ejercicio se formaliza dentro de un sistema de gestión, deja de ser un proyecto anual y pasa a ser un proceso con evidencia. En el SGSI ISO/IEC 27001:2022 completo que implantamos en una empresa de software —34 políticas, 25 procedimientos y 46 formatos—, la apreciación y el tratamiento del riesgo son un procedimiento con sus formatos, no una hoja suelta que se rehace cada año desde cero. Ahí está la diferencia entre medir el riesgo y gestionarlo.

Preguntas frecuentes

Conclusión

La gestión de riesgos tecnológicos falla por arriba y por abajo: por arriba, cuando produce una presentación de colores sin decisiones; por abajo, cuando se intenta sin saber qué activos sostienen la operación. Entre esos dos extremos hay un método sencillo que cabe en siete pasos y que una empresa mediana puede ejecutar con sus propias personas.

Si vas a arrancar, tres decisiones ordenan el resto: levanta el inventario de activos con la columna de cuánto aguanta caído, define el umbral de riesgo que la dirección acepta antes de valorar nada, y prueba una restauración de verdad este trimestre. Las tres se hacen sin comprar nada y cambian lo que la empresa sabe de sí misma.