En una auditoría ISO 27001 Stage 2, el auditor no se queda en el registro de riesgos. Pide seguir la cadena: riesgo identificado, decisión de tratamiento, acción concreta, propietario, plazo, evidencia de implementación y riesgo residual aceptado. Esa cadena vive en el plan de tratamiento de riesgos exigido por la cláusula 6.1.3 de ISO/IEC 27001:2022.
Muchas organizaciones confunden tres documentos distintos: el registro de riesgos (output del análisis), el Statement of Applicability (qué controles del Anexo A aplican) y el plan de tratamiento (qué se hace con cada riesgo que supera los criterios de aceptación). Tener el primero sin el tercero es una de las causas más frecuentes de hallazgos mayores en primera certificación.
Qué es el plan de tratamiento de riesgos y en qué se diferencia del registro
El plan de tratamiento de riesgos es el documento que registra, para cada riesgo que requiere acción, la opción de tratamiento elegida, los controles o medidas concretas, los responsables, los plazos y el riesgo residual esperado una vez implementado. ISO 27001 lo distingue explícitamente de la evaluación de riesgos (cláusula 6.1.2): la evaluación identifica y valora; el plan decide y asigna.
La relación entre documentos es lineal:
- Evaluación de riesgos → produce el registro con niveles de riesgo inherente.
- Evaluación contra criterios de aceptación → filtra qué riesgos necesitan tratamiento.
- Plan de tratamiento → detalla acciones por riesgo.
- Statement of Applicability → consolida qué controles del Anexo A se implementan y por qué.
- Evidencias → demuestran que las acciones del plan se ejecutaron.
Si el SoA lista controles que no aparecen en ningún plan de tratamiento vinculado a un riesgo, el auditor pregunta por qué se eligieron. Si el plan describe acciones genéricas («reforzar seguridad») sin control del Anexo A ni evidencia verificable, tampoco aguanta.
Las 4 opciones de tratamiento según ISO 27005
La norma no usa exactamente la terminología coloquial «mitigar, aceptar, transferir, evitar». En ISO/IEC 27005:2022 las opciones son:
- Modificar el riesgo: Reducir la probabilidad o el impacto mediante controles. Es la opción más habitual: se seleccionan controles del Anexo A (o controles adicionales documentados) y se implementan. Ejemplo: riesgo de acceso no autorizado a CRM → control A.5.15 (control de accesos) + A.5.16 (gestión de identidades) + MFA en el IdP.
- Retener el riesgo: Aceptar el riesgo residual sin acción adicional más allá de los controles ya existentes. Requiere que el nivel residual esté dentro de los criterios de aceptación y que el propietario del riesgo firme la aceptación formal. No es «no hacer nada»: es decidir conscientemente que el riesgo restante es tolerable.
- Evitar el riesgo: Eliminar la actividad, el activo o el proceso que genera el riesgo. Ejemplo: dejar de almacen datos de clientes en hojas de cálculo locales eliminando el riesgo de pérdida por dispositivo no cifrado. Poco frecuente pero válido cuando el coste de control supera el valor del activo.
- Compartir el riesgo: Transferir parcialmente el impacto financiero, habitualmente mediante seguro cibernético o cláusulas contractuales con proveedores. No elimina la obligación de controles: sigues siendo responsable operativamente.
Cada riesgo del plan debe tener una sola opción principal documentada. Combinar «modificar + retener» es normal (implementas controles y aceptas el residual), pero debe quedar explícito cuál es el residual y quién lo acepta.
Campos que el auditor espera ver en cada entrada del plan
Un plan que aguanta auditoría no es un párrafo por riesgo. Es una fila estructurada con trazabilidad. Estos son los campos mínimos:
| Campo | Qué debe contener |
|---|---|
| ID de riesgo | Referencia al registro de riesgos |
| Descripción del riesgo | Escenario claro: amenaza + activo + consecuencia |
| Nivel inherente | Antes de tratamiento |
| Opción de tratamiento | Modificar, retener, evitar o compartir |
| Controles del Anexo A | Referencia explícita (ej. A.8.24, A.5.33) |
| Acciones concretas | Qué se implementa, no intenciones vagas |
| Propietario del riesgo | Responsable de la decisión y aceptación residual |
| Responsable de implementación | Quien ejecuta la acción (puede ser distinto) |
| Fecha objetivo | Plazo de implementación |
| Estado | Planificado, en curso, completado, verificado |
| Evidencia requerida | Qué documento o registro demuestra la acción |
| Riesgo residual | Nivel esperado tras implementación |
| Aceptación del residual | Firma o acta del propietario del riesgo |
La guía para crear una evaluación de riesgos ISO 27001 cubre la fase anterior (registro y niveles). El plan de tratamiento es el paso siguiente: convertir números en proyecto.
Cómo construir el plan en 5 pasos
1. Filtrar riesgos que requieren plan detallado. No todo riesgo del registro necesita un plan expandido. Los riesgos por debajo del umbral de aceptación pueden documentarse en el registro con decisión «retener» y justificación breve. Reserva el plan detallado para riesgos medios y altos y para cualquier riesgo donde la opción elegida sea modificar con varios controles.
2. Seleccionar controles con criterio, no copiar el Anexo A. Elegir 93 controles «por si acaso» infla el SoA y el trabajo de implementación. Por cada riesgo, pregunta: qué control reduce específicamente esta amenaza sobre este activo. Si un control cubre varios riesgos, referéncialo en cada fila del plan.
3. Desglosar acciones implementables. «Implementar política de accesos» no es acción; es título. Acciones válidas: redactar política, someter a aprobación de dirección, configurar MFA en Entra ID, revisar miembros del grupo admin-cloud, documentar excepciones aprobadas.
4. Asignar propietarios reales. El propietario del riesgo suele ser el responsable del proceso o sistema afectado (director de producto para riesgo en SaaS, CFO para riesgo financiero). El responsable de implementación puede ser IT o seguridad. Confundir ambos roles genera acciones sin dueño.
5. Vincular al SoA y programar verificación. Cuando una acción se completa, actualiza el SoA (control marcado como implementado), archiva la evidencia y recalcula el riesgo residual. Programa revisión del plan en la revisión por dirección y ante cambios significativos, como exige el marco de gestión de riesgos del SGSI.
Ejemplo de cadena auditable (sin plantilla genérica)
Supongamos un riesgo identificado en una empresa SaaS B2B:
- Riesgo R-014: Exposición de datos de clientes por bucket S3 mal configurado.
- Inherente: Alto (probabilidad media × impacto alto).
- Tratamiento: Modificar.
- Controles: A.8.20 (seguridad en redes), A.8.24 (cifrado), A.8.9 (gestión de configuración).
- Acciones: Activar Block Public Access en todas las cuentas AWS; implementar policy SCP que deniegue ACLs públicas; desplegar scanner semanal de buckets; corregir los tres buckets flagged en el primer scan.
- Propietario del riesgo: CTO.
- Plazo: 30 días desde aprobación del plan.
- Evidencia: Export de AWS Config + ticket de remediación cerrado + informe del scanner.
- Residual: Bajo, aceptado por CTO en acta del comité de seguridad.
Esa cadena es lo que el auditor sigue. No necesita un ejemplo de fraude o robo de identidad copiado de un blog genérico: necesita ver tu riesgo real, tu decisión y tu prueba.
6 Errores que generan no conformidades en auditoría
- Plan copiado del registro sin acciones. Misma descripción en ambos documentos, sin controles ni plazos.
- Controles del SoA sin trazabilidad al plan. El auditor elige un control al azar y pregunta qué riesgo cubre.
- Aceptación de riesgo sin firma del propietario. «Retener» documentado solo en Excel sin aprobación formal.
- Acciones completadas sin evidencia. Estado «hecho» sin ticket, configuración, informe o acta que lo demuestre.
- Riesgo residual no recalculado. El plan dice «residual bajo» pero el registro sigue mostrando nivel alto.
- Plan congelado desde la certificación inicial. Sin revisiones tras incidentes, nuevos productos o cambios de proveedor cloud.
Relación con el Statement of Applicability
El SoA y el plan de tratamiento se alimentan mutuamente pero no son intercambiables. El plan es operativo (proyecto por riesgo); el SoA es declarativo (estado de controles del Anexo A). Flujo recomendado:
- Construyes acciones en el plan → identificas controles del Anexo A necesarios → consolidas en el SoA con estado de implementación.
- En revisiones anuales → actualizas plan por nuevos riesgos → ajustas SoA si aparecen controles nuevos o exclusiones justificadas.
La autoevaluación ISO 27001 incluye comprobar coherencia entre registro, plan y SoA antes de convocar al auditor.
Cómo puede ayudar PrivaLex
El plan de tratamiento es donde muchos SGSI bien intencionados se rompen: el registro existe, el SoA está relleno, pero el vínculo entre riesgo, acción y evidencia no aguanta el muestreo del auditor. PrivaLex trabaja con organizaciones en diseño e implementación del SGSI para que la cláusula 6.1.3 quede cubierta de forma verificable.
Metodología y plantillas. Definimos criterios de aceptación, escalas y plantilla de plan alineadas con ISO 27005 y con el formato que vuestro organismo de certificación espera ver. Evitamos plantillas genéricas desconectadas de vuestros procesos.
Construcción del primer plan. Facilitamos el taller de tratamiento con propietarios de riesgo reales: por cada riesgo prioritario, decisión documentada, control del Anexo A seleccionado y acción con plazo. No dejamos al equipo de IT solo con un Excel vacío.
Coherencia registro – plan – SoA. Revisamos trazabilidad cruzada antes de Stage 1 y Stage 2. Corregimos huecos donde un control aparece en el SoA sin riesgo asociado o una acción del plan no tiene evidencia definida.
Seguimiento pre-auditoría. Acompañamos el cierre de acciones pendientes, recopilación de evidencias y aceptación formal de riesgos residuales. Más contexto en ISO 27001 y en la guía de certificación para startups en la UE.
Mantenimiento post-certificación. Integramos revisiones del plan en el ciclo de vigilancia anual y tras cambios de alcance, para que el documento siga vivo y no sea un artefacto de la semana previa a la auditoría.
Conclusión
El plan de tratamiento de riesgos ISO 27001 es el puente entre analizar riesgos y demostrar que el SGSI funciona. Requiere opciones de tratamiento explícitas, controles del Anexo A trazables, acciones con propietario y plazo, evidencias definidas y aceptación documentada del riesgo residual. Sin esa cadena, el registro de riesgos es un ejercicio teórico y el SoA una lista de deseos. Construirlo bien desde la primera certificación ahorra hallazgos, reauditorías parciales y meses de remediación reactiva.
Si quieres revisar si tu plan de tratamiento actual aguantaría una auditoría Stage 2, solicita tu risk assessment gratuito o reserva una sesión con nuestro equipo.
Preguntas Frecuentes
ISO 27001 cláusula 6.1.3 exige un plan de tratamiento de riesgos documentado. Puede ser un documento separado o una extensión estructurada del registro, siempre que contenga las decisiones de tratamiento, controles seleccionados, responsables y resultados esperados. Lo que no vale es un registro que solo lista riesgos y niveles sin decisiones de tratamiento trazables.
Cuando el riesgo residual, tras los controles ya existentes, está dentro de los criterios de aceptación definidos por dirección y el propietario del riesgo documenta y firma esa aceptación. No procede para riesgos altos sin justificación sólida ni sin involucrar a dirección. El auditor verificará que la aceptación no es una forma de ignorar riesgos que deberían tratarse.
No. Solo los controles que tratamientos de riesgo concretos requieren, más los que la organización implementa por decisión propia. El SoA consolida todos los controles aplicables (implementados o no, con justificación). El plan de tratamiento vincula controles a riesgos específicos. Incluir los 93 controles en el plan sin relación con riesgos es tan problemático como un SoA que los excluye todos sin justificación.
Ante cambios significativos (nuevo producto, incidente grave, cambio de proveedor crítico, nueva regulación) y como mínimo en el ciclo de revisión del SGSI, que suele ser anual. Las acciones con plazo vencido sin cerrar son un hallazgo habitual. El plan funciona como documento de gestión de proyecto: estados, fechas y responsables deben estar actualizados.
Depende de la acción: política aprobada y publicada, captura de configuración, informe de test, ticket cerrado en ITSM, registro de formación, acta de comité. La evidencia debe definirse en la fila del plan antes de implementar, no buscarse después cuando llega el auditor. El auditor muestrea riesgos y pide ver la evidencia que el plan prometió.
No. Son documentos complementarios. El plan responde «qué hacemos con este riesgo». El SoA responde «qué controles del Anexo A aplican a la organización y en qué estado están». Ambos deben ser coherentes, pero cumplen funciones distintas en la cláusula 6.1 de ISO 27001.