Qué es un plan de tratamiento de riesgos y dónde encaja en ISO 27001
Evaluar riesgos no protege una organización por sí solo. Es común disponer de una matriz de riesgos detallada con colores, probabilidades e impactos y continuar operando con las mismas vulnerabilidades sin resolver. El valor real de la gestión de riesgos aparece cuando la organización convierte esa evaluación en decisiones ejecutables y asigna recursos. Ese puente operativo es el plan de tratamiento de riesgos (Risk Treatment Plan).
En la norma ISO/IEC 27001:2022, el tratamiento de riesgos se fundamenta en dos cláusulas principales:
- Cláusula 6.1.3: Requisito de planificación donde se define el proceso de tratamiento de riesgos, la selección de controles, la comparación con el Anexo A y la preparación de la Declaración de Aplicabilidad (SoA).
- Cláusula 8.3: Requisito operativo donde se exige ejecutar formalmente el plan de tratamiento de riesgos de seguridad de la información y conservar la información documentada de los resultados.
Para comprender cómo se realiza el análisis inicial de amenazas e impactos antes del tratamiento, puedes consultar nuestra guía sobre la evaluación y tratamiento de riesgos y la visión global de la planificación del SGSI.
Diferencias entre Registro de Riesgos, SoA y Plan de Tratamiento
Aunque pueden integrarse dentro de un mismo software GRC, es indispensable diferenciar el propósito de estos tres artefactos clave del qué es un SGSI:
| Artefacto | Pregunta Central | Contenido Principal |
|---|---|---|
| Registro de Riesgos (Risk Register) | ¿Qué riesgos amenazan a la organización? | Escenarios de amenaza, vulnerabilidades, activos afectados, nivel de riesgo inherente y controles actuales. |
| Declaración de Aplicabilidad (SoA) | ¿Qué controles del Anexo A aplican y por qué? | Lista de los 93 controles de ISO 27001:2022, justificación de inclusión/exclusión y estado general de implementación. |
| Plan de Tratamiento de Riesgos (RTP) | ¿Qué acciones concretas realizaremos para mitigar los riesgos? | Acciones específicas, responsables asignados, presupuestos, fechas límite, dependencias y nivel de riesgo residual esperado. |
Las 4 opciones de tratamiento de riesgo
Basándose en ISO/IEC 27005:2022 e ISO 31000:2018, la organización debe seleccionar una opción de tratamiento adecuada para cada riesgo que supere el criterio de aceptación:
Modificar / Reducir el riesgo
Aplicar controles organizacionales, técnicos o físicos para disminuir la probabilidad del evento o reducir su impacto (ejemplo: desplegar autenticación multifactor MFA y soluciones PAM).
Evitar el riesgo
Decidir no iniciar o descontinuar la actividad que genera la exposición al riesgo (ejemplo: retirar un servicio software legado sin soporte de seguridad que no puede ser aislado).
Compartir / Transferir el riesgo
Transferir o compartir parte del impacto financiero o contractual con terceros mediante seguros de ciberriesgo o cláusulas contractuales con proveedores. Nota: transferir no elimina la responsabilidad reputacional o legal.
Retener / Aceptar el riesgo
Mantener el nivel de riesgo de forma consciente y justificada si se encuentra dentro de los criterios de gobernanza aprobados por la alta dirección. Nota: aceptar no es ignorar el riesgo.
Metodología de 15 pasos: del riesgo evaluado a la verificación de eficacia
Para estructurar el plan de tratamiento siguiendo la implementación ISO 27001 paso a paso, se recomienda aplicar el siguiente ciclo riguroso de 15 pasos:
Partir de los riesgos evaluados
Seleccionar los escenarios del registro de riesgos que superan el nivel de tolerancia definido.
Elegir la opción de tratamiento
Determinar formalmente si el riesgo se reducirá, evitará, compartirá o retendrá.
Determinar los controles necesarios
Identificar las medidas organizativas o técnicas requeridas para materializar la decisión.
Comparar con el Anexo A de ISO 27001
Verificar contra los 93 controles de referencia para asegurar que no se hayan omitido salvaguardas estándar.
Actualizar la SoA
Registrar las decisiones de inclusión de controles y sus razones en la Declaración de Aplicabilidad.
Convertir los controles en acciones verificables
Dividir el diseño del control en tareas concretas con entregables medibles (evitar descripciones vagas).
Asignar los propietarios (Owners)
Designar responsables claros de la gobernanza del riesgo, la custodia del control y la ejecución de tareas.
Asignar recursos y presupuesto
Garantizar las horas de equipo, licencias o contratación de terceros necesarios para ejecutar las acciones.
Identificar dependencias
Mapear qué tareas requieren de prerrequisitos técnicos u organizativos previos para evitar retrasos ficticios.
Establecer plazos y fechas límite
Fijar un cronograma de implantación priorizado según la severidad del riesgo y la capacidad del equipo.
Definir la evidencia objetiva esperada
Especificar qué registros, configuraciones, contratos o pruebas demostrarán la finalización de la tarea.
Definir el criterio de eficacia
Establecer la métrica que comprobará si el control reduce efectivamente la probabilidad o el impacto del riesgo.
Reevaluar el riesgo residual
Estimar el nivel de riesgo resultante que permanecerá una vez implantadas y probadas las acciones.
Obtener la aceptación del riesgo residual
Presentar el riesgo residual al propietario del riesgo (Risk Owner) para su aprobación formal.
Supervisar, monitorizar y revisar
Realizar un seguimiento periódico del avance de las acciones, gestionando bloqueos y revisando el estado en las reuniones de seguimiento.
Asignación de roles: Risk Owner vs Control Owner vs Action Owner
Para garantizar la gobernanza del plan de tratamiento, es vital diferenciar tres figuras de responsabilidad que no siempre recaen en la misma persona:
| Rol | Responsabilidad Principal | Ejemplo de Cargo |
|---|---|---|
| Risk Owner (Propietario del Riesgo) | Tiene la autoridad y responsabilidad organizativa para gestionar el riesgo y aceptar el riesgo residual. | Director de Operaciones / CTO / CISO / Director Financiero. |
| Control Owner (Propietario del Control) | Responsable de garantizar el diseño, mantenimiento y correcto funcionamiento continuo de la salvaguarda. | Responsable de IAM / Jefe de Infraestructura / Responsable de Privacidad. |
| Action Owner (Responsable de Acción) | Ejecuta la tarea técnica o administrativa concreta fijada en el plan de tratamiento dentro del plazo. | Ingeniero de Ciberseguridad / Administrador de Sistemas / Consultor. |
Riesgo residual y gobernanza de aceptación
El riesgo residual es el nivel de riesgo que permanece tras la aplicación del tratamiento de seguridad. Implementar un control no elimina automáticamente el riesgo a cero.
Criterio de gobernanza: El propietario del riesgo (Risk Owner) debe aceptar explícitamente el riesgo residual estimado. Si el riesgo residual excede los niveles de tolerancia de la organización, se debe diseñar un tratamiento complementario o aplicar controles compensatorios temporales.
Además, la aceptación del riesgo no es una decisión permanente: debe revisarse periódicamente ante cambios en el contexto de la organización tal como se especifica en la guía de interpretar y auditar contexto y alcance.
Ejemplos prácticos de fichas de tratamiento
Ejemplo 1 — Tratamiento de cuentas privilegiadas
Escenario: Riesgo de acceso no autorizado a bases de datos críticas por compromiso de credenciales de administradores.
Decisión: Modificar / Reducir el riesgo.
Controles asociados: MFA para acceso administrativo, solución PAM y registros de auditoría (controles A.5.15 y A.8.5 de ISO 27002).
Acción concreta: Integrar la plataforma PAM con el directorio activo corporativo y desplegar MFA obligatorio a 15 administradores de IT.
Evidencia: Configuración del servidor PAM, reporte de enrolamiento de usuarios y logs de auditoría.
Ejemplo 2 — Tratamiento de dependencia de proveedores cloud
Escenario: Riesgo de interrupción del servicio SaaS por indisponibilidad prolongada del proveedor cloud.
Decisión: Modificar + Compartir.
Controles asociados: Acuerdos SLA, política de copias de seguridad en repositorios inmutables aislados y plan de contingencia.
Ejemplo 3 — Tratamiento de software legado (Legacy)
Escenario: Aplicación de facturación sin soporte del fabricante con vulnerabilidades no parcheables.
Decisión: Evitar a medio plazo (migración en 6 meses); Modificar a corto plazo (aislamiento en VLAN dedicada con firewall y monitorización estrecha como control compensatorio).
Plantilla práctica y herramientas para gestionar el plan
El plan de tratamiento puede gestionarse mediante hojas de cálculo (Excel), gestores de tareas de ingeniería (Jira) o plataformas especializadas de GRC:
| Herramienta | Ventajas | Riesgos / Limitaciones |
|---|---|---|
| Hoja de cálculo (Excel) | Sencillo de iniciar, flexible, sin costes adicionales de licencias. | Falta de control de versiones, problemas de concurrencia y débil trazabilidad. |
| Jira / Ticketing | Fácil seguimiento de tareas, fechas límite, responsables y estados de trabajo. | Riesgo de perder el vínculo directo con la evaluación de riesgos si no se usan IDs relacionados. |
| Software GRC especializado | Trazabilidad completa entre Riesgo, SoA, Controles, Acciones, Evidencias y Aprobaciones. | Mayor coste de licenciamiento y curva de aprendizaje para la organización. |
Cómo auditar el plan de tratamiento y métricas clave de desempeño
Al evaluar el plan de tratamiento en el proceso de evaluación del desempeño, el auditor seleccionará una muestra de riesgos y seguirá la trazabilidad completa:
Riesgo Evaluado → Decisión de Tratamiento → Controles Seleccionados → SoA → Acciones → Responsable → Evidencias de Ejecución → Riesgo Residual Aceptado.
Métricas eficaces para el Plan de Tratamiento
- Porcentaje de acciones de tratamiento vencidas: Tareas no finalizadas dentro de la fecha límite acordada.
- Porcentaje de riesgos residuales pendientes de aceptación: Riesgos tratados cuyas decisiones residuales aún no han sido aprobadas por los Risk Owners.
- Tasa de reaparición de riesgos: Número de riesgos cerrados que han vuelto a superar el umbral de tolerancia por falta de eficacia del control.
Errores frecuentes al gestionar el plan de tratamiento
| Error Habitual | Impacto en el SGSI | Solución Recomendada |
|---|---|---|
| Confundir el Plan de Tratamiento con la Declaración de Aplicabilidad (SoA). | La SoA solo justifica aplicabilidad; no organiza tareas, plazos ni responsables. | Mantener el plan de tratamiento como el instrumento ejecutable del SGSI. |
| Definir acciones vagas como "mejorar la seguridad de la red". | Imposibilidad de auditar si la tarea se ha completado o de medir su éxito. | Redactar acciones concretas con criterios de aceptación y evidencias objetivas. |
| Asignar todas las tareas de tratamiento al departamento de Ciberseguridad/IT. | Falta de compromiso de las áreas de negocio y cuellos de botella operativos. | Involucrar a los líderes de proceso como Risk Owners de sus respectivos activos. |
| Asumir que cerrar una tarea equivale a haber eliminado el riesgo. | Genera una falsa sensación de seguridad sin verificar la eficacia del control. | Medir la eficacia operativa y reevaluar el riesgo residual tras la implantación. |
Preguntas frecuentes (FAQ)
¿ISO/IEC 27001 exige obligatoriamente un Plan de Tratamiento de Riesgos?
Sí. Las cláusulas 6.1.3 y 8.3 exigen definir, implementar y mantener un plan de tratamiento de riesgos de seguridad de la información, conservando información documentada que demuestre su ejecución.
¿Es obligatorio implementar los 93 controles del Anexo A en el plan?
No. La organización debe seleccionar únicamente los controles requeridos para tratar los riesgos identificados. El Anexo A se utiliza como lista de verificación para comparar y justificar cualquier exclusión en la SoA. Para más detalle, consulta la guía de controles organizacionales.
¿Quién debe firmar la aceptación del riesgo residual?
Los propietarios del riesgo (Risk Owners) designados según la estructura de gobernanza de la empresa. Para riesgos de impacto crítico, la aprobación suele recaer en la Alta Dirección o el CISO.
Checklist de verificación del plan de tratamiento
- [ ] Evaluación de riesgos finalizada e hitos de tolerancia definidos.
- [ ] Opción de tratamiento (reducir, evitar, compartir, retener) formalizada para cada riesgo.
- [ ] Selección de controles comparada contra los 93 controles del Anexo A de ISO 27001:2022.
- [ ] Declaración de Aplicabilidad (SoA) actualizada con las razones de inclusión.
- [ ] Acciones concretas de tratamiento redactadas con entregables verificables.
- [ ] Propietarios del riesgo (Risk Owners) y responsables de acción (Action Owners) asignados.
- [ ] Recursos, presupuestos y dependencias técnicas identificados.
- [ ] Fechas de inicio y finalización establecidas de forma realista.
- [ ] Criterios de evidencia y eficacia operativa especificados para cada acción.
- [ ] Reevaluación del riesgo residual realizada tras la planificación.
- [ ] Aprobación y aceptación formal del riesgo residual obtenida de los Risk Owners.
- [ ] Proceso periódico de seguimiento de acciones y revisión de bloqueos configurado.
Un plan de tratamiento eficaz conecta riesgo, controles, responsables, evidencia y aceptación residual. Si quieres profundizar en esta lógica dentro de gobierno, riesgo y cumplimiento, puedes continuar con Analista GRC: Gobernanza de IT, Riesgo y Cumplimiento.
Cursos recomendados de ISO 27001 y Ciberseguridad
Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento.
Gobernanza de IT, Riesgo y Cumplimiento. Perfil corporativo en alza.
Ver curso GRC
Prepara Todas las Certificaciones ISO 27001, con Práctica.
Prepárate para todas las certificaciones ISO 27001 con práctica real.
Ver curso ISO 27001