Gestión de riesgos de TI: el registro que tu dirección debería exigir

Pregúntale a tu área de TI si están seguros. Casi siempre la respuesta es "sí". Ahora pídeles el registro de riesgos. Si no lo tienen, no tienes seguridad — tienes una corazonada bien intencionada.

El registro de riesgos es el artefacto que separa la seguridad que se gestiona de la que se supone. Y es una de las columnas tanto de SOC 2 como de ISO 27001.

Qué es, en concreto

Un documento vivo que lista, para cada riesgo relevante: qué es, su probabilidad, su impacto, quién es el dueño, y qué se está haciendo al respecto (aceptarlo, mitigarlo, transferirlo o evitarlo). No es un PDF que se hace una vez y se archiva: se revisa y se actualiza, típicamente al menos una vez al año, en la evaluación de riesgos formal.

Por qué tu dirección debería exigirlo

Porque convierte una conversación imposible —"¿estamos seguros?"— en una que se puede tomar: "estos son nuestros diez riesgos principales, ranqueados, y esto estamos haciendo con cada uno." Deja de ser fe y se vuelve una decisión de asignación de recursos: dónde invertir, qué aceptar conscientemente, qué no. Un director no necesita entender el detalle técnico; necesita ver la lista priorizada y los dueños.

¿Cómo se ve un registro de riesgos bien hecho?

No hace falta software especial para empezar. Una hoja bien estructurada funciona, siempre que cada riesgo tenga estos campos:

• Descripción concreta. "Ransomware cifra el servidor de archivos y los respaldos conectados", no "ciberataques".
• Activo o proceso afectado y quién depende de él.
• Probabilidad e impacto, cada uno en una escala del 1 al 5, con criterios escritos para que dos personas califiquen igual.
• Nivel de riesgo inherente: probabilidad × impacto, de 1 a 25.
• Controles existentes y el riesgo residual que queda después de ellos.
• Tratamiento elegido: mitigar, transferir, evitar o aceptar, con fecha y responsable.
• Dueño del riesgo: una persona con nombre, no "TI".
• Fecha de la última revisión.

¿Cómo se hace la evaluación, paso a paso?

1. Define el criterio antes de calificar. Qué significa impacto 5 para tu empresa: días sin facturar, una multa, la pérdida de un cliente clave. Sin criterio escrito, cada quien califica con su propio miedo.
2. Fija tu apetito de riesgo. Por ejemplo, todo lo que resulte en 15 o más necesita un plan de tratamiento; lo que quede en 6 o menos puede aceptarse formalmente.
3. Identifica los riesgos con las áreas, no solo con TI. Finanzas, operación y ventas conocen dependencias que sistemas no ve.
4. Califica, prioriza y asigna dueño. El resultado es un mapa de calor y una lista ordenada.
5. Decide el tratamiento y documenta la aceptación. Aceptar un riesgo es válido, siempre que lo decida alguien con autoridad y quede por escrito.
6. Revisa al menos una vez al año y cada vez que cambie algo importante: un sistema nuevo, una adquisición, un incidente.

¿Qué piden SOC 2 e ISO 27001 exactamente?

En SOC 2, la evaluación de riesgos forma parte de los criterios comunes (la serie CC3): identificar y analizar riesgos, considerar el riesgo de fraude y evaluar los cambios que puedan afectar a los controles. En ISO 27001, las cláusulas 6.1.2 y 6.1.3 piden un proceso definido de evaluación y tratamiento de riesgos, y su resultado alimenta la Declaración de Aplicabilidad: el documento que justifica qué controles del Anexo A aplicas y por qué. El registro de riesgos es la columna vertebral de ambos.

Errores que vuelven inútil un registro de riesgos

• Riesgos genéricos. "Falla de TI" no se puede tratar ni medir. Si no puedes decir qué control lo reduce, está mal escrito.
• Confundir vulnerabilidad con riesgo. "El servidor no tiene parches" es una vulnerabilidad; el riesgo es lo que pasa si alguien la explota y qué le cuesta al negocio.
• Solo riesgos técnicos. La salida de la única persona que sabe administrar el ERP es un riesgo tan real como un ransomware.
• Sin dueño con nombre. Un riesgo asignado a "el área" no lo atiende nadie.
• Aceptar sin firma. Si la dirección no aprobó por escrito aceptar un riesgo, en la práctica nadie lo aceptó: simplemente se ignoró.
• Hacerlo una vez. Un registro que no se ha revisado en dos años describe una empresa que ya no existe.

¿Tu registro pasaría esta lista? Si no existe todavía, mejor: empiezas sin arrastrar ninguno de estos vicios.

El beneficio que no esperabas

El mismo registro que te da control interno es evidencia directa para SOC 2 e ISO 27001 — ambos exigen gestión de riesgos formal. Haces el trabajo una vez y sirve para gobernar y para certificar. Es, otra vez, la lógica del andamiaje: lo que endurece tu operación es lo mismo que te acredita ante terceros.