Matriz de riesgos ISO 27001: ejemplo práctico para descargar

La matriz de riesgos es, junto con la Declaración de Aplicabilidad, el documento que más mira un auditor de ISO 27001. Es donde se demuestra que la empresa conoce sus activos, entiende qué puede salir mal y ha decidido qué hacer al respecto. Y es también donde más PYMEs chilenas tropiezan, porque copian plantillas genéricas, asignan probabilidades sin criterio o llenan filas que nunca vuelven a tocar. Esta guía explica con un ejemplo concreto cómo construir una matriz de riesgos ISO 27001:2022 que resista una auditoría externa y, sobre todo, que sea útil para tomar decisiones reales de seguridad.

📐 Qué exige ISO 27001 sobre el análisis de riesgos

La cláusula 6.1.2 de ISO 27001:2022 obliga a la organización a:

Establecer y mantener criterios de riesgo de seguridad de la información (criterios de aceptación y criterios para realizar evaluaciones).
Asegurar que las evaluaciones de riesgo producen resultados consistentes, válidos y comparables.
Identificar los riesgos asociados a la pérdida de confidencialidad, integridad o disponibilidad.
Analizar los riesgos (consecuencias y probabilidad).
Evaluar los riesgos contra los criterios definidos y priorizarlos para tratamiento.

El estándar no impone una metodología específica: puedes usar ISO/IEC 27005, NIST SP 800-30, MAGERIT u otra, siempre que sea consistente y reproducible. En la práctica, para PYMEs y medianas empresas chilenas, una matriz cualitativa de probabilidad x impacto en escala de 1 a 5 es perfectamente aceptable.

📊 Definir las escalas (la decisión que el auditor revisa primero)

Antes de llenar una sola fila de la matriz, hay que definir las escalas. Aquí un ejemplo que funciona bien y que el auditor entiende rápido:

Escala de probabilidad

Nivel	Descripción	Frecuencia esperada
1	Muy baja	Menos de una vez cada 5 años
2	Baja	Una vez cada 2 a 5 años
3	Media	Una vez al año
4	Alta	Varias veces al año
5	Muy alta	Mensual o más frecuente

Escala de impacto

Nivel	Confidencialidad / Integridad / Disponibilidad
1	Insignificante: sin impacto operativo o legal
2	Menor: interrupción inferior a 4 horas o filtración no sensible
3	Moderado: interrupción de un día, multa baja, queja de cliente
4	Mayor: interrupción de varios días, multa significativa, pérdida de cliente clave
5	Crítico: interrupción prolongada, sanción gravísima Ley 21.719, pérdida de licencia o quiebre operacional

Cálculo del riesgo

Riesgo = Probabilidad × Impacto, con valores entre 1 y 25. Los criterios de aceptación se definen así:

1 a 4: riesgo bajo → aceptable.
5 a 9: riesgo moderado → tratar si es eficiente; revisar anualmente.
10 a 15: riesgo alto → tratar obligatoriamente con plan y plazo.
16 a 25: riesgo crítico → tratamiento inmediato con prioridad de dirección.

Documentar estos criterios antes de evaluar es lo que diferencia un análisis de riesgos serio de uno improvisado.

🗂️ Inventario de activos (paso previo)

La matriz se construye sobre un inventario de activos de información, no sobre activos físicos. En una empresa chilena típica de servicios, los activos suelen agruparse así:

Información: bases de datos de clientes, registros de RRHH, código fuente, contratos, propiedad intelectual.
Software: sistemas core (ERP, CRM, herramientas de cobranza), SaaS críticos, sitio web.
Hardware: servidores, notebooks, dispositivos móviles corporativos.
Servicios: conectividad, energía eléctrica, hosting cloud.
Personas: roles críticos cuya rotación o ausencia afecta operaciones.
Instalaciones: oficinas, datacenter, sala de servidores.

Cada activo tiene un propietario (no es el área de TI; es el dueño del proceso que usa el activo) y una clasificación (público, interno, confidencial, restringido).

📋 Ejemplo: matriz de riesgos para una software factory chilena de 45 personas

A continuación, un ejemplo realista con 12 activos típicos. Esta matriz no debe copiarse; sirve como referencia del nivel de detalle esperado.

