En el módulo anterior construimos el mapa de riesgos: activos identificados, amenazas y vulnerabilidades cruzadas, y un valor de riesgo —probabilidad × impacto— para cada escenario. Ese mapa es diagnóstico, no acción. Un riesgo analizado y sin tratar no protege nada: sigue ahí, exactamente igual, esperando a materializarse. Este módulo cierra el ciclo de gestión de riesgos abordando la pregunta que de verdad importa al negocio: ¿qué hacemos con cada riesgo? Y, sobre todo, cómo lo documentamos de forma que resista una auditoría de certificación ISO 27001 sin fisuras.
El eje de este módulo es la Declaración de Aplicabilidad (SoA, Statement of Applicability), el documento más citado —y más frecuentemente mal hecho— de cualquier proyecto ISO 27001. Si el análisis de riesgos es el diagnóstico, la SoA es la receta firmada: qué controles aplican, cuáles no y por qué. Un auditor experimentado puede tumbar una certificación entera si la SoA está copiada de una plantilla genérica sin trazabilidad real al análisis de riesgos de la organización.
Qué aprenderás
- Las cuatro opciones de tratamiento del riesgo (mitigar, transferir, aceptar, evitar) y el criterio coste-beneficio para elegir entre ellas.
- Cómo estructurar y redactar un Plan de Tratamiento del Riesgo (RTP) que un comité de dirección pueda aprobar y un auditor pueda seguir.
- Qué es el riesgo residual, cómo se estima y por qué su aceptación formal por el propietario del riesgo es un requisito auditable de ISO 27001.
- La cadena de trazabilidad riesgo → control → ISO/IEC 27002:2022, indispensable para justificar cualquier decisión ante un auditor.
- Cómo construir la Declaración de Aplicabilidad (SoA) a partir de los 93 controles del Anexo A, con sus columnas obligatorias.
- El ciclo de seguimiento continuo y reevaluación periódica del riesgo, y qué herramientas usar (PILAR/EAR del CCN, plataformas GRC).
- A resolver un caso práctico completo: de tres riesgos analizados a su fila de RTP y su fila de SoA.
Las opciones de tratamiento del riesgo
ISO 31000 (gestión de riesgos genérica) e ISO/IEC 27005 (gestión de riesgos de seguridad de la información, que particulariza ISO 31000 para nuestro dominio) describen cuatro opciones de tratamiento. No son alternativas puramente técnicas: son decisiones de negocio que el propietario del riesgo toma con información técnica de apoyo. Conviene fijar la terminología, porque en español circulan variantes (mitigar/reducir, transferir/compartir) que en la práctica son sinónimos usados indistintamente en la literatura y en las plantillas de auditoría.
1. Mitigar / reducir: aplicar controles
Es la opción más habitual. Se reduce la probabilidad de que la amenaza se materialice, el impacto si ocurre, o ambos, mediante controles técnicos, organizativos, físicos o de personas —las cuatro categorías del Anexo A de ISO/IEC 27001:2022. Ejemplos: cifrado de discos para reducir el impacto de un robo de portátil, autenticación multifactor para reducir la probabilidad de una cuenta comprometida, segmentación de red para reducir el alcance de un ransomware. Mitigar no elimina el riesgo: lo baja hasta un nivel residual que debe quedar por debajo del apetito de riesgo de la organización (concepto que trabajamos en el Módulo 3).
2. Transferir / compartir: seguros ciber, externalización
Se traslada una parte del impacto económico o de la responsabilidad operativa a un tercero, sin eliminar el riesgo subyacente. Dos mecanismos principales en el contexto español y europeo:
- Seguro de ciberriesgo (cyber insurance). Cubre parcialmente costes de respuesta a incidentes, notificación a afectados (relevante bajo RGPD), pérdida de negocio y, en algunas pólizas, sanciones cuando son asegurables según la jurisdicción. No transfiere la responsabilidad legal ante la AEPD ni exime de las obligaciones de notificación de brecha en 72 horas del artículo 33 RGPD: solo compensa parte del daño económico.
- Externalización con SLA de seguridad. Contratar un proveedor cloud, un SOC gestionado o un proveedor de backup con cláusulas contractuales de seguridad y penalizaciones. Ojo: bajo RGPD y bajo NIS2, la responsabilidad última ante el regulador casi nunca se transfiere del todo —la cadena de suministro es hoy uno de los focos de supervisión de NIS2 precisamente por esto.
Error frecuente: tratar la transferencia como si eliminara el riesgo. No lo hace: cambia quién asume el coste económico, pero la organización sigue siendo responsable de la diligencia debida, de exigir evidencias al asegurador o proveedor, y de la reputación ante clientes y regulador.
3. Aceptar: formal y documentado
Se decide convivir con el riesgo sin aplicar controles adicionales, normalmente porque el coste de tratarlo supera el beneficio esperado, o porque el riesgo ya está dentro del apetito de riesgo aprobado. La aceptación de riesgo no es no hacer nada: es una decisión de negocio que ISO 27001 exige documentar y firmar explícitamente por el propietario del riesgo (cláusula 6.1.3 e), sobre la que profundizamos más abajo). Una aceptación sin firma ni fecha de revisión es, en la práctica, un riesgo sin tratar disfrazado de decisión.
4. Evitar: eliminar la actividad
Se elimina la fuente del riesgo descontinuando la actividad, el proceso, el sistema o la relación con el tercero que lo genera. Es la opción más drástica y la menos usada porque tiene coste de oportunidad: dejar de ofrecer un servicio, cerrar un sistema legacy sin sustituto, romper una integración con un proveedor. Ejemplos reales: retirar un sistema Windows Server 2012 sin soporte que no se puede parchear ni aislar, cancelar el uso de una app de mensajería no corporativa para intercambiar datos de clientes, o no lanzar una función que requeriría procesar datos biométricos sin base legal clara.
Cómo elegir: coste-beneficio y apetito de riesgo
No existe una opción «correcta» por defecto: la decisión combina tres factores.
- Coste del tratamiento frente a la reducción de riesgo que aporta. Un control de 40.000 €/año que reduce un riesgo de impacto 15.000 € anuales no es racional salvo que existan razones normativas (por ejemplo, un control exigido por el ENS o por un cliente contractualmente).
- Apetito de riesgo aprobado por dirección. Si el comité de seguridad ha fijado que ningún riesgo con impacto «crítico» puede quedar sin tratar activamente, eso descarta la aceptación para esos escenarios independientemente del coste.
- Obligaciones normativas y contractuales. Un riesgo puede tener un coste de tratamiento alto pero ser de aplicación obligatoria (por ejemplo, cifrado de datos de salud bajo RGPD, o requisitos de notificación de incidentes bajo NIS2 para entidades esenciales o importantes). Aquí el análisis coste-beneficio queda subordinado al cumplimiento legal.
En la práctica, la mayoría de los riesgos de nivel medio-alto combinan opciones: se mitiga hasta donde es razonable y, sobre el riesgo residual restante, se decide transferir una parte (seguro) o aceptar formalmente el resto.
El Plan de Tratamiento del Riesgo (RTP)
El Plan de Tratamiento del Riesgo (Risk Treatment Plan, RTP) es el documento operativo que traduce cada decisión de tratamiento en acciones concretas, con dueño y plazo. ISO/IEC 27001:2022, cláusula 6.1.3, exige formular este plan como parte del proceso de tratamiento de riesgos, y la cláusula 6.1.3 f) requiere obtener la aprobación del plan por parte de los propietarios del riesgo. Sin RTP aprobado, no hay evidencia de que la organización gestione realmente sus riesgos: solo los ha catalogado.
Estructura mínima de una fila del RTP
| Campo | Contenido |
|---|---|
| ID del riesgo | Referencia al registro de riesgos del Módulo 3 (ej. R-014) |
| Descripción del riesgo | Activo, amenaza y vulnerabilidad, en una frase |
| Riesgo inherente | Valor probabilidad × impacto antes de tratamiento |
| Opción de tratamiento | Mitigar / Transferir / Aceptar / Evitar |
| Controles a implantar | Referencia a control(es) de ISO/IEC 27002:2022 o control específico |
| Responsable (dueño de la acción) | Persona o rol concreto, no un departamento genérico |
| Plazo | Fecha límite de implantación |
| Recursos necesarios | Presupuesto, personas, herramientas |
| Riesgo residual estimado | Valor esperado tras aplicar el control |
| Estado | Pendiente / En curso / Implantado / Verificado |
Ejemplo de plan de tratamiento (extracto)
| ID | Riesgo | Opción | Controles | Responsable | Plazo | Estado |
|---|---|---|---|---|---|---|
| R-014 | Exfiltración de datos de clientes por cuenta de administrador comprometida (sin MFA) | Mitigar | ISO 27002:2022 8.5 (autenticación segura), 5.18 (derechos de acceso) | Responsable de Sistemas | 30 días | En curso |
| R-027 | Indisponibilidad prolongada del ERP por fallo del proveedor cloud sin plan de continuidad contractual | Transferir + Mitigar | Cláusula SLA de disponibilidad 99,9 % + seguro de interrupción de negocio + plan de continuidad propio (27002:2022 5.29, 5.30) | Responsable de Compras / DPO | 60 días | Pendiente |
| R-041 | Filtración de datos de un formulario web de baja criticidad, impacto residual mínimo tras revisión legal | Aceptar | N/A — aceptación formal documentada | Propietario del riesgo: Responsable de Marketing | Revisión anual | Aceptado (firmado 03/2026) |
Riesgo residual y su aceptación formal
El riesgo residual es el nivel de riesgo que permanece después de aplicar los controles del plan de tratamiento. Ningún control reduce un riesgo a cero: siempre queda un remanente, ya sea porque el control tiene una eficacia inferior al 100 %, porque cubre solo parte del vector de ataque, o porque introduce nuevos riesgos residuales propios (por ejemplo, un control mal configurado).
Cómo se estima
La forma más práctica, siguiendo la misma escala cualitativa o semicuantitativa usada en el análisis de riesgos del Módulo 3, es reevaluar probabilidad e impacto asumiendo el control ya implantado y operando correctamente:
- Reducción de probabilidad. Un control preventivo (MFA, segmentación, hardening) suele bajar la probabilidad de explotación exitosa. Se reestima con el mismo criterio cualitativo (muy baja/baja/media/alta/muy alta) o, en enfoques cuantitativos tipo FAIR, recalculando la frecuencia de pérdida anualizada.
- Reducción de impacto. Un control de contención o recuperación (backups probados, cifrado en reposo, segregación de redes) no evita el incidente pero limita su alcance o coste. Se reestima el impacto esperado tras el control.
- Documentar el supuesto de eficacia. Es buena práctica anotar de qué eficacia del control se parte (por ejemplo, «se asume que el MFA reduce en un 90 % la probabilidad de compromiso por credenciales robadas, según referencias del sector») en vez de dar una cifra sin justificar.
La aceptación formal: un requisito auditable, no un trámite
ISO/IEC 27001:2022, cláusula 6.1.3 e), exige explícitamente «obtener la aprobación de los propietarios del riesgo del plan de tratamiento de riesgos de seguridad de la información y la aceptación de los riesgos residuales de seguridad de la información». Esto significa dos cosas que un auditor va a verificar de forma independiente:
- El plan de tratamiento en su conjunto debe estar aprobado por quienes son propietarios de cada riesgo (no basta con la firma genérica de un CISO si el riesgo pertenece funcionalmente a otro responsable).
- Cada riesgo residual —incluidos los que se mitigan parcialmente, no solo los que se aceptan sin tratar— requiere una aceptación explícita de que el nivel remanente es tolerable.
En la práctica, esto se traduce en un registro con nombre, cargo, fecha y firma (física o electrónica con validez probatoria) del propietario del riesgo, junto al valor de riesgo residual aceptado y la fecha en que se revisará esa aceptación. Sin este registro, un auditor de certificación puede levantar una no conformidad porque no hay evidencia objetiva de que la aceptación haya sido una decisión consciente de quien tiene autoridad para tomarla, y no una omisión.
De la matriz de riesgos a los controles de ISO/IEC 27002
La relación riesgo → control no es libre: cada control que se decide implantar debe poder trazarse hasta el riesgo (o riesgos) que mitiga. Esta trazabilidad es la columna vertebral que conecta el análisis de riesgos (Módulo 3) con la Declaración de Aplicabilidad (este módulo) y es, junto a la propia SoA, uno de los puntos que más se revisan en una auditoría de certificación.
El flujo de trabajo
- Del registro de riesgos se identifica cada riesgo con nivel inaceptable según el apetito de riesgo aprobado.
- Se selecciona la opción de tratamiento (mitigar/transferir/aceptar/evitar) según el criterio coste-beneficio visto antes.
- Si la opción implica controles, se buscan en el catálogo de 93 controles de ISO/IEC 27002:2022 —organizados en cuatro categorías: 37 organizativos, 8 de personas, 14 físicos y 34 tecnológicos— los que mitigan específicamente ese vector de amenaza.
- Se documenta la relación en el RTP (qué controles tratan qué riesgo) y, de forma inversa, en la SoA (qué riesgo justifica la inclusión de cada control).
Esta doble trazabilidad (riesgo→control en el RTP, control→riesgo en la SoA) es lo que permite responder con seguridad a la pregunta típica de auditoría: «¿por qué tienen implantado el control 8.16 (actividades de monitorización)?» La respuesta correcta empieza siempre en un riesgo del registro, no en «porque lo pide la norma».
La Declaración de Aplicabilidad (SoA)
La Declaración de Aplicabilidad, conocida universalmente por su acrónimo en inglés SoA (Statement of Applicability), es, sin exagerar, el documento central de todo el SGSI. Es el único documento que ISO/IEC 27001:2022 exige explícitamente por su nombre en el texto normativo (cláusula 6.1.3 d), y es el primer documento que un auditor de certificación pide ver.
Qué es y por qué es central
La SoA es la lista completa y comentada de los 93 controles del Anexo A de ISO/IEC 27001:2022 (que remiten a ISO/IEC 27002:2022), donde la organización declara, control por control:
- Si el control aplica o no aplica al alcance de su SGSI.
- La justificación de esa decisión —tanto si se incluye como si se excluye.
- El estado de implantación real del control (implantado, parcialmente implantado, pendiente, no aplica).
- Una referencia a la documentación de soporte (política, procedimiento, registro de riesgo asociado).
Es central por tres motivos: primero, es la evidencia de que la organización ha considerado todos los controles del estándar, no solo los que le resultaban cómodos. Segundo, conecta el análisis de riesgos con la implantación real, cerrando el círculo que empezó en el Módulo 3. Tercero, es el documento que el auditor usa como índice para pedir evidencias de cada control marcado como aplicable e implantado —si la SoA dice que el control 8.24 (uso de criptografía) está implantado, el auditor pedirá ver la política de cifrado y sus registros.
Cómo se construye
- Partir del catálogo completo de 93 controles del Anexo A / ISO/IEC 27002:2022, sin omitir ninguno.
- Cruzar cada control con el registro de riesgos. Un control es aplicable si mitiga uno o más riesgos identificados en el análisis, o si es exigido por ley, regulación o contrato (por ejemplo, cláusulas de seguridad impuestas por un cliente, o requisitos del ENS si la organización también debe cumplirlo).
- Justificar cada exclusión de forma específica. «No aplica porque no tenemos desarrollo de software propio» es válida para el control 8.25 (ciclo de vida de desarrollo seguro) si es cierto y verificable; «no aplica» sin más, no lo es.
- Registrar el estado real de implantación, no el deseado. Un control aplicable pero aún no implantado se marca como tal, y su implantación pasa al Plan de Tratamiento del Riesgo con plazo y responsable.
- Someter la SoA a aprobación formal por la dirección/comité de seguridad, con fecha y versión, y revisarla al menos en cada revisión del SGSI o cuando cambie el alcance, el registro de riesgos o el contexto normativo.
Estructura de columnas de la SoA
| Columna | Contenido |
|---|---|
| Referencia del control | Numeración de ISO/IEC 27002:2022 (ej. 5.9, 8.16) |
| Nombre del control | Título literal del control según el estándar |
| Categoría | Organizativo / Personas / Físico / Tecnológico |
| Aplicable (Sí/No) | Declaración explícita, sin ambigüedad |
| Justificación de inclusión o exclusión | Motivo concreto, trazable al riesgo o a la obligación legal |
| Estado de implantación | Implantado / Parcial / Pendiente / No aplica |
| Referencia a evidencia/riesgo asociado | Enlace a política, procedimiento o ID de riesgo del RTP |
Ejemplo de SoA con controles reales (extracto ilustrativo)
| Ref. | Control (ISO/IEC 27002:2022) | Aplicable | Justificación | Estado | Referencia |
|---|---|---|---|---|---|
| 5.9 | Inventario de información y otros activos asociados | Sí | Base para todo el análisis de riesgos; mitiga R-003 (activos sin inventariar no gestionados) | Implantado | Registro de Activos v3 |
| 5.30 | Preparación de las TIC para la continuidad del negocio | Sí | Mitiga R-027 (indisponibilidad del ERP); exigido además por cláusula contractual de disponibilidad con cliente principal | Parcial | RTP-R027 |
| 6.3 | Concienciación, educación y formación en seguridad | Sí | Mitiga R-014 y otros riesgos de phishing/ingeniería social del registro | Implantado | Plan de Formación 2026 |
| 7.4 | Supervisión de la seguridad física | No | La organización opera 100 % en instalaciones cloud de terceros certificados (ISO 27001); no gestiona CPD propio dentro del alcance del SGSI | No aplica | Declaración de alcance del SGSI |
| 8.24 | Uso de criptografía | Sí | Mitiga R-014 (exfiltración de datos) y obligación RGPD de medidas técnicas apropiadas para datos personales | Implantado | Política de Cifrado v2 |
Nota: la selección de controles y su redacción exacta debe verificarse contra el texto vigente de ISO/IEC 27002:2022 al elaborar la SoA real de una organización; este extracto es ilustrativo del formato, no una SoA completa.
Seguimiento continuo y reevaluación periódica
El tratamiento del riesgo no es un evento único: es un ciclo. Un riesgo tratado hoy puede volver a subir de nivel mañana porque cambia el contexto —nueva amenaza, nueva vulnerabilidad publicada, cambio en el negocio, nuevo proveedor, nueva obligación normativa (NIS2 y DORA, por ejemplo, han elevado sustancialmente el nivel de riesgo aceptable en cadena de suministro para muchos sectores desde su entrada en aplicación). Buenas prácticas de seguimiento:
- Revisión periódica programada del registro de riesgos y de la SoA, como mínimo en cada revisión anual del SGSI, y siempre que cambie el alcance, la arquitectura o el marco legal aplicable.
- Indicadores de seguimiento (KRI) ligados a cada control crítico —por ejemplo, porcentaje de cuentas con MFA activo, tiempo medio de aplicación de parches críticos— que alimenten el comité de seguridad visto en el Módulo 2.
- Disparadores de reevaluación fuera de ciclo: un incidente de seguridad, una auditoría externa con hallazgos, un cambio de proveedor cloud, la incorporación de un nuevo servicio o la publicación de una vulnerabilidad crítica en un componente usado por la organización.
- Cierre del ciclo con evidencia: cada control marcado «implantado» en la SoA debe poder demostrarse con evidencia viva (configuración actual, registro de logs, certificado vigente), no solo con la fecha en que se implantó originalmente.
Este seguimiento retroalimenta directamente el análisis de riesgos del Módulo 3: los indicadores y los incidentes reales son la mejor fuente para recalibrar probabilidades e impactos en la siguiente iteración.
Herramientas: PILAR/EAR y plataformas GRC
PILAR (Procedimiento Informático-Lógico para el Análisis de Riesgos) es la herramienta de referencia del Centro Criptológico Nacional (CCN) en España, desarrollada bajo la familia de herramientas EAR (Entorno de Análisis de Riesgos). Implementa la metodología MAGERIT (vista en el Módulo 3) y está especialmente alineada con el Esquema Nacional de Seguridad, aunque incluye perfiles para ISO 27001/27002. Existen varias variantes: PILAR completo, PILAR Basic (pensado para pymes y entidades locales) y µPILAR (análisis rápidos). Es de descarga gratuita para entidades del sector público a través del portal del CCN-CERT; para el sector privado conviene verificar las condiciones de licencia vigentes en el propio portal antes de desplegarla. Permite mantener el registro de riesgos, simular el efecto de controles sobre el riesgo residual y generar planes de mejora trazables, lo que la hace especialmente útil para organizaciones que deben compatibilizar ISO 27001 con el ENS.
Para organizaciones que gestionan varios marcos a la vez (ISO 27001, ENS, RGPD, NIS2, DORA) es también habitual apoyarse en plataformas GRC comerciales (de forma genérica: herramientas de gestión de gobierno, riesgo y cumplimiento que centralizan registro de riesgos, SoA, planes de tratamiento, evidencias de auditoría y seguimiento de KPIs/KRIs en un único repositorio con flujos de aprobación). La elección entre PILAR/EAR y una plataforma GRC comercial depende del tamaño de la organización, del número de marcos normativos a gestionar simultáneamente y del presupuesto; no son mutuamente excluyentes —muchas organizaciones usan PILAR para el análisis de riesgos técnico y una plataforma GRC para la gestión documental y de auditoría del conjunto.
Caso práctico
Continuando el registro de riesgos del Módulo 3, una pyme de servicios financieros con 80 empleados tiene, entre otros, estos tres riesgos identificados y valorados:
- R-014: Exfiltración de datos de clientes por compromiso de una cuenta de administrador de dominio sin autenticación multifactor (MFA). Riesgo inherente: Alto (probabilidad Alta × impacto Alto).
- R-027: Indisponibilidad del ERP durante más de 24 horas por incidente en el proveedor cloud, sin cláusula contractual de disponibilidad ni plan de continuidad propio. Riesgo inherente: Medio-Alto.
- R-041: Posible filtración de las respuestas de un formulario de contacto público (nombre, email, mensaje) por una vulnerabilidad XSS de baja explotabilidad detectada en una auditoría de caja gris. Riesgo inherente: Bajo.
Decisión de tratamiento
| Riesgo | Opción elegida | Razonamiento |
|---|---|---|
| R-014 | Mitigar | Impacto alto (datos de clientes, obligación RGPD) y coste del control (MFA en el IdP ya contratado) bajo. Coste-beneficio claramente favorable; por encima del apetito de riesgo aprobado, no cabe aceptar. |
| R-027 | Transferir + Mitigar | Eliminar el proveedor cloud (evitar) tendría un coste de migración desproporcionado. Se negocia SLA de disponibilidad con penalización (transferir parcialmente el impacto económico) y se implanta un plan de continuidad propio con backups verificados (mitigar el impacto residual). |
| R-041 | Mitigar y después Aceptar el residual | Se corrige la vulnerabilidad XSS (coste bajo, corrección de código) y, dado que el dato expuesto es de baja sensibilidad y el riesgo residual queda claramente dentro del apetito de riesgo aprobado, el propietario acepta formalmente el remanente sin controles adicionales. |
Fila del Plan de Tratamiento del Riesgo
| ID | Riesgo | Opción | Controles | Responsable | Plazo | Riesgo residual estimado | Estado |
|---|---|---|---|---|---|---|---|
| R-014 | Exfiltración por cuenta admin. sin MFA | Mitigar | 27002:2022 8.5 (autenticación segura); 5.18 (revisión de derechos de acceso privilegiados) | Responsable de Sistemas | 21 días | Bajo | En curso |
| R-027 | Indisponibilidad ERP >24h por proveedor cloud | Transferir + Mitigar | 27002:2022 5.30 (continuidad TIC); 5.22 (seguimiento de servicios de proveedores); cláusula SLA 99,9 % + penalización | Responsable de Compras y Responsable de Sistemas | 60 días | Medio-Bajo | Pendiente |
| R-041 | Filtración de formulario por XSS | Mitigar + Aceptar residual | 27002:2022 8.28 (codificación segura) | Responsable de Desarrollo Web | 15 días | Muy bajo — aceptado | Aceptado (pendiente de firma tras corrección) |
Fila correspondiente de la SoA
| Ref. | Control | Aplicable | Justificación | Estado | Referencia |
|---|---|---|---|---|---|
| 8.5 | Autenticación segura | Sí | Mitiga R-014 (exfiltración por cuenta admin. comprometida); obligación de medidas técnicas apropiadas art. 32 RGPD | En curso | RTP-R014 |
| 5.30 | Preparación de las TIC para la continuidad del negocio | Sí | Mitiga R-027 (indisponibilidad prolongada del ERP crítico para operativa financiera) | Pendiente | RTP-R027 |
| 8.28 | Codificación segura | Sí | Mitiga R-041 (vulnerabilidad XSS en formulario público) | En curso | RTP-R041 |
Para profundizar en cómo se detectan y corrigen vulnerabilidades como la XSS de R-041 en aplicaciones web, el curso de Hacking Web cubre metodología de pentesting de aplicaciones. Si el escenario R-014 hubiera llegado a materializarse, el curso de DFIR y Respuesta a Incidentes detalla cómo investigar y contener el compromiso; y como buena parte de este tipo de riesgos gira en torno a cuentas de dominio, el curso de Defensa de Active Directory profundiza en el hardening de la autenticación privilegiada.
Errores comunes
- SoA copiada de una plantilla genérica, sin justificar exclusiones. Es el hallazgo de auditoría más frecuente. Marcar controles como «No aplica» sin una justificación específica y verificable (por ejemplo, «no aplica» sin más para el control de desarrollo seguro cuando la empresa sí desarrolla software internamente) es una no conformidad casi automática.
- Aceptar riesgos sin firma del propietario del riesgo. Una aceptación verbal en una reunión, o un campo «aceptado» marcado por el equipo de seguridad sin que el propietario funcional del riesgo lo haya firmado, no cumple con la cláusula 6.1.3 e) de ISO/IEC 27001:2022 y deja al SGSI sin evidencia objetiva de la decisión.
- Plan de tratamiento sin plazos ni dueño concreto. Filas del RTP con responsable «IT» o «el departamento correspondiente» y sin fecha límite no son accionables; en la práctica, esos controles nunca se implantan porque nadie tiene la responsabilidad ni el plazo exigible.
- Confundir riesgo inherente con riesgo residual en el registro, de forma que se reporta a dirección un nivel de riesgo que ya no refleja los controles implantados (o que asume controles que en realidad siguen pendientes).
- No actualizar la SoA cuando cambia el alcance o el registro de riesgos, dejando un documento «aprobado» que ya no refleja la realidad de la organización en el momento de la auditoría.
- Tratar la transferencia (seguro) como eliminación del riesgo, olvidando que la responsabilidad regulatoria y reputacional casi nunca se transfiere junto con el coste económico.
Ejercicio
Retoma tres riesgos de tu propio registro de riesgos (o, si no dispones de uno, usa tres riesgos plausibles de una organización que conozcas: por ejemplo, un riesgo de phishing dirigido a finanzas, un riesgo de fuga de datos por un dispositivo personal no gestionado (BYOD) y un riesgo de dependencia de un único desarrollador que mantiene un sistema crítico sin documentación).
- Para cada riesgo, decide la opción de tratamiento (mitigar/transferir/aceptar/evitar) y redacta en dos frases el razonamiento coste-beneficio que justifica esa elección.
- Construye la fila completa del Plan de Tratamiento del Riesgo para cada uno, incluyendo control de ISO/IEC 27002:2022 asociado (busca el número real de control que mejor encaje), responsable con nombre de rol concreto, plazo realista y estimación cualitativa del riesgo residual.
- Redacta la fila de SoA correspondiente a cada control elegido, con justificación de inclusión trazada explícitamente al ID del riesgo.
- Para uno de los tres riesgos, redacta el texto de aceptación formal de riesgo residual que firmaría el propietario del riesgo, incluyendo: descripción del riesgo residual, nivel aceptado, fecha de revisión prevista y espacio para nombre, cargo y fecha de firma.
Preguntas frecuentes
¿Es obligatorio tratar todos los riesgos identificados en el análisis?
No. ISO 27001 no exige tratar todos los riesgos con controles adicionales: exige que cada riesgo tenga una decisión de tratamiento explícita y documentada, que puede ser perfectamente la aceptación formal cuando el nivel de riesgo está dentro del apetito aprobado por dirección. Lo que sí es obligatorio es que esa decisión exista, esté justificada y esté firmada por quien tiene autoridad para tomarla.
¿Puede un control estar en la SoA como «aplicable» pero no estar implantado?
Sí, y es una situación habitual y correcta siempre que se refleje con honestidad. La columna de estado de implantación existe precisamente para eso: un control puede ser aplicable (porque mitiga un riesgo real) y estar «pendiente» o «parcial», con su correspondiente fila en el Plan de Tratamiento del Riesgo indicando plazo y responsable para completarlo. Lo que no es aceptable es marcarlo como «implantado» sin evidencia real.
¿Qué diferencia hay entre riesgo inherente y riesgo residual?
El riesgo inherente es el nivel de riesgo antes de aplicar cualquier control adicional (aunque en la práctica suele calcularse considerando los controles ya existentes, no un escenario de «cero controles»). El riesgo residual es el nivel que queda después de ejecutar el plan de tratamiento y que el propietario del riesgo debe aceptar formalmente. La diferencia entre ambos es, en esencia, la eficacia del tratamiento aplicado.
¿Quién debe firmar la aceptación de un riesgo residual: el CISO o el responsable del área de negocio?
El propietario del riesgo, que rara vez es el CISO salvo que el riesgo pertenezca directamente a la función de seguridad. ISO 27001 distingue entre el rol que analiza y propone (habitualmente seguridad/GRC) y el rol que asume la responsabilidad de negocio sobre el riesgo (el director del área afectada: financiero, comercial, operaciones, RR. HH., según el caso). El CISO puede coordinar el proceso y asesorar técnicamente, pero la firma de aceptación corresponde a quien tiene autoridad sobre el proceso o activo afectado.
¿Con qué frecuencia hay que actualizar la Declaración de Aplicabilidad?
Como mínimo, en cada revisión del SGSI (habitualmente anual) y siempre que se produzca un cambio significativo: modificación del alcance del SGSI, actualización relevante del registro de riesgos, incorporación de un nuevo sistema o proveedor crítico, o un cambio normativo que introduzca nuevas obligaciones (por ejemplo, la entrada en aplicación de NIS2 o DORA para organizaciones dentro de su ámbito). Una SoA que no se ha tocado en varios años, en una organización que ha cambiado de infraestructura o de proveedores, es en sí misma una señal de alerta para un auditor.
«La organización debe formular un proceso de tratamiento de riesgos de seguridad de la información […] y producir una Declaración de Aplicabilidad que contenga los controles necesarios […] y la justificación de las inclusiones, si se implementan o no, y la justificación de las exclusiones de los controles del Anexo A.»