#	Activo	Amenaza	Vulnerabilidad	P	I	Riesgo	Tratamiento	Control Anexo A
1	Base de datos de clientes (PII)	Acceso no autorizado	Cuentas compartidas en producción	4	5	20	Mitigar	A.5.15, A.8.2
2	Código fuente del SaaS	Filtración por ex-empleado	Repos sin revocación al egreso	3	4	12	Mitigar	A.5.11, A.6.5
3	Servidores cloud (AWS)	Compromiso por configuración errada	Falta de revisión de configuración	3	4	12	Mitigar	A.5.23, A.8.9
4	Cuentas Office 365	Phishing	Sin MFA en todos los usuarios	4	3	12	Mitigar	A.5.17, A.8.5
5	Notebooks corporativos	Robo o pérdida	Discos sin cifrado	3	3	9	Mitigar	A.7.10, A.8.24
6	Respaldos de BD	Pérdida de información	Restauración nunca probada	2	5	10	Mitigar	A.8.13
7	Pipeline CI/CD	Inyección de código malicioso	Secrets en repos sin gestor	2	4	8	Mitigar	A.8.25, A.8.28
8	Sitio web corporativo	Defacement / DDoS	Hosting sin WAF	2	2	4	Aceptar	—
9	Contratos con proveedores	Acceso a información sensible sin acuerdo	NDAs firmados pero sin cláusulas de seguridad	3	3	9	Mitigar	A.5.19, A.5.20
10	Personal clave (CTO, líderes técnicos)	Indisponibilidad prolongada	Falta de respaldo de conocimiento	2	4	8	Mitigar	A.5.30, A.6.3
11	Conectividad a internet	Caída de proveedor	Un único ISP sin redundancia	3	4	12	Transferir	A.5.30, contrato SLA
12	Datos personales tratados por encargo	Sanción Ley 21.719	DPA con cliente desactualizado	2	5	10	Mitigar	A.5.34, A.5.20

Algunos detalles que un auditor revisará en este tipo de matriz:

Coherencia entre el riesgo y el tratamiento: el riesgo crítico #1 (20) debe tener un plan con plazos cortos y responsables nombrados. Si aparece como "aceptar", hay un problema.
Trazabilidad al SoA: cada control mencionado en la columna "Control Anexo A" debe aparecer como "incluido" en la Declaración de Aplicabilidad con justificación.
Riesgos legales explícitos: en Chile, riesgos como el #12 (sanción bajo Ley 21.719) o los relativos a la Ley 21.663 deben estar en la matriz, no fuera de ella.

🛠️ Cómo decidir el tratamiento

Para cada riesgo, ISO 27001 reconoce cuatro estrategias:

Mitigar: implementar controles para reducir probabilidad y/o impacto. Es la estrategia mayoritaria.
Transferir: contratar seguros, derivar a un proveedor con SLA, contratar servicios gestionados.
Evitar: dejar de realizar la actividad que genera el riesgo.
Aceptar: documentar y aceptar el riesgo residual cuando esté dentro del criterio de aceptación.

La aceptación de un riesgo alto debe ser firmada por la dirección, no por el responsable de TI. Esa firma es lo que un auditor pedirá ver.

🔁 Riesgo inherente vs. riesgo residual

Una matriz madura distingue dos momentos:

Riesgo inherente: probabilidad e impacto antes de considerar los controles ya implementados.
Riesgo residual: probabilidad e impacto después de aplicar los controles.

En el primer ciclo, muchas empresas chilenas saltan directo al residual. Aceptable, pero la práctica recomendada para el segundo ciclo es agregar la columna inherente; permite mostrar al auditor la eficacia de los controles y, en revisión por la dirección, justificar la inversión hecha.

⚠️ Errores frecuentes en la matriz de riesgos

Probabilidades e impactos asignados "a ojo" sin que las escalas estén documentadas. El auditor pedirá ver los criterios.
Ningún riesgo "alto" o "crítico". Sospechosa: el evaluador subestimó por miedo a tener que tratarlos.
La matriz no se actualiza tras incidentes ni cambios significativos. La cláusula 8.2 obliga a re-evaluar.
Activos sin propietario o todos a nombre del responsable del SGSI.
Tratamiento sin plazo ni responsable. Una matriz que no se traduce en un plan de tratamiento con fechas y dueños es decoración.
Inconsistencia con la SoA: controles "no aplicables" en la SoA pero referenciados como tratamiento en la matriz.

📌 Conclusión

La matriz de riesgos no es un documento que se hace una vez y se archiva: es el motor del SGSI. Define qué controles importan, justifica la inversión en seguridad y orienta las decisiones de la dirección. Una matriz construida con escalas claras, basada en un inventario real de activos y vinculada al plan de tratamiento es lo que diferencia a una organización que gestiona sus riesgos de seguridad de la información de una que solo cumple un trámite ISO.

El ejercicio del primer año cuesta. Pero al segundo ciclo, mantenerla actualizada se vuelve parte natural de la operación: cada vez que cambia un proveedor crítico, entra un sistema nuevo o se incorpora un cliente que aporta nuevos datos sensibles, la matriz se actualiza. Esa disciplina es lo que el certificador busca y lo que efectivamente reduce los incidentes de seguridad.

🚀 ¿Necesitas ayuda con tu matriz de riesgos ISO 27001?

En FideliNorm apoyamos a empresas chilenas a construir matrices de riesgos coherentes, vinculadas al plan de tratamiento y a la Declaración de Aplicabilidad, con trazabilidad auditable. Nuestra plataforma facilita mantener viva la matriz tras cada cambio relevante en la empresa. Si quieres pasar de la planilla estática a un sistema operativo de gestión de riesgos, conversemos.